Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

For C programmers that hate C++ (2011)

thanassis.space

Post reply on HN
Print view View original

11–18 of 18 posts

Re: For C programmers that hate C++ (2011)

#11

Post by dilipdasilva »

bfrog wrote: post #8

Reading C++ is commonly much harder than reading C in my experience. Seeing as I read more than write code it heavily biased me towards C.

C++ has a lot of features (large surface area) and power. This power is the result of powerful language constructs like inheritance, operator overloading, templates, etc. This can make it very powerful and concise for writing code. When power is hidden, it makes it very difficult to read.

C just has data structures and functions (small surface area). Its simplicity makes it much easier to read.

Some languages prioritize adding features and power. C++, Rust, and Swift are examples.

Other languages prioritize minimizing the surface area. C, Go and Scheme are examples.

Programmers either value minimal surface area (better for reading) or maximal features and power (better for writing) and are more likely to adopt languages based on this classification.

For example, C programmers are more likely to adopt Go over C++ and Rust. And, C++ programmers are more likely to adopt Rust.

Re: For C programmers that hate C++ (2011)

#12

Post by wott »

ActorNightly wrote: post #10

The right way to do this in C would be to define each type of pixel in its own file, along with processing functions, and use function pointers within the structs for required processing. C++ classes are really just syntactic sugar for data organization. You can do the same type of organization in C, things just have to be more explicit. The benefit if using C is that you can use constructs where needed while trimmin…

Well, you don't really need to mimic OO to make that code cleaner and less error prone.

Here's what he wrote in order to complain about it:

    if (mode == ambient) {
      // handle pixels as ambient...
      int steps = right.a.x - left.a.x;
      float dv = (right.a.ambientLight - left.a.ambientLight)/steps;
      float currentIntensity = left.a.ambientLight;
      for (i=left.a.x; i
Nobody should do that. We use a temporary variable of the correct type. For example this way (but it could also be done with pointers to access directly the union variable):

    switch(mode) {
      case AMBIENT: {
        PixelDataAmbient l = left.a;
        PixelDataAmbient r = right.a;
        int steps = r.x - l.x;
        float dv = (r.ambientLight - l.ambientLight)/steps;
        /* ... */
        break;
      }
      case GOURAUD: {
        PixelDataGouraud l = left.g;
        PixelDataGouraud r = right.g;
        int steps = r.x - l.x;
          /* ... */
          break;
        }
      /* ... */
      default:
        show_error("Illegal mode");
    }
There is no need to cart all the .a. and .g. around and clutter the code. And there is no possibility to accidentally access the wrong fields the wrong way: trying to access l.ambientLight in the second block (GOURAUD) will fail at compilation since a PixelDataGouraud doesn't have an ambientLight field. It is also not possible to do PixelDataGouraud l = left.a; since left.a is not a PixelDataGouraud.

Much cleaner, much more readable and avoids most of the possible errors he complains about.

Re: For C programmers that hate C++ (2011)

#13

Post by BenFrantzDale »

omegalulw wrote: post #4
carlmr wrote: post #3

The problem with C++ is not the features that help you write better, safer code as explained here. The problem is that C++ has so much bad and people do use it. C++ is good as long as it's a solo project, it's okay for small projects, it inevitably fails on large projects.

> it inevitably fails on large projects. This is not even REMOTELY true. Plenty of companies use massive pure C++ projects.

Agreed. With its static typing, namespaces, and stability over decades, I can think of few languages other than C++ appropriate for enormous projects.

Re: For C programmers that hate C++ (2011)

#14

Post by RcouF1uZ4gsC »

thinkski wrote: post #9

In embedded systems, space can be a premium (e.g. a recent project has 75MB for a rootfs). With C++, need to link to libstdc++ and libc, with C only need libc. I find a number of developers reach for C++ because they aren’t comfortable with C or low-level development. For instance, will copy memory into a std::vector or std::string just to use the STLs search functions where a simple finite state machine would be mor…

>For instance, will copy memory into a std::vector or std::string just to use the STLs search functions where a simple finite state machine would be more appropriate.

The STL was specifically designed so that pointers are iterators and you are able to pass a pair of pointers to pretty much any STL algorithm. This you should never need to copy memory into a container such a vector or string to be able to use the STL algorithms.

Re: For C programmers that hate C++ (2011)

#15

Post by longtrousers »

dilipdasilva wrote: post #11
bfrog wrote: post #8

Reading C++ is commonly much harder than reading C in my experience. Seeing as I read more than write code it heavily biased me towards C.

C++ has a lot of features (large surface area) and power. This power is the result of powerful language constructs like inheritance, operator overloading, templates, etc. This can make it very powerful and concise for writing code. When power is hidden, it makes it very difficult to read. C just has data structures and functions (small surface area). Its simplicity makes it much easier to read. Some languages priorit…

This summary is absolutely amazing. It makes you think, given that code gets read a lot more than it gets written. It also makes me curious about Scheme, because I didn't know that it belongs to that category. I think that it's also important to add that C++ sort of belongs to a category of its own, because it has an absolutely enourmous surface area compared to e.g. Rust.

Re: For C programmers that hate C++ (2011)

#16

Post by [deleted] »

thinkski wrote: post #9

In embedded systems, space can be a premium (e.g. a recent project has 75MB for a rootfs). With C++, need to link to libstdc++ and libc, with C only need libc. I find a number of developers reach for C++ because they aren’t comfortable with C or low-level development. For instance, will copy memory into a std::vector or std::string just to use the STLs search functions where a simple finite state machine would be mor…

[deleted]

Re: For C programmers that hate C++ (2011)

#17

Post by ActorNightly »

wott wrote: post #12
ActorNightly wrote: post #10

The right way to do this in C would be to define each type of pixel in its own file, along with processing functions, and use function pointers within the structs for required processing. C++ classes are really just syntactic sugar for data organization. You can do the same type of organization in C, things just have to be more explicit. The benefit if using C is that you can use constructs where needed while trimmin…

Well, you don't really need to mimic OO to make that code cleaner and less error prone. Here's what he wrote in order to complain about it: if (mode == ambient) { // handle pixels as ambient... int steps = right.a.x - left.a.x; float dv = (right.a.ambientLight - left.a.ambientLight)/steps; float currentIntensity = left.a.ambientLight; for (i=left.a.x; i Nobody should do that. We use a temporary variable of the correc…

You can definitely do that, however in practice, separating out by files makes the code very easy to test, since you can validate functionality per pixel type, and then validate your outer loop by passing fake objects with correct functions.

You can also have internal workings with static functions/variables that you can use as helpers, but invisible to outside code and not declared in header files.

Re: For C programmers that hate C++ (2011)

#18

Post by bfrog »

dilipdasilva wrote: post #11
bfrog wrote: post #8

Reading C++ is commonly much harder than reading C in my experience. Seeing as I read more than write code it heavily biased me towards C.

C++ has a lot of features (large surface area) and power. This power is the result of powerful language constructs like inheritance, operator overloading, templates, etc. This can make it very powerful and concise for writing code. When power is hidden, it makes it very difficult to read. C just has data structures and functions (small surface area). Its simplicity makes it much easier to read. Some languages priorit…

I actually disagree, while Rust has a great deal of features it’s still significantly easier to read. A big part of that I think comes from not having implicit function overloads and having not succumbed to the multitude of bikeshed acceptable language subsets C++ has developed over the many years it has existed. The rust you write on a microcontroller isn’t actually that different than the rust you’d write for a web app. Perhaps a clear sign that the parents statement is evidently incorrect is the acceptance of rust and the utter denial of C++ in the Linux kernel, where developers demand readability. Part of that may very well be what Rust provides as a feature set is enticing enough to work with whatever readability issues have come up.
Post reply on HN