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

Modern C and What We Can Learn from It [video]

youtube.com

Post reply on HN
Print view View original

51–60 of 132 posts

Re: Modern C and What We Can Learn from It [video]

#51

Post by enriquto »

varajelle wrote: post #13
lmilcin wrote: post #9

Earlier quoted context omitted.

In my experience, I have to qualify I program "ANSI C", otherwise people assume that I am really talking about C++. I list ANSI C and no C++ in my professional experience and yet I have had a bunch of people call me to seriously talk about me helping in their C++ project. Maybe I shouldn't fault recruiters too much, though they should probably understand what language they are hiring for. But some of these guys were…

> C died and C++ is newer and better version of it That's kind of my opinion. C didn't die for legacy reasons, but starting new project in C seems a nonsense to me. C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs.

> C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs.

I respect your opinion, but mine is the exact opposite (I don't know how representative mine is, but I'm sure I'm not alone).

The problem with C++ is that many of those "features" are actually "anti-features". From the top of my head: operator overloading, copy-constructors, constructors, destructors, function overloading. While these "features" may make correct code easier to write, they always make incorrect code much, much harder to understand.

For example, you find a simple line of C++ that says "y=f(x);", and it can do anything: has the parenthesis operator been overloaded? and the copy constructor? how many times is a destructor called here? What are its side effects? What instance of f is called, if none of them is defined for the actual type of x? Every single line of C++ that you have to analyze is a terrifying nightmare like this one.

Re: Modern C and What We Can Learn from It [video]

#52

Post by Quekid5 »

lmilcin wrote: post #16
harry8 wrote: post #10

Earlier quoted context omitted.

If you can program C well, C++ isn't going to be too much of a problem for you. The reverse is not necessarily true. If I were hiring on a C++ project I'd definitely want to talk to someone who is genuinely good at C - they may not want to talk of course.

I have been programming professionally for over 20 years in languages ranging from assembly to Lisp and everything inbetween and applications from embedded to Linux kernel, to OS, to backend systems to algorithmic trading. That I don't touch C++ is my choice because after years of development I decided that most of all I value simple and readable code, working with people who like to write simple and readable code or…

> For some reason I do not fully understand, C++ projects I have participated are a contest of who can think of more convoluted C++ construct that nobody ever will be able to understand and C++ seem to be absolutely perfect platform for it.

I think it both a culture and a more technical language problem. There seems to be a sort of extreme "ackshually, ..." one-upmanship and/or pedantry in all the C++ forums I've ever participated in. Of course this is itself driven by the crazy complexity of just the base C++ language itself and the numerous edge cases for everything. I think it's very telling that nobody, not even long-time committee members, can even claims to know all of C++[0].

This is exacerbated further by the committee's unwillingness to remove anything. I mean even such an obsolete feature as trigraphs was only removed in C++17, probably about 15-20 years after it mattered to anybody but IBM with their EBCDIC. Another little fun observation: Initializing a variable can be done in soooo many ways. I think it's at something like 20+ different ways at last count... Not a good sign.

I say all of the above as someone who actually appreciates a lot of things about C++.

[0] Even to a first approximation. Obviously there will always be obscure corners of any practical language such that no human can know literally all of it.

Re: Modern C and What We Can Learn from It [video]

#53

Post by lmilcin »

wruza wrote: post #45
lmilcin wrote: post #16

Earlier quoted context omitted.

I have been programming professionally for over 20 years in languages ranging from assembly to Lisp and everything inbetween and applications from embedded to Linux kernel, to OS, to backend systems to algorithmic trading. That I don't touch C++ is my choice because after years of development I decided that most of all I value simple and readable code, working with people who like to write simple and readable code or…

No upvote can tell how much I relate to this. The only way to get a good maintainable C++ code is to hire very mediocre programmers whose “C++” really means “Qt with some shared ptrs”. The reason (I believe) is that complex things are like hard drugs for smart people. Instead of solving business tasks, which honestly are often just boring, they long for an art in programming. In C++ this inevitably leads to solving n…

> The reason (I believe) is that complex things are like hard drugs for smart people.

That is the golden explanation I kind of understood internally but never formulated consciously.

Yes, that's exactly it.

It takes willpower to be able to refrain from all those shiny toys. You see one and you are immediately imagining what you could use it for.

Writing C is like using typewriter or distraction-free editor, putting away your phone and disconnecting the Internet.

Just imagine your team is told to write all their pieces of code in any language they want.

Writing C is like telling the team: sorry, you can't do that. We know all those languages exist and they even may have fancy features that could improve your work, but for reasons of sanity we want you to stay programming single language.

Re: Modern C and What We Can Learn from It [video]

#54

Post by slavik81 »

flohofwoe wrote: post #19
derefr wrote: post #11

Earlier quoted context omitted.

I prefer C, but I technically write C++ because my “C code” sometimes uses references instead of pointers. (Why did that never become a C feature, anyway? It’s completely independent from OO/exceptions/templates/etc.) Luckily, in most any environment you can name, installing a C compiler actually implicitly installs a C++ compiler as well; so I can hand my “C code” library to people and tell them it’s C, and the fact…

> Why did that never become a C feature, anyway? I would rather ask, why did C++ add another reference type next to pointers ;) PS: the important part is that libraries have a C API, whether the implementation underneath is written in C or C++ isn't all that important. But IMHO once you're restricted to a C API anyway, writing the implementation in C too makes more sense because there's fewer situations where the imp…

> I would rather ask, why did C++ add another reference type next to pointers

References were added so users could create types that look and feel like the built-in types. You need references to implement operator[] for std::vector or std::deque.

Another example would be a vec2 class with a += operator that returns *this, just like the += operator for float.

Re: Modern C and What We Can Learn from It [video]

#55

Post by kaba0 »

harry8 wrote: post #2

Association of C and C++ Users (ACCU) They should really just call themselves the ACU, they are wildly pro C++. It's progress that there is even a C talk at all at their conference but even looking at the title it's pitching itself at "No really, C isn't completely worthless" One day such language wars might seem quaint. While everyone has their livelihoods tied to their chosen technologies it probably won't. C++ is…

Not trying to start a language war, but what exactly would you use C for? C++ is just as good at embedded, and you can use it as basically a slightly less foot-gunny C. And there is also Rust and Zig, if that’s not really what you want.

I just can’t really use C with that amount of namespace pollution, at least namespaces should be added. And purely text-based macros are the worst thing ever.

Re: Modern C and What We Can Learn from It [video]

#56

Post by pjmlp »

lmilcin wrote: post #44
pjmlp wrote: post #42

Earlier quoted context omitted.

It is a culture problem, something that only will change with mentality reboot. "CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”" https://www.youtube.com/watch?v=D7Sd8A6_fYU "Writing better embedded Software - Dan Saks - Keynote Meeting Embedded 2018" https://www.youtube.com/watch?v=3VtGCPIoBfs "Embedded & C++ - Meeting 2017 Keynote" https://www.youtube.com/watch?v=mNPfsUZb3vs In a way, the same…

I think the basic issue is that C++ want to spend a lot of time focusing on C++ The Language, while C developers mostly want to focus on developing the logic of whatever they are doing. When I worked on C++ projects half of the discussion was on just the use of language or various consequences of it. On C projects that never happens. There is nothing to talk about so everybody focuses on making the project better. Th…

What I miss most when working in C instead of C++ is that although lint was created in 1979, most projects still avoid any kind of static analysis.

Then there are the discussions on:

- what warnings to turn on as errors

- what ISO C says and what compiler XYZ does, with many not even aware to the differences

- not clear understanding of the 200+ UB cases documented on the standard

- in-house libraries for safer handling of strings and arrays

- experienced developers creating CVEs because they think they are free of such errors (pun intended)

Re: Modern C and What We Can Learn from It [video]

#58

Post by an1sotropy »

An account of modern C should also note , which came with C99, and makes "sin()" and "cos()" do the right thing w.r.t. argument type (float, double, long double), something that has long been possible in Fortran. In C, this allows you to typedef a "real" type, set to either float or double at compile-time, in order to conveniently explore trade-offs associated with the different floating point precisions. The implementation of tgmath.h is an incredible hack though https://www.pixelstech.net/article/1324906407-The-ugliest-C-...

Re: Modern C and What We Can Learn from It [video]

#59

Post by jcelerier »

enriquto wrote: post #51
varajelle wrote: post #13

Earlier quoted context omitted.

> C died and C++ is newer and better version of it That's kind of my opinion. C didn't die for legacy reasons, but starting new project in C seems a nonsense to me. C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs.

> C++ just has so many features that makes the development of programs and libraries easier, for almost no extra costs. I respect your opinion, but mine is the exact opposite (I don't know how representative mine is, but I'm sure I'm not alone). The problem with C++ is that many of those "features" are actually "anti-features". From the top of my head: operator overloading, copy-constructors, constructors, destructor…

> The problem with C++ is that many of those "features" are actually "anti-features". From the top of my head: operator overloading, copy-constructors, constructors, destructors, function overloading. While these "features" may make correct code easier to write, they always make incorrect code much, much harder to understand.

> For example, you find a simple line of C++ that says "y=f(x);", and it can do anything: has the parenthesis operator been overloaded? and the copy constructor? how many times is a destructor called here? What are its side effects? What instance of f is called, if none of them is defined for the actual type of x? Every single line of C++ that you have to analyze is a terrifying nightmare like this one.

I have yet to see any of this be an actual problem in real-world projects.

I have seen on the other hand a lot of people coming with these abstract "this is gonna be a problem" ideas in mind, and never wanting to touch C again after working on actual modern C++ projects.

Re: Modern C and What We Can Learn from It [video]

#60

Post by jstimpfle »

pjmlp wrote: post #40
flohofwoe wrote: post #31

Earlier quoted context omitted.

> allows for out parameters Out parameters are mostly a legacy feature from the time when C compilers didn't allow struct return values though, or implemented this inefficiently (besides, out parameters via pointers works too). > memory addresses without the unsafety of dealing with pointers I never understood the "increased safety" argument. C++ references can become dangling just as easily as pointers, and arguable…

Out parameters are a welcomed feature of all memory safe systems programming languages, only missed from C and BCPL. C++ references surely are safer than pointer that can point to whatever they feel like and aren't initialized to any safe value. There is a difference between being 100% fully safe, which they aren't, and being safer than plain unsafe pointers Assembly style.

Although I've never found it useful, I believe if you do

    TYPE *const ptr = foo();
to initialize a C pointer where you can't change what thing it points to (as opposed to the thing itself), then you get 100% of the alleged safety benefits that you get from C++ references.

Except, you're not adding another type category in the type system, with all the complexities (non-orthogonality of features) that come with that.

Granted, compared to C++ reference declarations like

    TYPE& ptr = foo();
you'll have to type a few characters more, but then again you won't have to repeat your method signatures in 18 different flavours.
Post reply on HN