4 ms·

I'd miss the STL more than anything. It's so much nicer than any of the remotely comparable C data structure + algorithm libraries. That plus RAII are enough to

I'd miss the STL more than anything. It's so much nicer than any of the remotely comparable C data structure + algorithm libraries. That plus RAII are enough to keep me on the C++ side.

sillysaurus3 12y ago
Alternatively, the STL is so bloated and there are so many ways to mess up RAII that it's enough to keep me on the C side. Where I sell C shells.
- cageface 12y ago
  The STL is actually pretty lean compared to the standard libraries that ship with most popular programming languages these days and if you leave the iostream stuff out it's fast and doesn't take up much space in the binary. I've used it with great results on iOS devices. My first step in creating any new class is subclassing a no-copy parent, which in my experience eliminates most of the nasty gotchas with accidental copies. I have yet to get any RAII weirdness. I've considered reverting to plain C to make it easier to interface with other languages like pure ObjC and now Swift but when I think about how much extra work this is going to entail for absolutely zero benefit to my users I always give up the idea.
  - sillysaurus3 12y ago
    My first step in creating any new class is subclassing a no-copy parent That's exactly why, when presented with a choice between C or C++, I'll choose C every time. First, because it's often inexperience with other paradigms that forces programmers into an "everything must be an object" mindset. Second, because the fact that you need to learn a gargantuan amount of trivia to use C++ inheritance non-dangerously is a sign of underlying derangement. Third, because through experience I've learned that C is far less scary once you embrace standard patterns for accomplishing various tasks. The total linecount isn't significantly increased by using C over C++. The codebase complexity isn't increased. What I like about C is that it gives you a set of inalienable commandments: thou shalt not go completely nuts with {inheritance, template metaprogramming, flavor du jour}, because you can't. In the hands of an experienced programmer, C gives you more reliability than C++ precisely because there are fewer gotchas. The dangers are straightforward: free memory after you use it; have a single place that a pointer is "owned"; check your lengths before copying between buffers.
    - cageface 12y ago
      I actually very rarely create class hierarchies in C++. I do, however, define and implement interfaces and this is a simple, no-brainer technique that eliminates a whole class of gotchas when I do it. The total linecount isn't significantly increased by using C over C++. The codebase complexity isn't increased. This I can't agree with at all. If I had to rewrite my current codebase in C it would be substantially larger and buggier and much less flexible. I know because I've tried this experiment already. This is even more the case with the C++11 syntax enhancements, which reduce the verbosity of C++ a lot. My only real complaint with C++ is that it lacks a proper ABI so I have to wrap it in C if I want to use it from another language. This wasn't a big deal when I could rely on Obj-C++ but Apple's new Swift language has thrown a bit of a wrench in this scheme.
      - sillysaurus3 12y ago
        This is even more the case with the C++11 syntax enhancements, which reduce the verbosity of C++ a lot. Maybe true. I bailed from the C++ world before C++11 became pervasive. But if you use C++11 you risk leaving VS2010 users (and below) in a situation where they can't use your code at all: http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-... And C++14? No idea what version of VS supports it. But using C++14 will definitely mess with people who have older compilers. And those people don't always have the luxury of just buying the latest version of VS. Who cares about Windows? Well, anyone who's into the open source movement should be sympathetic to people who are forced to use a certain operating system but still want to get into programming. The spark for people's desire to become programmers often starts by wanting to customize their environment. That leads them to shell scripting, which is a stepping off point into more advanced programming. The main point is simply that the C++ ecosystem has so many "gotchas" and timesinks that when forced to choose between C++ and C, an experienced programmer will save time with C, mainly because their years-old patterns will work regardless of what environment they're in. There are still some gotchas, of course; you can't use unix signals and expect them to be cross-platform. But it's far more straightforward than trying to get your codebase compiling on five different compilers. Of course, choosing Python or some higher level language is almost always the best cost/benefit tradeoff.
Peaker 12y ago
The STL has huge mistakes like the completely useless "std::list". It also does a whole lot of unnecessary dynamic allocations due to the non-intrusive style used for all of its containers. I think the STL might be overhyped.
- cageface 12y ago
  95% of my use cases are satisfied by std::vector and std::map. Neither one has ever even shown up as a tiny blip in my performance traces, even in debug builds. If you really really need intrusive containers you can get them from boost. Like anything in decades of heavy commercial use it has some warts but at least C++ gives you the control you need to write fast code at a reasonable level of abstraction.
  - Peaker 12y ago
    I wasn't dissing C++ here (though I do believe C++ has quite a few downfalls..), just the STL. std::vector is completely reasonable implementation for a dynamic vector. std::map is somewhat unreasonable, because its non-intrusiveness requires dynamic allocations, more indirections, and more expensive deletions. std::list is useless, so when you do want linked lists, you end up using the wrong data structure, because list is out of the lexicon.
- srean 12y ago
  It would help if you could point me to something that is better than STL (in performance and ease of use) and addresses the full scope of STL. I have asked this a few times, but all I have got so far is cricket chirps or pointers to worse bloatware. Not claiming that such a thing does not exist, rather would be happy to give such a thing a try. It would also lend more heft to your comment.
  - mtdewcmu 12y ago
    Any library that addresses exactly the same use case as STL is going to have the same limitations as STL. Everything is a trade-off. I think you can probably assume that STL does about as good a job as any library would, given identical trade-offs. Note that the actual implementations will vary by platform and compiler.

I'd miss the STL more than anything. It's so much nicer than any of the remotely comparable C data structure + algorithm libraries. That plus RAII are enough to keep me on the C++ side.

sillysaurus3 12y ago

Alternatively, the STL is so bloated and there are so many ways to mess up RAII that it's enough to keep me on the C side. Where I sell C shells.

cageface 12y ago
The STL is actually pretty lean compared to the standard libraries that ship with most popular programming languages these days and if you leave the iostream stuff out it's fast and doesn't take up much space in the binary. I've used it with great results on iOS devices. My first step in creating any new class is subclassing a no-copy parent, which in my experience eliminates most of the nasty gotchas with accidental copies. I have yet to get any RAII weirdness. I've considered reverting to plain C to make it easier to interface with other languages like pure ObjC and now Swift but when I think about how much extra work this is going to entail for absolutely zero benefit to my users I always give up the idea.
- sillysaurus3 12y ago
  My first step in creating any new class is subclassing a no-copy parent That's exactly why, when presented with a choice between C or C++, I'll choose C every time. First, because it's often inexperience with other paradigms that forces programmers into an "everything must be an object" mindset. Second, because the fact that you need to learn a gargantuan amount of trivia to use C++ inheritance non-dangerously is a sign of underlying derangement. Third, because through experience I've learned that C is far less scary once you embrace standard patterns for accomplishing various tasks. The total linecount isn't significantly increased by using C over C++. The codebase complexity isn't increased. What I like about C is that it gives you a set of inalienable commandments: thou shalt not go completely nuts with {inheritance, template metaprogramming, flavor du jour}, because you can't. In the hands of an experienced programmer, C gives you more reliability than C++ precisely because there are fewer gotchas. The dangers are straightforward: free memory after you use it; have a single place that a pointer is "owned"; check your lengths before copying between buffers.
  - cageface 12y ago
    I actually very rarely create class hierarchies in C++. I do, however, define and implement interfaces and this is a simple, no-brainer technique that eliminates a whole class of gotchas when I do it. The total linecount isn't significantly increased by using C over C++. The codebase complexity isn't increased. This I can't agree with at all. If I had to rewrite my current codebase in C it would be substantially larger and buggier and much less flexible. I know because I've tried this experiment already. This is even more the case with the C++11 syntax enhancements, which reduce the verbosity of C++ a lot. My only real complaint with C++ is that it lacks a proper ABI so I have to wrap it in C if I want to use it from another language. This wasn't a big deal when I could rely on Obj-C++ but Apple's new Swift language has thrown a bit of a wrench in this scheme.
    - sillysaurus3 12y ago
      This is even more the case with the C++11 syntax enhancements, which reduce the verbosity of C++ a lot. Maybe true. I bailed from the C++ world before C++11 became pervasive. But if you use C++11 you risk leaving VS2010 users (and below) in a situation where they can't use your code at all: http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-language-features-in-vc10-the-table.aspx http://blogs.msdn.com/b/vcblog/archive/2010/04/06/c-0x-core-... And C++14? No idea what version of VS supports it. But using C++14 will definitely mess with people who have older compilers. And those people don't always have the luxury of just buying the latest version of VS. Who cares about Windows? Well, anyone who's into the open source movement should be sympathetic to people who are forced to use a certain operating system but still want to get into programming. The spark for people's desire to become programmers often starts by wanting to customize their environment. That leads them to shell scripting, which is a stepping off point into more advanced programming. The main point is simply that the C++ ecosystem has so many "gotchas" and timesinks that when forced to choose between C++ and C, an experienced programmer will save time with C, mainly because their years-old patterns will work regardless of what environment they're in. There are still some gotchas, of course; you can't use unix signals and expect them to be cross-platform. But it's far more straightforward than trying to get your codebase compiling on five different compilers. Of course, choosing Python or some higher level language is almost always the best cost/benefit tradeoff.

Peaker 12y ago

The STL has huge mistakes like the completely useless "std::list". It also does a whole lot of unnecessary dynamic allocations due to the non-intrusive style used for all of its containers. I think the STL might be overhyped.

cageface 12y ago
95% of my use cases are satisfied by std::vector and std::map. Neither one has ever even shown up as a tiny blip in my performance traces, even in debug builds. If you really really need intrusive containers you can get them from boost. Like anything in decades of heavy commercial use it has some warts but at least C++ gives you the control you need to write fast code at a reasonable level of abstraction.
- Peaker 12y ago
  I wasn't dissing C++ here (though I do believe C++ has quite a few downfalls..), just the STL. std::vector is completely reasonable implementation for a dynamic vector. std::map is somewhat unreasonable, because its non-intrusiveness requires dynamic allocations, more indirections, and more expensive deletions. std::list is useless, so when you do want linked lists, you end up using the wrong data structure, because list is out of the lexicon.
srean 12y ago
It would help if you could point me to something that is better than STL (in performance and ease of use) and addresses the full scope of STL. I have asked this a few times, but all I have got so far is cricket chirps or pointers to worse bloatware. Not claiming that such a thing does not exist, rather would be happy to give such a thing a try. It would also lend more heft to your comment.
- mtdewcmu 12y ago
  Any library that addresses exactly the same use case as STL is going to have the same limitations as STL. Everything is a trade-off. I think you can probably assume that STL does about as good a job as any library would, given identical trade-offs. Note that the actual implementations will vary by platform and compiler.