4 ms·

FWIW, Donald Knuth was a proponent of using C over C++ at the time it first came out. He equated C++ with the use of frameworks in writing programs which he tho

FWIW, Donald Knuth was a proponent of using C over C++ at the time it first came out. He equated C++ with the use of frameworks in writing programs which he thought were a bad idea for the profession as it would dumb it down. C++ does make code reuse a lot easier.

overgard 9y ago
> C++ does make code reuse a lot easier. Not really, with ABI issues and compiler incompatibility widely used C++ libs are either header-only, or have an "extern C" version of the public API. Id say C++ makes reuse much harder.
- aidenn0 9y ago
  1) ABI issues and compiler incompatibility hasn't been a problem for 5-10 years (using two compilers for a single binary is relatively rare). 2) Being "header-only" is no impediment to code reuse.
  - elderK 9y ago
    Hey there Aidenn0, I'm no expert on C++ and I've been considering using it for several projects. An important thing for my needs is being able to define classes in one shared object and create new subtypes of those classes in another, possibly defining overrides on virtual methods and such. A good friend of mine has said similar things as you - that the ABI issue has not been a major obstacle for some time. And yet, as much as I search, I still find the same-old advice: Don't use STL types in your interfaces or throw exceptions across module boundaries. If all the compilers used for a given platform follow the same ABI, would using a separate and specific STL implementation (say, STLport) instead alleviate that particular issue? Sorry if this question seems a bit rambley but I'd really love to find out how to use C++ in the way I've mentioned.
    - khitchdee 9y ago
      Partly this depends on the platform. C++ is well supported on Microsoft's .NET platform where you can access all the functionality of the .NET libraries through C++. STL, I guess, is more used on Linux. I would advise against trying to use portable libraries and instead using libraries designed for the platform you are targeting. Having said that, a good portable UI library is the open source WxWidgets which is accessible through C++ for OSX, Linux, Windows
    - aidenn0 9y ago
      If you use the same compiler, ABI is a non-issue. If you want to distribute dynamic-link binaries for windows, use MSVC. If you want to distribute dynamic-link binaries for OS X, use Xcode. If you want to distribute dynamic-link binaries for linux, you are SOL regardless of whether or not you are using C++, but if you use the same compiler and flags that the latest LTS version of Ubuntu uses, then it will work on Ubuntu, and will be made to work anywhere that Steam works. It used to be that there were at least two C++ compilers for each *nix (typically GNU and something cfront based), so ABI was a much bigger deal. When "Modern C++ Design" came out, famously none of the compilers could correctly compile all of the sample code. Since then things are much better; not that all compilers are bug-free of course, but they are sufficiently good enough that if you report a bug, you can expect it to be fixed. [EDIT] "Don't use STL Types in your interfaces" is not advice I've heard in like 15 years; I more often hear "If you're using a C array instead of a Vector, you're doing it wrong" "Don't throw exceptions across module boundaries" seems similarly odd. Unless your constructors are inlined, no modern code-base will follow that rule because RAII relies so strongly on exceptions. There are coding styles that are opposed to exceptions as part of an external interface, but that's due to exceptions not being checked as part of the type system, and is not what I would call a majority opinion.
      - elderK 9y ago
        Thanks for the response. To clarify "module boundaries", I mean "separate shared objects." As for Linux, I'm not too concerned with creating a single binary that works for all distributions. I'm more concerned with someone being able to build a set of shared libraries on their distribution of choice and those shared libraries being able to interact naturally regardless of which compiler s/he uses to build each of them. Say, LibA is built using LLVM. LibB is built using G++ and LibC is built using ICC. LibA defines several classes. LibB creates some subtypes. LibC instantiates types from both LibA and LibB. All the functions present in LibA, LibB, LibC make use of STL types such as std::string, std::vector, etc. Some may throw exceptions, whatever. With respect to MSVC, I've read that compatibility between Debug and Release builds is kind of suspect, especially if you're using STL types. Not to mention differences in MSVC version. Is this still a concern?
  - overgard 9y ago
    1) Ever try to upgrade msvc versions? It's always a huge problem if you're using libraries you don't have source for. Not to mention the 50 million linker issues if one library is linked statically and the rest dynamic. There are still people on like msvc 6 because of this. 2) Header only libraries are horrible for compile times, especially heavily templated ones (and if you use c++ generics it basically has to be a header library). The reason boost is banned from a lot of cpp projects isn't because the library is bad, it's because of compile time.
khitchdee 9y ago
As an example of C++ making code reuse a lot easier, consider the Windows platform from a developer's perspective. Before C++, there was this huge library called Win32 in C that contained several hundred functions and data structures to access the services of the platform. Since it was not object oriented, there was a fat book by Charles Petzold, which was like a Bible for windows programmers that described how each of the functions related to each other, in what sequence to call them and a bunch of stuff that was not even documented by Microsoft. Once C++ came, there was a library called MFC which was object oriented and hence a lot better documented and organised and now there's .NET. The organization of functions into objects makes it a lot easier to understand systems software specially if it's very large. Also the ability to subclass means you can take the base functionality of "template" classes provided by a library and subclass them to extend them with what you need. This was not as easy with C where you had to rely on sample code for this purpose. The Petzold book had a ton of sample code.

overgard 9y ago

> C++ does make code reuse a lot easier. Not really, with ABI issues and compiler incompatibility widely used C++ libs are either header-only, or have an "extern C" version of the public API. Id say C++ makes reuse much harder.

aidenn0 9y ago
1) ABI issues and compiler incompatibility hasn't been a problem for 5-10 years (using two compilers for a single binary is relatively rare). 2) Being "header-only" is no impediment to code reuse.
- elderK 9y ago
  Hey there Aidenn0, I'm no expert on C++ and I've been considering using it for several projects. An important thing for my needs is being able to define classes in one shared object and create new subtypes of those classes in another, possibly defining overrides on virtual methods and such. A good friend of mine has said similar things as you - that the ABI issue has not been a major obstacle for some time. And yet, as much as I search, I still find the same-old advice: Don't use STL types in your interfaces or throw exceptions across module boundaries. If all the compilers used for a given platform follow the same ABI, would using a separate and specific STL implementation (say, STLport) instead alleviate that particular issue? Sorry if this question seems a bit rambley but I'd really love to find out how to use C++ in the way I've mentioned.
  - khitchdee 9y ago
    Partly this depends on the platform. C++ is well supported on Microsoft's .NET platform where you can access all the functionality of the .NET libraries through C++. STL, I guess, is more used on Linux. I would advise against trying to use portable libraries and instead using libraries designed for the platform you are targeting. Having said that, a good portable UI library is the open source WxWidgets which is accessible through C++ for OSX, Linux, Windows
  - aidenn0 9y ago
    If you use the same compiler, ABI is a non-issue. If you want to distribute dynamic-link binaries for windows, use MSVC. If you want to distribute dynamic-link binaries for OS X, use Xcode. If you want to distribute dynamic-link binaries for linux, you are SOL regardless of whether or not you are using C++, but if you use the same compiler and flags that the latest LTS version of Ubuntu uses, then it will work on Ubuntu, and will be made to work anywhere that Steam works. It used to be that there were at least two C++ compilers for each *nix (typically GNU and something cfront based), so ABI was a much bigger deal. When "Modern C++ Design" came out, famously none of the compilers could correctly compile all of the sample code. Since then things are much better; not that all compilers are bug-free of course, but they are sufficiently good enough that if you report a bug, you can expect it to be fixed. [EDIT] "Don't use STL Types in your interfaces" is not advice I've heard in like 15 years; I more often hear "If you're using a C array instead of a Vector, you're doing it wrong" "Don't throw exceptions across module boundaries" seems similarly odd. Unless your constructors are inlined, no modern code-base will follow that rule because RAII relies so strongly on exceptions. There are coding styles that are opposed to exceptions as part of an external interface, but that's due to exceptions not being checked as part of the type system, and is not what I would call a majority opinion.
    - elderK 9y ago
      Thanks for the response. To clarify "module boundaries", I mean "separate shared objects." As for Linux, I'm not too concerned with creating a single binary that works for all distributions. I'm more concerned with someone being able to build a set of shared libraries on their distribution of choice and those shared libraries being able to interact naturally regardless of which compiler s/he uses to build each of them. Say, LibA is built using LLVM. LibB is built using G++ and LibC is built using ICC. LibA defines several classes. LibB creates some subtypes. LibC instantiates types from both LibA and LibB. All the functions present in LibA, LibB, LibC make use of STL types such as std::string, std::vector, etc. Some may throw exceptions, whatever. With respect to MSVC, I've read that compatibility between Debug and Release builds is kind of suspect, especially if you're using STL types. Not to mention differences in MSVC version. Is this still a concern?
- overgard 9y ago
  1) Ever try to upgrade msvc versions? It's always a huge problem if you're using libraries you don't have source for. Not to mention the 50 million linker issues if one library is linked statically and the rest dynamic. There are still people on like msvc 6 because of this. 2) Header only libraries are horrible for compile times, especially heavily templated ones (and if you use c++ generics it basically has to be a header library). The reason boost is banned from a lot of cpp projects isn't because the library is bad, it's because of compile time.

khitchdee 9y ago

As an example of C++ making code reuse a lot easier, consider the Windows platform from a developer's perspective. Before C++, there was this huge library called Win32 in C that contained several hundred functions and data structures to access the services of the platform. Since it was not object oriented, there was a fat book by Charles Petzold, which was like a Bible for windows programmers that described how each of the functions related to each other, in what sequence to call them and a bunch of stuff that was not even documented by Microsoft. Once C++ came, there was a library called MFC which was object oriented and hence a lot better documented and organised and now there's .NET. The organization of functions into objects makes it a lot easier to understand systems software specially if it's very large. Also the ability to subclass means you can take the base functionality of "template" classes provided by a library and subclass them to extend them with what you need. This was not as easy with C where you had to rely on sample code for this purpose. The Petzold book had a ton of sample code.