3 ms·

>The term "C/C++" is a Tool of the Devil. Each has its many endearing qualities but it is inappropriate to put them together like that. I do understand the com

by jasode 11y ago

>The term "C/C++" is a Tool of the Devil. Each has its many endearing qualities but it is inappropriate to put them together like that. I do understand the common complaint about that but in the author's type of article, it's fine to lump them together. He's talking about "tools" for runtime analysis, formatters, etc. The tools he's talking about handle both languages. His current url for the article is: .../blog/2015/07/23/additional-c-slash-c-plus-plus-tooling/ What would be a solution to satisfy purists and always separate C from C++? Should the author create 2 separate urls? C tooling url would be: .../blog/2015/07/23/additional-c-tooling/ C++ tooling url would be: .../blog/2015/07/23/additional-c-plus-plus-tooling/ And both webpages would be 99% the same and running a diff only shows that string "C language" is replaced with "C++ language". Instead of that convoluted redundancy, it's quite reasonable in this specific type of article to lump "C/C++" together.

gherazta 11y ago
But the tools _do_ change. E.g. - Development Environments High-Level C++ is rather verbose so it is often developed in connection with an IDE, e.g. to jump to a class definition. C works way better with established tools like grep and co, as it does not do function overloading. - Debugging C++ is for me the most hard language to debug, as their is so much stuff you have to keep in your head. Due to name-wrangling symbols get also weird names in debuggin areas. - FFI C is the established high-quality FFI approach and popular languages have very good _C_ FFI support: Python, Haskell, etc. In particular it is simpler for language designers to support C. It is similar to the Java/JavaScript debate, where one might argue that both are interpreted languages.
- jasode 11y ago
  >But the tools _do_ change. Yes but that's not relevant in this thread. Please try to follow the limited context of this discussion. We are not talking about the set of ALL tools of which some might be specific for C and others might be specific to C++. Instead, we were discussing Nick Desaulniers' specific article and the particular tools he's describing in his article.

by jasode 11y ago

gherazta 11y ago

But the tools _do_ change. E.g. - Development Environments High-Level C++ is rather verbose so it is often developed in connection with an IDE, e.g. to jump to a class definition. C works way better with established tools like grep and co, as it does not do function overloading. - Debugging C++ is for me the most hard language to debug, as their is so much stuff you have to keep in your head. Due to name-wrangling symbols get also weird names in debuggin areas. - FFI C is the established high-quality FFI approach and popular languages have very good _C_ FFI support: Python, Haskell, etc. In particular it is simpler for language designers to support C. It is similar to the Java/JavaScript debate, where one might argue that both are interpreted languages.

jasode 11y ago
>But the tools _do_ change. Yes but that's not relevant in this thread. Please try to follow the limited context of this discussion. We are not talking about the set of ALL tools of which some might be specific for C and others might be specific to C++. Instead, we were discussing Nick Desaulniers' specific article and the particular tools he's describing in his article.