5 ms·

After twenty years of using it? That I was wrong, that plain-old C really is better.

AdieuToLogic 11y ago
The C that you call "really is better" is not the C which existed before C++. It is "K&R C", which looked like this: foo (a, b, c) char *a; int b, c; { /* do something cool here */ } And there were no "function declarations" (who needs argument type and cardinality checking anyway), no "slash slash" single line comments, no need to declare a return type as int was implied, say goodbye to const and volatile qualifiers, any char array is mutable (including those defined in double quotes), plus be sure to use function pointers thusly: (*some_pointer) (insert, args, here); Instead of: some_pointer (looks, like, a, function); Oh yeah, and say adios to struct initialization using the C89 syntax. And it's a no-no to try and initialize a local array along the lines of: char *strings = { "this", "is", "convenient", "isn't", "it?" }; So if you wish to assert (pun intended) "that plain-old C really is better", then be sure to acknowledge where a non-trivial amount of what is known as "plain-old C" stems from.
- exacube 11y ago
  by plain old, i think infradig was implying that C was plain and old compared to C++, and not about an older standard of C.
  - ectoplasm 11y ago
    Yes, plain-old C like plain-old vanilla ice cream, as compared to C++ like swirly rainbow vanilla chocolate strawberry template macro class inherits from a waffle cone with generic unique pointer functor sprinkles ice cream.
o87dv 11y ago
I'm a C programmer, and I'm considering trying C++ in the future. Can you elaborate?
eots 11y ago
What I've learnt is that if you start writing C++ as a plan-old C, you quickly find yourself reaching for this and that feature from C++ that makes your job easier and your code more readable. Knowing where to stop is the tricky part.
- madmoose 11y ago
  I like to call that "C with std::vector"
- bluetomcat 11y ago
  Coding in plain C99 with some discipline can actually get you most of the benefits of C++, without any of its quirks. The "object-orientedness" of C++ really boils down to implicitly passing the this pointer to member functions, inheritance + virtual functions, and namespaces. All of these can be emulated in what I would call "C with discipline". Just be consistent in your naming conventions, always use a common prefix for globally visible functions and types, and use structs of function pointers whenever you really need virtual functions.
  - checker659 11y ago
    What about templates? For some reason, C programmers only seem to comment about the OO parts of C++ and never talk about templates. When you bring variadic templates into the mix, it's just more awesomeness. And, before you mention it, use clang to avoid getting the page long templates related errors.
    - bluetomcat 11y ago
      I haven't seen much template wizardry in the C++ codebases I've worked on. It can generally be seen in the standard headers. Type-generic data containers can still be implemented with void pointers and very little runtime overhead, for example: http://lxr.nginx.org/source/src/core/ngx_array.h http://lxr.nginx.org/source/src/core/ngx_array.h
      - 11y ago
blub 11y ago
I hold the exact opposite opinion, and would never want to work on a plain C project. It is so low level that one has to write a lot of plumbing code to take care of error handling and resource management. It's also missing pretty much all higher-level concepts that are fast and can make code easier to write, read and less error-prone. Overall, it's simply not fun to write C code, there's a lot of tedious manual work, and even if you do everything according to the book you might oversee something and have problems. Well-written C++ completely eliminates some classes of problems, just like Rust's type system can eliminate even more issues. C is so tedious to write that even if I didn't have access to C++ I would try something else first when the need to write cross-platform/performant code would come. The point is: it's not appropriate to evangelise C (or any other language) without pointing out some of its major disadvantages. This is simply spreading misinformation.
- agumonkey 11y ago
  Stroustrup gave talks where he explained how to cherry pick c++ elements to decorate simple C code with just enough abstraction to get done safe and fast. I find it's an old timer skill to be able to use languages as suggestions rather than law and to strip it using only the bits that will really bring value to the project.
- xamuel 11y ago
  >plumbing code to take care of error handling This becomes much simpler once you learn how to write your own variadic functions (it's not that hard, though I do admit it could be prettier). Then you just write one single logerrf function or whatever, which 9 times out of 10 you can carry with minor modifications to your next project. Java does try/catch better in the sense that with checked exceptions you can force library users to at least acknowledge exceptions. Without checked exceptions, try/catch just hides the extra int *err argument under the rug, actually increasing the risk of library users not acknowledging edge cases. >and resource management I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification. The problem is compounded by the way C++ doesn't play nice with gdb/valgrind. Memory leaks and other memory errors are much easier to fix in C than C++. >C is so tedious It really isn't, though, if you use it right. Whatever syntactic tedium it has is more than compensated for by the lightning-fast compile time and the infinitely simpler compiler errors (due to no overloading, no templates...)
pjc50 11y ago
I've spent most of my career writing C++ in the "C with classes and containers" style. Apart from the compile times and library issues, this really is better than just standard C. You can automate much of the memory management.

The C that you call "really is better" is not the C which existed before C++. It is "K&R C", which looked like this: foo (a, b, c) char *a; int b, c; { /* do something cool here */ } And there were no "function declarations" (who needs argument type and cardinality checking anyway), no "slash slash" single line comments, no need to declare a return type as int was implied, say goodbye to const and volatile qualifiers, any char array is mutable (including those defined in double quotes), plus be sure to use function pointers thusly: (*some_pointer) (insert, args, here); Instead of: some_pointer (looks, like, a, function); Oh yeah, and say adios to struct initialization using the C89 syntax. And it's a no-no to try and initialize a local array along the lines of: char *strings = { "this", "is", "convenient", "isn't", "it?" }; So if you wish to assert (pun intended) "that plain-old C really is better", then be sure to acknowledge where a non-trivial amount of what is known as "plain-old C" stems from.

exacube 11y ago
by plain old, i think infradig was implying that C was plain and old compared to C++, and not about an older standard of C.
- ectoplasm 11y ago
  Yes, plain-old C like plain-old vanilla ice cream, as compared to C++ like swirly rainbow vanilla chocolate strawberry template macro class inherits from a waffle cone with generic unique pointer functor sprinkles ice cream.

o87dv 11y ago

I'm a C programmer, and I'm considering trying C++ in the future. Can you elaborate?

eots 11y ago

What I've learnt is that if you start writing C++ as a plan-old C, you quickly find yourself reaching for this and that feature from C++ that makes your job easier and your code more readable. Knowing where to stop is the tricky part.

madmoose 11y ago
I like to call that "C with std::vector"
bluetomcat 11y ago
Coding in plain C99 with some discipline can actually get you most of the benefits of C++, without any of its quirks. The "object-orientedness" of C++ really boils down to implicitly passing the this pointer to member functions, inheritance + virtual functions, and namespaces. All of these can be emulated in what I would call "C with discipline". Just be consistent in your naming conventions, always use a common prefix for globally visible functions and types, and use structs of function pointers whenever you really need virtual functions.
- checker659 11y ago
  What about templates? For some reason, C programmers only seem to comment about the OO parts of C++ and never talk about templates. When you bring variadic templates into the mix, it's just more awesomeness. And, before you mention it, use clang to avoid getting the page long templates related errors.
  - bluetomcat 11y ago
    I haven't seen much template wizardry in the C++ codebases I've worked on. It can generally be seen in the standard headers. Type-generic data containers can still be implemented with void pointers and very little runtime overhead, for example: http://lxr.nginx.org/source/src/core/ngx_array.h http://lxr.nginx.org/source/src/core/ngx_array.h
    - 11y ago

blub 11y ago

I hold the exact opposite opinion, and would never want to work on a plain C project. It is so low level that one has to write a lot of plumbing code to take care of error handling and resource management. It's also missing pretty much all higher-level concepts that are fast and can make code easier to write, read and less error-prone. Overall, it's simply not fun to write C code, there's a lot of tedious manual work, and even if you do everything according to the book you might oversee something and have problems. Well-written C++ completely eliminates some classes of problems, just like Rust's type system can eliminate even more issues. C is so tedious to write that even if I didn't have access to C++ I would try something else first when the need to write cross-platform/performant code would come. The point is: it's not appropriate to evangelise C (or any other language) without pointing out some of its major disadvantages. This is simply spreading misinformation.

agumonkey 11y ago
Stroustrup gave talks where he explained how to cherry pick c++ elements to decorate simple C code with just enough abstraction to get done safe and fast. I find it's an old timer skill to be able to use languages as suggestions rather than law and to strip it using only the bits that will really bring value to the project.
xamuel 11y ago
>plumbing code to take care of error handling This becomes much simpler once you learn how to write your own variadic functions (it's not that hard, though I do admit it could be prettier). Then you just write one single logerrf function or whatever, which 9 times out of 10 you can carry with minor modifications to your next project. Java does try/catch better in the sense that with checked exceptions you can force library users to at least acknowledge exceptions. Without checked exceptions, try/catch just hides the extra int *err argument under the rug, actually increasing the risk of library users not acknowledging edge cases. >and resource management I don't like C++ malloc'ing things behind my back. I see it as trading maintainability for instant gratification. The problem is compounded by the way C++ doesn't play nice with gdb/valgrind. Memory leaks and other memory errors are much easier to fix in C than C++. >C is so tedious It really isn't, though, if you use it right. Whatever syntactic tedium it has is more than compensated for by the lightning-fast compile time and the infinitely simpler compiler errors (due to no overloading, no templates...)

pjc50 11y ago

I've spent most of my career writing C++ in the "C with classes and containers" style. Apart from the compile times and library issues, this really is better than just standard C. You can automate much of the memory management.