3 ms·

Talking to one of my professors, his experience is that if you get deep enough into C++ and use the STL, you get around the same performance as Java. I'm not a

Talking to one of my professors, his experience is that if you get deep enough into C++ and use the STL, you get around the same performance as Java. I'm not a big C++ or Java programmer, so I have no first-hand experience, but I found that to be interesting.

cageface 16y ago
I certainly haven't found that to be the case for my routine uses of the STL. Vector iteration, map lookup, applications of the various STL algorithms etc are all very fast in the code in which I've put them to use. Maybe this doesn't hold for more sophisticated uses. For example, I see no discernible overhead at all in iterating through an std::vector vs a bare C array.
- DaveMebs 16y ago
  The STL does lead to increased memory consumption and code bloat, however. It is wholly unacceptable to use the STL in any embedded system, or kernel-level OS code.
  - blub 16y ago
    That is incorrect. It is not used (or rather a standard STL is not used) because it depends on exceptions and dynamic memory allocations. The STL code is highly optimized and there should be no technical reason why it would consume more memory or lead to code bloat.
    - zwieback 16y ago
      My experience exactly. The STL==code-bloat argument is really not valid but avoiding STL in smaller embedded systems due to exceptions+new/malloc is reasonable. Once you have a MMU and megabytes of RAM the balance may shift but you still have to worry about realtime behavior.
      - jimwise 16y ago
        Right. This is why Ada, which has always paid special attention to the needs of embedded systems, provides so many guarantees about what program behaviors are and are not allowed to cause allocations or exceptions. The upcoming Ada 2012 standard even includes versions of Ada 2005's collection classes which are allocation-free (read: pre-allocated to a size specified at creation time, and guaranteed not to perform allocation after that point). Ada's generic programming was a big influence on Stepanov's design of what became the STL (the first versions were a port of work he had done under Ada). Ironically, the Ada standards process moved so slowly that by the time Ada grew standards-mandated generic collection classes (previously this was something all vendors provided as an extension), it had time to learn the lessons of STL. (Not a knock on STL, by the way -- STL's implementors have learned a lot over the life of the standard as well.)
Jach 16y ago
This was also true in 2003. http://scribblethink.org/Computer/javaCbenchmark.html http://scribblethink.org/Computer/javaCbenchmark.html It wouldn't surprise me if there were many areas that Java outperforms C++ nowadays.
- blub 16y ago
  You have linked to a known poor/very old benchmark. And for the record, there aren't many areas where Java outperforms C++ today.

cageface 16y ago

I certainly haven't found that to be the case for my routine uses of the STL. Vector iteration, map lookup, applications of the various STL algorithms etc are all very fast in the code in which I've put them to use. Maybe this doesn't hold for more sophisticated uses. For example, I see no discernible overhead at all in iterating through an std::vector vs a bare C array.

DaveMebs 16y ago
The STL does lead to increased memory consumption and code bloat, however. It is wholly unacceptable to use the STL in any embedded system, or kernel-level OS code.
- blub 16y ago
  That is incorrect. It is not used (or rather a standard STL is not used) because it depends on exceptions and dynamic memory allocations. The STL code is highly optimized and there should be no technical reason why it would consume more memory or lead to code bloat.
  - zwieback 16y ago
    My experience exactly. The STL==code-bloat argument is really not valid but avoiding STL in smaller embedded systems due to exceptions+new/malloc is reasonable. Once you have a MMU and megabytes of RAM the balance may shift but you still have to worry about realtime behavior.
    - jimwise 16y ago
      Right. This is why Ada, which has always paid special attention to the needs of embedded systems, provides so many guarantees about what program behaviors are and are not allowed to cause allocations or exceptions. The upcoming Ada 2012 standard even includes versions of Ada 2005's collection classes which are allocation-free (read: pre-allocated to a size specified at creation time, and guaranteed not to perform allocation after that point). Ada's generic programming was a big influence on Stepanov's design of what became the STL (the first versions were a port of work he had done under Ada). Ironically, the Ada standards process moved so slowly that by the time Ada grew standards-mandated generic collection classes (previously this was something all vendors provided as an extension), it had time to learn the lessons of STL. (Not a knock on STL, by the way -- STL's implementors have learned a lot over the life of the standard as well.)

Jach 16y ago

This was also true in 2003. http://scribblethink.org/Computer/javaCbenchmark.html http://scribblethink.org/Computer/javaCbenchmark.html It wouldn't surprise me if there were many areas that Java outperforms C++ nowadays.

blub 16y ago
You have linked to a known poor/very old benchmark. And for the record, there aren't many areas where Java outperforms C++ today.