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

11–20 of 132 posts

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

#11

Post by derefr »

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…

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 that there’re a few .cpp files in there won’t be a problem, any more than having some .asm files in there would be.

I’d like to use std::string as well, but I want my code to externally obey the C FFI, rather than the C++ one (I.e. no need for the linking code to know it needs to initialize the C++ runtime), so I can’t really use any STL. Still wishing C had a standard, portable, found-in-all-compilers prefix-length strings library...

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

#12

Post by varajelle »

david2ndaccount wrote: post #7
makapuf wrote: post #6

It is to be noted that designated struct initializers will be/are in C++20 (of course it has all the features, it's C++). See it here: https://en.cppreference.com/w/cpp/language/aggregate_initial...

The C++ version is much worse. "Note: out-of-order designated initialization, nested designated initialization, mixing of designated initializers and regular initializers, and designated initialization of arrays are all supported in the C programming language, but are not allowed in C++.” Arrays designed to be indexed by an enum is a pattern I use all the time in C and designated initializers make it a whole lot safe…

The out of order initialisation is not supported because it would be confusing with the order of destruction. Note that initializing the members in a constructor in a different order is allowed, but they are actually still initialized in the declaration order. That's quite confusing and most compiler warn about that. So in a way it's good the same mistake was not done in designated initialized.

I don't know why the array notation is not allowed in C++.

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

#13

Post by varajelle »

lmilcin wrote: post #9
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…

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.

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

#14

Post by harry8 »

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.

This is a perfectly valid and fine opinion for many new projects. Possibly even most. The point were I dismiss this sort of thing is where it is "all" new projects.

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

#15

Post by Y_Y »

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.

Maybe you're just an unusually talented coder, but I pay dearly for every little extra bit of C++ my code touches. It's often worth it, but never a freebie.

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

#16

Post by lmilcin »

harry8 wrote: post #10
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…

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 helping projects write simple and readable code. And C++ and community is, in my opinion, anything but about simplicity and readability.

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.

Even if I am able to understand it (which I frequently do not), I just can't rationalize putting crap like that in a project that is expected to then be grokked and modified by new developers.

I have tried restricting the types of constructs and C++ syntax used in projects in the past but this inevitably causes flamewars and lots of discussions about why these rules were instituted and whether they are necessary. I am sick and tired of explaining the value that exists in moderation and restriction.

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

#17

Post by flohofwoe »

makapuf wrote: post #6

It is to be noted that designated struct initializers will be/are in C++20 (of course it has all the features, it's C++). See it here: https://en.cppreference.com/w/cpp/language/aggregate_initial...

Unfortunately the restrictions added in C++20 make designated initialization quite pointless for any structs or classes with more than a handful items. Having to remember the order of initialization is too much hassle in this case.

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

#18

Post by flohofwoe »

varajelle wrote: post #12
david2ndaccount wrote: post #7

Earlier quoted context omitted.

The C++ version is much worse. "Note: out-of-order designated initialization, nested designated initialization, mixing of designated initializers and regular initializers, and designated initialization of arrays are all supported in the C programming language, but are not allowed in C++.” Arrays designed to be indexed by an enum is a pattern I use all the time in C and designated initializers make it a whole lot safe…

The out of order initialisation is not supported because it would be confusing with the order of destruction. Note that initializing the members in a constructor in a different order is allowed, but they are actually still initialized in the declaration order. That's quite confusing and most compiler warn about that. So in a way it's good the same mistake was not done in designated initialized. I don't know why the a…

Apparently the array initialization clashes with lambda syntax.

Regarding all the restrictions added in C++20:

Clang supported the full C99 designated intiialization feature set in C++ without any issues long before C++20, so the decision by the C++ Committee to add those restrictions is quite baffling, considering that there is a solid implementation in the wild that has been working just fine for many years.

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

#19

Post by flohofwoe »

derefr wrote: post #11
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…

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 implementation clashes with the interface.

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

#20

Post by hmry »

flohofwoe wrote: post #17
makapuf wrote: post #6

It is to be noted that designated struct initializers will be/are in C++20 (of course it has all the features, it's C++). See it here: https://en.cppreference.com/w/cpp/language/aggregate_initial...

Unfortunately the restrictions added in C++20 make designated initialization quite pointless for any structs or classes with more than a handful items. Having to remember the order of initialization is too much hassle in this case.

That's what I thought too, until I actually used them extensively. The compiler tells you the correct order when you get it wrong, and I'm sure if you used an IDE (I don't) it would help you as well. And that was with Vulkan, everything in that API is done by creating structs with way too many members.
Post reply on HN