-
June 9th, 2014, 02:29 AM
#1
Why certain projects always roll their own data structures/utility classes?
Why certain projects always roll their own data structures/utililiy classes rather than
using the C++ standard libraries? such as linked lists and queues?
Is there a particular reason for this?
Thanks
Jack
Last edited by lucky6969b; June 9th, 2014 at 02:33 AM.
-
June 9th, 2014, 02:31 AM
#2
Re: Why certain projects always roll their own data structures/utililiy classes?
They might predate the standard.
-
June 9th, 2014, 02:34 AM
#3
Re: Why certain projects always roll their own data structures/utility classes?
Okay, that is a good reason.
Thanks
Jack
-
June 9th, 2014, 08:59 AM
#4
Re: Why certain projects always roll their own data structures/utility classes?
Also there may be performance reasons. std is fast, but not in every case.
Nobody cares how it works as long as it works
-
June 9th, 2014, 03:28 PM
#5
Re: Why certain projects always roll their own data structures/utility classes?
And there are other, less complimentary reasons.
-
June 9th, 2014, 11:09 PM
#6
Re: Why certain projects always roll their own data structures/utility classes?
Thanks guys for the explanations
Jack
-
June 16th, 2014, 07:51 AM
#7
Re: Why certain projects always roll their own data structures/utility classes?
and the std does not have every possible imaginable type of container/type wrapped in a class.
and sometimes, whomever wrote the code is just an idiot and thought (s)he could do it better himself when (s)he obviously can't.
-
June 16th, 2014, 08:08 AM
#8
Re: Why certain projects always roll their own data structures/utility classes?
I've reverse engineered versions of STL containers that encapsulate their own fixed size resources.
This was necessary due to the project having real-time and memory constraints. This required the avoidance of dynamic memory allocation.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
-
June 22nd, 2014, 08:51 AM
#9
Re: Why certain projects always roll their own data structures/utililiy classes?
Originally Posted by laserlight
They might predate the standard.
An ongoing example of this is the highlevel libraries built on top of C++ 11 threading, like parallel looping and threadsafe containers. They'll most likely end up in the standard eventually but people don't want to wait so they are rolling their own in the meantime.
Last edited by razzle; June 23rd, 2014 at 01:49 AM.
-
June 22nd, 2014, 10:37 AM
#10
Re: Why certain projects always roll their own data structures/utility classes?
Originally Posted by JohnW@Wessex
I've reverse engineered versions of STL containers that encapsulate their own fixed size resources.
This was necessary due to the project having real-time and memory constraints. This required the avoidance of dynamic memory allocation.
But note that providing custom allocators to STL containers is the standard.
You can quite easily supply your own memory management for individual containers if you have special needs such as hard real-time constraints.
But not only that, you can even replace the default memory allocator that comes with your runtime system. It means you can gain full control of the C++ heap, all within standard C++.
I tried the Intel TBB costum allocator (specialized for fast allocation of small objects in multithreading applications) for a while but then I realized the Microsoft default allocator performed equally well so I switched back. Standard C++ heaps aren't the bottlenecks they used to be.
Last edited by razzle; June 23rd, 2014 at 01:52 AM.
-
June 23rd, 2014, 03:21 AM
#11
Re: Why certain projects always roll their own data structures/utility classes?
Originally Posted by razzle
But note that providing custom allocators to STL containers is the standard.
Yes, I was aware of that, but I discovered that there were severe limitations going down that route with the STL library I was using.
For instance, with a fixed vector implementation you can just reserve a single block of memory for storage. When a resize greater than the current capacity is requested it is perfectly valid to return the starting address of the same block as used before, as you have already allocated all the memory that you will need.
Unfortunately, that STL library throws an error if you return the same address as before because the library designers decided that that was obviously 'wrong'. The only way around it would have been to do what the standard vector does and allocate a new block, copy the data over, delete the old block. This was unacceptable both in memory consumption and performance.
Last edited by JohnW@Wessex; June 23rd, 2014 at 03:33 AM.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
-
June 23rd, 2014, 03:32 AM
#12
Re: Why certain projects always roll their own data structures/utility classes?
Originally Posted by razzle
But not only that, you can even replace the default memory allocator that comes with your runtime system. It means you can gain full control of the C++ heap, all within standard C++.
Standard C++ heaps aren't the bottlenecks they used to be.
It's not hat the heap is a bottleneck. In an embedded environment, the heap is rarely used, if at all, due to the designers needing to have a tight grip on memory usage. Using the heap makes it very difficult to prove that your device will never run out of memory. That's why creating containers that define their own storage at compile time is attractive.
The STL contains a lot of really nice stuff, it's just that for embedded designers, some parts are not quite as useful as they would like them to (or could) be.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|