5 ms·

One of the problems with structs in C, is that you must explicitly call the destructor function if you have non-memory resources. In C++, a scope's closing } al

by dmpk2k 12y ago

One of the problems with structs in C, is that you must explicitly call the destructor function if you have non-memory resources. In C++, a scope's closing } always takes care of that for you. As for the generated code bit, I assume you're referring to the STL. Writing my own data structures is explicitly what I don't want to do anymore. STL has it? Great, I use it and move on.

harry8 12y ago
Sure use it if you understand it, ie vector where you reserve the memory up front to avoid future allocations and pointer/iterator invalidations or you don't care in which case use a friendlier or more powerful language maybe? Writing datastructures is much of what programming is, I know that's not what you meant and you use the basics of STL to build the real datastructure you want, but you care about performance and with STL it's not targeted at your case so when you get beyond prototype you have to rip it out anyway. Automatic destructor calls on leaving scope is the nicest part of c++ - shame it interacts with exceptions so nastily that nobody understands how it works. "Exception safe code" yeah, right, not in c++. Generated code - you can use macros, you can use templates. Or you can use anything that generates text and does what you want, more nicely than that.
- maxlybbert 12y ago
  > Sure use it if you understand it, ie vector where you reserve the memory up front to avoid future allocations and pointer/iterator invalidations or you don't care in which case use a friendlier or more powerful language maybe? std::vector implements one of the simplest data structures in computer science. If somebody doesn't understand the difference between, say, an array (however you want to call it) and a linked list, I don't want them on my team. > Writing datastructures is much of what programming is, I know that's not what you meant and you use the basics of STL to build the real datastructure you want, but you care about performance and with STL it's not targeted at your case so when you get beyond prototype you have to rip it out anyway. What are you talking about? More than a decade ago, there was a lot of interest in what kind of penalty there was in using C++ compared to C. There were several benchmarks run and papers written, including one from Alexander Stepanov (main contributor to the STL) that became an appendix to the standard ( http://std.dkuug.dk/JTC1/SC22/WG21/docs/PDTR18015.pdf http://std.dkuug.dk/JTC1/SC22/WG21/docs/PDTR18015.pdf ). The conclusion from the various experiments was that C++ performance was on par with C, and C++ often provided opportunities to optimize more than C did (e.g., passing a pointer to a function in C to the more common C++ practice of passing a functor with an inlineable operator()). The STL relies on those features that allow for a very efficient implementation. In fact, the main complaint I've seen is that the STL struck the wrong balance of preferring efficiency over generality ( http://www.open-std.org/JTC1/SC22/wg21/docs/papers/2007/n2271.html http://www.open-std.org/JTC1/SC22/wg21/docs/papers/2007/n227... , http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1850.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n185... ). > Automatic destructor calls on leaving scope is the nicest part of c++ - shame it interacts with exceptions so nastily that nobody understands how it works. "Exception safe code" yeah, right, not in c++. A decade ago, there was a period of maybe six months where people thought it might be impossible to write exception safe code in C++. It was solved, and the solution was to use destructors. You may have heard of RAII ( http://stroustrup.com/except.pdf http://stroustrup.com/except.pdf ). Alexandrescu even made it incredibly simple to do ( http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758 http://www.drdobbs.com/cpp/generic-change-the-way-you-write-... ). > Generated code - you can use macros, you can use templates. Or you can use anything that generates text and does what you want, more nicely than that. So I have a choice between using templates, which provide syntax checking and type checking, or generating text in an ad-hoc way? And you actually recommend monkeying with text generation? For what it's worth, I do like C. But when I work in C, I need to rely on something like Apache's APR or GNU's glib to provide me with useful data structures. While those have been ported to all architectures I care about, there's something to be said for having data structures in the core library. I like C11. I like using _Generic in macros. I like variable argument macros. But if I'm working on a project where I need variable argument macros, I'm much more likely to pick C++ than to try to convince myself that I'm generating correct source code through macros.
  - yongjik 12y ago
    > std::vector implements one of the simplest data structures in computer science. It may "implement" one of the simplest DS, but this particular implementation is anything but trivial to use. You can get a pointer to an element in it, and keep using the vector, and the pointer will point to the correct element... until you push_back() one too many element, it resizes, and then suddenly your pointer is invalid. But if you reserve() the right amount of space, you can keep it valid! If you are very careful. But then you don't want to call reserve() too often because it may actually turn your O(N) algorithm into O(N^2)! (Basically, calling reserve() N times on O(N) length vector takes O(N^2) time, while doing push_back() N times is guaranteed to be O(N).) Sure, std::vector is useful, and I use it all the time, but it is anything but simple. It's C++ after all. :)
    - dmpk2k 12y ago
      You have the similar problems if you build your own resizeable arrays in C, unless you resort to an extra level of indirection (e.g. an array of pointers, or pointers to array chunks). std::vector has a series of gotchas, but any generic resizeable array which has similar performance will have similar gotchas; std::vector wasn't made that way just for giggles.
    - nly 12y ago
      boost::stable_vector[0] isn't a bad middle ground between a linked list and a vector if you just want iterator stability and better exception safety (for types that throw when moved or copied) [0] http://www.boost.org/doc/libs/1_57_0/doc/html/boost/container/stable_vector.html http://www.boost.org/doc/libs/1_57_0/doc/html/boost/containe...
    - maxlybbert 12y ago
      dmpk2k is right: the requirements on iterator validity are the obvious consequences of using a reallocatable array. Replace a std::vector with malloc-ed memory and call realloc every so often, and you'll find your pointers to elements in the array don't stay valid. It's not a gratuitous problem; you'd run into it no matter how you implement your grow able array. Interestingly, keeping track of indexes into the array avoids the issue completely.

by dmpk2k 12y ago

harry8 12y ago

Sure use it if you understand it, ie vector where you reserve the memory up front to avoid future allocations and pointer/iterator invalidations or you don't care in which case use a friendlier or more powerful language maybe? Writing datastructures is much of what programming is, I know that's not what you meant and you use the basics of STL to build the real datastructure you want, but you care about performance and with STL it's not targeted at your case so when you get beyond prototype you have to rip it out anyway. Automatic destructor calls on leaving scope is the nicest part of c++ - shame it interacts with exceptions so nastily that nobody understands how it works. "Exception safe code" yeah, right, not in c++. Generated code - you can use macros, you can use templates. Or you can use anything that generates text and does what you want, more nicely than that.

maxlybbert 12y ago
> Sure use it if you understand it, ie vector where you reserve the memory up front to avoid future allocations and pointer/iterator invalidations or you don't care in which case use a friendlier or more powerful language maybe? std::vector implements one of the simplest data structures in computer science. If somebody doesn't understand the difference between, say, an array (however you want to call it) and a linked list, I don't want them on my team. > Writing datastructures is much of what programming is, I know that's not what you meant and you use the basics of STL to build the real datastructure you want, but you care about performance and with STL it's not targeted at your case so when you get beyond prototype you have to rip it out anyway. What are you talking about? More than a decade ago, there was a lot of interest in what kind of penalty there was in using C++ compared to C. There were several benchmarks run and papers written, including one from Alexander Stepanov (main contributor to the STL) that became an appendix to the standard ( http://std.dkuug.dk/JTC1/SC22/WG21/docs/PDTR18015.pdf http://std.dkuug.dk/JTC1/SC22/WG21/docs/PDTR18015.pdf ). The conclusion from the various experiments was that C++ performance was on par with C, and C++ often provided opportunities to optimize more than C did (e.g., passing a pointer to a function in C to the more common C++ practice of passing a functor with an inlineable operator()). The STL relies on those features that allow for a very efficient implementation. In fact, the main complaint I've seen is that the STL struck the wrong balance of preferring efficiency over generality ( http://www.open-std.org/JTC1/SC22/wg21/docs/papers/2007/n2271.html http://www.open-std.org/JTC1/SC22/wg21/docs/papers/2007/n227... , http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1850.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n185... ). > Automatic destructor calls on leaving scope is the nicest part of c++ - shame it interacts with exceptions so nastily that nobody understands how it works. "Exception safe code" yeah, right, not in c++. A decade ago, there was a period of maybe six months where people thought it might be impossible to write exception safe code in C++. It was solved, and the solution was to use destructors. You may have heard of RAII ( http://stroustrup.com/except.pdf http://stroustrup.com/except.pdf ). Alexandrescu even made it incredibly simple to do ( http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758 http://www.drdobbs.com/cpp/generic-change-the-way-you-write-... ). > Generated code - you can use macros, you can use templates. Or you can use anything that generates text and does what you want, more nicely than that. So I have a choice between using templates, which provide syntax checking and type checking, or generating text in an ad-hoc way? And you actually recommend monkeying with text generation? For what it's worth, I do like C. But when I work in C, I need to rely on something like Apache's APR or GNU's glib to provide me with useful data structures. While those have been ported to all architectures I care about, there's something to be said for having data structures in the core library. I like C11. I like using _Generic in macros. I like variable argument macros. But if I'm working on a project where I need variable argument macros, I'm much more likely to pick C++ than to try to convince myself that I'm generating correct source code through macros.
- yongjik 12y ago
  > std::vector implements one of the simplest data structures in computer science. It may "implement" one of the simplest DS, but this particular implementation is anything but trivial to use. You can get a pointer to an element in it, and keep using the vector, and the pointer will point to the correct element... until you push_back() one too many element, it resizes, and then suddenly your pointer is invalid. But if you reserve() the right amount of space, you can keep it valid! If you are very careful. But then you don't want to call reserve() too often because it may actually turn your O(N) algorithm into O(N^2)! (Basically, calling reserve() N times on O(N) length vector takes O(N^2) time, while doing push_back() N times is guaranteed to be O(N).) Sure, std::vector is useful, and I use it all the time, but it is anything but simple. It's C++ after all. :)
  - dmpk2k 12y ago
    You have the similar problems if you build your own resizeable arrays in C, unless you resort to an extra level of indirection (e.g. an array of pointers, or pointers to array chunks). std::vector has a series of gotchas, but any generic resizeable array which has similar performance will have similar gotchas; std::vector wasn't made that way just for giggles.
  - nly 12y ago
    boost::stable_vector[0] isn't a bad middle ground between a linked list and a vector if you just want iterator stability and better exception safety (for types that throw when moved or copied) [0] http://www.boost.org/doc/libs/1_57_0/doc/html/boost/container/stable_vector.html http://www.boost.org/doc/libs/1_57_0/doc/html/boost/containe...
  - maxlybbert 12y ago
    dmpk2k is right: the requirements on iterator validity are the obvious consequences of using a reallocatable array. Replace a std::vector with malloc-ed memory and call realloc every so often, and you'll find your pointers to elements in the array don't stay valid. It's not a gratuitous problem; you'd run into it no matter how you implement your grow able array. Interestingly, keeping track of indexes into the array avoids the issue completely.