Arrays in C++

[Gunslinger08]

I've never dealt with arrays in C++. Can anyone tell me how to find the last element of an array (assuming it doesn't fill the entire space alotted)?

 

[notfred]

You have to keep track of it yourself.

 

[EagleKeeper]

Handling arrays in C++ can be done as you would in C;

the only addition is that there are templates to allow you to manipulate arrays. Essentially, this is a class that will keep track of what you are doing with the array.

 

[bigalt]

yeah, either you can keep a running tally of how much you've entered as a separate variable, or if you only want access to the last element it might be convenient to use a vector or some other stack object.

 

[TerryMathews]

Arrays are by definition fixed boundary data types. The last element would be the length of the array - 1.

 

[Nothinman]

Arrays are by definition fixed boundary data types. The last element would be the length of the array - 1.

I think the idea was to find the last used slot, not the last slot.

 

[Barnaby W. Füi]

If you're using C++, there's probably a better way to go about it, with a vector or something.

 

[Mucman]

Just use vectors... they are safe, and just as fast as arrays (according to Bjarne Stroustrup).

 

[kylef]

Originally posted by: Mucman
Just use vectors... they are safe, and just as fast as arrays (according to Bjarne Stroustrup).

For this simple example, you're probably right.

But in reality, vectors (and the STL in general) are not as fast as using straight C library calls and intrinsic types, primarily because of all the memory allocation the STL performs in the background.

This is especially true with a multi-threaded application: use of the STL can be a serious bottleneck because you'll find that most of your threads are blocked on the C runtime's global heap allocation functions, which serialize threads because they are locked for thread safety.

The only way around this is to overload the STL's allocators to use a separate heap for each thread, and this is non-trivial.

 

[Mucman]

Originally posted by: kylef

Originally posted by: Mucman
Just use vectors... they are safe, and just as fast as arrays (according to Bjarne Stroustrup).

For this simple example, you're probably right.

But in reality, vectors (and the STL in general) are not as fast as using straight C library calls and intrinsic types, primarily because of all the memory allocation the STL performs in the background.

This is especially true with a multi-threaded application: use of the STL can be a serious bottleneck because you'll find that most of your threads are blocked on the C runtime's global heap allocation functions, which serialize threads because they are locked for thread safety.

The only way around this is to overload the STL's allocators to use a separate heap for each thread, and this is non-trivial.

Very good points... of course, it's always a design decision. If the application requires bleeding edge performance, then you
are always going to sacrifice a bit of safety for speed. Personally, I've never had to program anything that requires that kind
of performance so in the general case, vectors will usually do.

 

[glugglug]

Originally posted by: kylef

Originally posted by: Mucman
Just use vectors... they are safe, and just as fast as arrays (according to Bjarne Stroustrup).

For this simple example, you're probably right.

But in reality, vectors (and the STL in general) are not as fast as using straight C library calls and intrinsic types, primarily because of all the memory allocation the STL performs in the background.

This is especially true with a multi-threaded application: use of the STL can be a serious bottleneck because you'll find that most of your threads are blocked on the C runtime's global heap allocation functions, which serialize threads because they are locked for thread safety.

The only way around this is to overload the STL's allocators to use a separate heap for each thread, and this is non-trivial.

STL is not thread safe unless you use separate synchronization objects to keep from using the same STL object in 2 threads at once. The global heap allocation functions are NOT called every time you add an object to the container. The container grabs space for a bunch of objects into its pool and only asks the OS for more when the space it has already requested fills up. So this will in no way end up serializing threads as you suggest.

Actually, for many common applications, like throwing stuff into either a map or a priority_queue to sort it, STL templates end up faster than the normal way of doing things with C because all the container manipulation ends up compiler inlinable, including the overloading of the '<' operator for the container to use, whereas using qsort does a function call for each comparison.

A lot of the common trivial functions I would have expected to be declared as inline in the .h files are in fact calls to DLLs when using VC++.

 

[kylef]

STL is not thread safe unless you use separate synchronization objects to keep from using the same STL object in 2 threads at once. The global heap allocation functions are NOT called every time you add an object to the container. The container grabs space for a bunch of objects into its pool and only asks the OS for more when the space it has already requested fills up.

Correct: I never said that STL itself is thread safe, and it certainly isn't. However, the STL does LOTS of memory allocations in the C runtime in the background that you don't see (unless you run in a debugger and watch what's happening). These allocations do use the C runtime's memory allocator, which is locked for thread safety. This absolutely serializes multi-threaded applications. I'm speaking specifically here of the MSVC implementation of the STL. Other implementations may vary.

I've seen applications which have 10 or more threads using the MSVC STL end up with only 3 or 4 threads unblocked: the rest of the threads were waiting on the mutex locking the C runtime heap allocator. Granted, they were using more STL than just the vector class, which was all that was suggested to the poster here.

In my opinion, the STL is good for small, quick-and-dirty single-threaded apps where a programmer doesn't want to spend time to research better data structures and algorithms. But for real applications, the performance, readability, and debugging penalties of STL are too significant. There are ways around its problems, but you have to know what you're doing, and not many people do. (E.g., for starters I would try plugging in a different STL implementation into MSVC like the one at STLport.org.)

 

[BFG10K]

I've never dealt with arrays in C++. Can anyone tell me how to find the last element of an array (assuming it doesn't fill the entire space alotted)?

You basically have to do it yourself, either with a pointer, index or by writing a special value at the end such as a null '\0'.