We should add a note to the style guide. I think that the STL/TR1 is fine
for non-critical path,
but I wouldn't go so far as to rewrite currently working code. The STL
tends to hide costs
and tends to use algorithms with relatively high constant but low asymptotic
costs by default
which makes tun
I understand the issue with allocation and critical path. Fortunately my
current intended use is in an optional, non-critical path case.
Are there any concerns about exception safety? Should I take care to wrap any
potentially allocating calls in try/catch to handle out of memory conditions?
Or
On 07/24/2010 06:44 PM, Alan M. Carroll wrote:
Is it an official policy to not use STL, or is that just a legacy of ATS's C
heritage?
I think this is mostly "heritage", but care should definitely be taken.
ATS makes a big effort to avoid memory allocations on the heap in the
critical path,
I guess if all you ever use is GCC/G++, then C++ isn't so bad.
However, if you actually want to write a portable application *and*
support non-GNU compilers which may support a special target or is
optimized (think: Intel's compilers) ... most C compiler implementations
are pretty much surprise-f
But doesn't that apply just as well to C++, or even C?
Saturday, July 24, 2010, 8:06:01 PM, you wrote:
> It seems like the only thing "S" about "STL" is the specification, not
> in implementation
It seems like the only thing "S" about "STL" is the specification, not
in implementation -- this is why you have hell-on-earth like STLport.
Or, people throwing in the kitchen sink (!) and using a monstrosity like
Boost. (Seriously, there are whole operating systems that aren't as
enormous as Bo
