4 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 often see job board p

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 often see job board posts and get mail from recruiters seeking coders with experience in "C/C++". Consider that Linus Torvalds and Richard Stallman would be unqualified for C++ work. I myself have done so much C++ that I am not particularly good at C anymore. If you use C++ as "A Better C" or "C With Objects" you will never get the bugs out of your code. C++ wants to be written a certain way which is quite alien to most C practices.

glandium 11y ago
The OP is about tools to build, develop and debug C and C++. None of the mentioned tools apply to one and not the other. Why would you want the title not to mention both?
ndesaulniers 11y ago
I agree, C and C++ despite many similarities and close ties in their family trees are quite different. I did not make that point in the article, as it's irrelevant to a piece on tooling that works for both.
TwoBit 11y ago
You can use a C++ compiler to do "C with objects" fine. Lots of people successfully do that. There's specification for doing this in fact which is adhered to by embedded developers. It's better to use C++ more fully, of course.
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.

glandium 11y ago

The OP is about tools to build, develop and debug C and C++. None of the mentioned tools apply to one and not the other. Why would you want the title not to mention both?

ndesaulniers 11y ago

I agree, C and C++ despite many similarities and close ties in their family trees are quite different. I did not make that point in the article, as it's irrelevant to a piece on tooling that works for both.

TwoBit 11y ago

You can use a C++ compiler to do "C with objects" fine. Lots of people successfully do that. There's specification for doing this in fact which is adhered to by embedded developers. It's better to use C++ more fully, of course.

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.