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

71–80 of 132 posts

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

#71

Post by galangalalgol »

enriquto wrote: post #68
galangalalgol wrote: post #63

Earlier quoted context omitted.

I have indeed seen horrible things done with overloading andnto a much lesser extent copy consteuctors. But don't forget inheritance or partial template specialization. There are so very many ways to make subtle problems. In C you basically have evil macros and bad casts, which are bad enough. Are there any languages since C you think have gotten it right?

> Are there any languages since C you think have gotten it right? Basically any language except C++ ? ;) There's lots of languages that I use and enjoy: lua, julia, octave (just for numerical computation), python (except for numerical computation), the unix shell I find particularly beautiful and elegant (even with its obvious warts). Hell, even javascript the language is mostly OK, if it wasn't for its toxic develop…

Do you mean npm and its ability to both facilitate and encourage gigantic dependency trees? I'm worried julia and rust will get lesser versions of that problem.

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

#72

Post by ogoffart »

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…

> you find a simple line of C++ that says "y=f(x);", and it can do anything

In practice you know what it does because of the context. Devs don't usually override operator to mean the opposite of their meaning. And in case there are doubts, editors have become pretty good at pointing out at the right location.

It is the same in C. is `y` or `f` or `x` a macro that could potentially have `return` or `goto` statements, that can potentially use a `__LINE__` meaning you can't use two occurrence on the same line or within another macro. if `f` is a function, what are its side effects? Do conversion happen depending on the type of x? Or is it like a va_arg function that need the exact right type?

What i mean is that if you want to obfuscate things, you can do it in C just like in C++. But in normal code it's all pretty obvious.

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

#73

Post by enriquto »

galangalalgol wrote: post #71
enriquto wrote: post #68

Earlier quoted context omitted.

> Are there any languages since C you think have gotten it right? Basically any language except C++ ? ;) There's lots of languages that I use and enjoy: lua, julia, octave (just for numerical computation), python (except for numerical computation), the unix shell I find particularly beautiful and elegant (even with its obvious warts). Hell, even javascript the language is mostly OK, if it wasn't for its toxic develop…

Do you mean npm and its ability to both facilitate and encourage gigantic dependency trees? I'm worried julia and rust will get lesser versions of that problem.

Yes. That's what kills the language for me.

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

#74

Post by pjmlp »

jstimpfle wrote: post #60
pjmlp wrote: post #40

Earlier quoted context omitted.

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. G…

On those cases not, but certainly as function parameters.

or class members that are initialized on the constructor and never change during the class lifetime, if they are pointers instead it may raise lifetime questions.

Althought probably the correct way would be to make use of std::observer_ptr(), but it still isn't in the standard.

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

#75

Post by benibela »

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.

Easier to write . than ->

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

#76

Post by andrepd »

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…

Well... What's the difference compared to C? f(x) can also do anything, including side-effects, changing mutable state, etc. Worse if it's a macro.

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

#77

Post by pjmlp »

wruza wrote: post #38
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.

Ah, right. And all these “my move constructor wasn’t called” — “one of subfields had non-moveable field” and other arcane topics, which only C++ forums have, are just little implementation details. C++ is good when you believe it is Curly Visual Basic with some AOT speed and is an implicitness nightmare when you really care.

That is the beauty of C++.

I can write VB/Delphi like code with C++ Builder, write raytracing algorithms in CUDA, or just have fun targeting ESP32.

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

#78

Post by pjmlp »

kaba0 wrote: post #55
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.

UNIX/POSIX clones.

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

#79

Post by nathcd »

IgorPartola wrote: post #43
throwaway20014 wrote: post #25

Anyone who wants a very good modern C book that's only 272 pages, take a look at 'Effective C - An Introduction to Professional C Programming by Robert C. Seacord. [1]. It's from 2020. Robert Seacord is a Technical Director at NCC Group where he develops and delivers secure coding training in C, C++, and other languages. Seacord is an expert on the C Standards committee. > That's some solid credentials. He focuses on…

Hi Robert! :)

Per the HN guidelines:

> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.

https://news.ycombinator.com/newsguidelines.html

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

#80

Post by jstimpfle »

benibela wrote: post #75
pjmlp wrote: post #40

Earlier quoted context omitted.

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.

Easier to write . than ->

but less clear.

Some of the newer languages do aways with -> completely but I think it just obscures the data structures.

The one frequent annoyance that I had with . vs -> is that for access local variables I need to use . and if I make that code into a function that takes the local variables as a pointer, I need to change the code into ->. In other words, I can't easily move the code through stages of solidification using simple copy & paste.

That's why I tend to declare my local variables using pointer literal syntax, e.g.

    Foo *local_thing = &(Foo) { ... };
That way it gets easier to move the code out.
Post reply on HN