On my "Yet Another ::std namespace clone" I am currently working on, I am modifying slightly some of the specifications, such as: 1) there is now an "unsafe" access function (non bounds checked), operating as operator[] currently does in ::std::vector 2) operator[] may now be "safe" (bounds checked), depending on the "ImplementationT" type's constants/magic types. 3) different model - the basic containers are now interfaces rather than direct implementations, allowing finer control over details as needed (aka, for a vector, implementing it instead as a vector of pointers to large memory areas, reducing resize costs considerably (and able to release "unused" sub-memory blocks without fear of future performance it). In any case, I'm currently implementing it with this non bounds checked access function labeled "us" (for unsafe) and using the traditional "at" for bounds checked access, in keeping with current STL practice. If AT stands for something (and dosn't just refer to "at the index") I'd be interested - and if anyone has a better name than "us" I'd be interested in that too. It MUST be short, in order to not encourage (much) the use of implementations marked "unsafe" when a safe container would be more appropriate.

i'd prefer, uat. or at_ , or "dontuseme"
It would be good to make it have checks in debug mode anyway.

1) uat

Also my first idea, but could cause potential problems with typeos - aka:
somethingendingwithau.at(10);
might be mistyped:
somethingendingwithau.uat(10);
if they're typing too fast for their own good. Highly unlikely, but it would cause no errors, except prehaps some hard to track down ones that would have been caught by at(), that would cause security holes.

2) at_

Tells me "this is at" when I speed read it in a garble of badly formatted code, or "this is an internal function" when I slow read it. It has no built in meaning. Misleading in either case... to me anyways.

3) dontuseme

Too verbose ;_;. Otherwise I'd go with unsafe_at, or nocheck_at, or something like that.

It would be good to make it have checks in debug mode anyway.

That's part of my intent behind possibly making operator[] safe - basicly, you use at/us when you need (or want) to override the default checking mechanisms. The default implementation argument will be one with operator[] bounds checked. As programs enter maturity, and start being profiled and optimized, the programmer can go back and take out bounds checks where they're not needed, by changing to an "unsafe" implementation.

I will probably add support for forcing bounds checks for all operators to aid in debugging, probably through a define.

so, what's the problem with verbose names for unchecked? Or you worry that no one will [mis]use it?

as about `at_' ,if there's at exist, it tells me , "just like `at' but with some issues".

as about `uat' typo, `u' , `a' , and `.' or `>' is far on keyboard. The only possible typo, it's uat-->at , and it will not create any bugs[grin].

got idea: when really needed let people use
*(array.ptr+10)
for unchecked, certanly fast access.
If array.ptr is not a pointer, or data is storen that it can't be accessed via pointer, you can overload operator+ and operator* .

also i think it's not bad to make
template <typename T, int count> SimpleArray{
}
simple fixed-size array that works like pascal array(can be passed as parameter, etc)

Quote:Original post by MaulingMonkey
On my "Yet Another ::std namespace clone" I am currently working on, I am modifying slightly some of the specifications

If you're modifying the specifications then it's not a clone.

Quote:for a vector, implementing it instead as a vector of pointers to large memory areas, reducing resize costs considerably (and able to release "unused" sub-memory blocks without fear of future performance it).

This sounds like what std::deque does. There is a choice to be made between using a vector and using a deque. Deques are more efficient but vectors are contiguous. So, you can use a vector where a c-style array is expected. For example, you could pass the memory of a std::vector<char> to a function expecting a char*, c-style character array. You couldn't do that with a deque and the user knows that. See this article from C++ Report by Herb Sutter.

What you're suggesting is making this an implementation detail of vector, which actually to be standard you can't do. To be friendly to users, you shouldn't do it either because they won't know whether they can use it in place of a c-style array. It's all to do with the contiguous data. The reason there are different containers is so that the user has to make the informed choice.

Quote:If AT stands for something (and dosn't just refer to "at the index") I'd be interested

'at' means at.

Quote:if anyone has a better name than "us" I'd be interested in that too. It MUST be short, in order to not encourage (much) the use of implementations marked "unsafe" when a safe container would be more appropriate.

The standard library, on the whole, doesn't use abbreviations and spells things out in full instead.

The expected behaviour of indexable containers is that operator[] is unchecked and 'at' is checked. That's what people are used to and I can't see what you will be adding to that by introducing 'us'. operator[] already does that.

See Alexandrescu's yasli::vector. It's described in CUJ June 2004 if you have it or can get it.

Quote:Original post by Dmytry
you worry that no one will [mis]use it?

I worry about this exactly.

Quote:as about `uat' typo,

I'm considering the possibilty that a user will hit the same key twice by accident (very rare but I do this sometimes), once before and once after pressing ".". However, it's so unlikely I may go with that.

Quote:*(array.ptr+10)

Assumes the memory is contiguous.

Quote:Original post by petewood
If you're modifying the specifications then it's not a clone.

Ahh, true that. Just making light of the fact that I do know the ::std namespace exists, and that this may look at first glance like one of the thousands of yearly posts where someone runs into troubles inplementing their own version of ::std::list without even realizing ::std::list exists.

Quote:For example, you could pass the memory of a std::vector<char> to a function expecting a char*, c-style character array

Thanks for the links, I had been unaware that std::vector is guaranteed to be contiguous data. I'll rethink my architecture a bit for my array class.

Quote:The reason there are different containers is so that the user has to make the informed choice.

My current system is still an informed choice - the default implementation is a wrapper arround std::vector, and the only way to change that implementation is via an extra template parameter ala:

array<int,other_implementation<int>>

Quote:The expected behaviour of indexable containers is that operator[] is unchecked and 'at' is checked. That's what people are used to and I can't see what you will be adding to that by introducing 'us'. operator[] already does that.

Two reasons:
1) Newbies often don't know "at" exists. They will use [].
2) Template arguments. If you want to be able to access c-style arrays, you'll have to use operator[], period. There is the whole problem that their code is probably unsafe anyways at that point, but this could help catch mistakes.

Quote:Magmai Kai Holmlor
This functionality is already there:
&*begin()

That works... if the memory is guaranteed to be contiguous (not so for all containers) and is probably not intuitive to the novice user.