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

91–100 of 132 posts

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

#91

Post by jstimpfle »

ogoffart wrote: post #72
enriquto wrote: post #51

Earlier quoted context omitted.

> 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,…

It's not that anybody wants to obfuscate things. But with clever mechanisms, people start to notice that they did only when it's too late.

C macros can be useful, I would enjoy programming in this language much less if they weren't there. And if I build a reasonable abstraction with them, it's as little as a grep or go-to declaration to find out the definition. There are no implicit complicated resolution mechanims, no complicated internal data structures that keep what should be application data isolated in the compiler (so it has to be duplicated in other parts of the code). With macros, I just search for the name, and will usually quickly find the definition with very little additional indirection.

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

#92

Post by synergy20 »

What I really want, is a C++ book that lists the absolutely must-have features for a beginner-intermediate programmer, I don't want to be overloaded(no pun intended) with all those 2000 advanced features, I can read an advanced level book when I'm ready.

Basic types, smart-pointers(how to use them and when to use them), basic OOD and template(but no advanced tricks), essential algorithms and containers, that's about them. No need on constexpr, rtii etc for now.

In this fast-paced world it's hard to get interested in any books more than 300 pages for me.

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

#93

Post by pclmulqdq »

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…

While this is mostly true, there are some (very limited) circumstances where modern language constructs are legitimately the best approach. Generic libraries are probably the most obvious case where you may need some fancy metaprogramming. Move semantics and other similar tricks for avoiding copies are often used for saving much more than a 24-byte copy.

Unfortunately, a lot of C++ enthusiasts who write this kind of code are language lawyers who might prefer to write in APL (a language with "expressiveness" and "beauty") than a language for humans.

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

#94

Post by dnautics »

amelius wrote: post #64

Is it possible to translate C into (unsafe) Rust while maintaining both human readability and link-level compatibility?

this is an evolving, and first-class capability of zig (you can run it now, the issue isn't closed because it's an epic)

https://github.com/ziglang/zig/issues/2457

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

#95

Post by pclmulqdq »

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.

Honestly, I think the "killer app" for C++ was generics. If you could write a generic data structure in C without using macros (which are extremely hard to debug), nobody would have wanted C++. However, the Linux Kernel is stuck with AVL trees and primitive hash table algorithms due to complexity, while C++ programmers can blissfully use B-trees and fast linear probing hash maps without worrying about the data structure.

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

#97

Post by jhauris »

As a professional C++ programmer who hasn't used C since the compiler limited me to C89 (so 2015ish), I am very impressed by how clean C code can look these days. This was a great talk. There are a lot of really good things in modern C, and if I ever have to use C again I will have some great new tools. And I found the "25k allocations for a single character entered" in chrome extremely shocking; it definitely pays to think about allocations in C++.

Given the improvements, I found the warning not to use libc unless absolutely necessary very surprising. I suppose C++ has parts we know to avoid, but I wonder why, with all the improvements to the C language, there haven't been the same improvements to the standard library? It appears C programmers are used to rewriting pretty basic functionality for every new project, or carting around their personal utility library.

I'm also still not at all convinced by macros.

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

#98

Post by jack_h »

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 only way to get a good maintainable C++ code is to hire very mediocre programmers whose “C++” really means “Qt with some shared ptrs”.

I feel like this is the most salient point in my mind. You can make an absolute mess of a code base in any language if you re-invent every wheel.

I work in the embedded world and there's a definite trade-off between C and C++. C is very minimal and embedded developers are very reluctant to use any third party code so you end up with a lot of triangular and square shaped wheels so to speak. On the other hand C++ does offer a lot of nice (and appropriate to use) things that would normally be re-invented in a C codebase, however it offers almost too many things which precipitates weird, wrong, and hard to maintain abstractions.

At least in my domain I feel the problem is developers just throwing code at a problem until it compiles and exhibits the expected behavior in the happy path before moving on to the next feature. This leads to the same concept being re-invented multiple times in the same code base in new and exciting ways. After all the goal is not to develop nice abstractions, it's to make a product that can be sold.

I would say C++ is an amazing language for library authors who are necessarily talented and spend the time to create robust, easy to use, and well thought out abstractions that can make the life of an application developer vastly easier.

Of course your mileage my vary as I'm sure the wider software world doesn't have all of the same problems that embedded has. I would just like to point out that I have seen absolutely unmaintainable, disastrous code bases in both C and C++ in my professional life and I doubt any language would have made it better.

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

#99

Post by maccard »

flohofwoe wrote: post #89
maccard wrote: post #86

Earlier quoted context omitted.

> If you feel the need to emulate C++ features in C then you're just writing C code with a C++ mindset. So you need a C++ mindset to have a use for a dynamic array, a hash table, threads or namespaces, all cross platform? (Yes windows is a platform too) That's without considering raii! (which does admittedly have some baggage wrt the functions you need to implement.)

Dynamic arrays, hash tables, threads: C++ doesn't have those either as language constructs, they are only implemented in the standard library. Namespaces: prefixes work just fine in C and don't require name mangling. RAII makes no sense with C's concept of "dumb data" instead of C++'s "smart objects".

Whether it's part of the language or the standard library is arguing semantics; Support for type safe dynamic arrays is something that C++ has that C doesn't, is widely used, and poorly reomplemented in C using macros (if you're lucky).

>Namespaces: prefixes work just fine in C and don't require name mangling.

This is a perfect example of a feature that solves a problem that C has (global namespace pollution). Prefixing is a bandaid, and a nasty one at that. Everyone loves #define NOMINMAX in the windows headers, and prefixing all their code with a faux namespace, dirtying _all_ of the code.

> RAII makes no sense with C's concept of "dumb data" instead of C++'s "smart objects".

Sure it does. Every call to fopen should be paired with a call to fclose, every malloc with a free. RAII practically eliminates a whole category of issues around resource leaks; in over a decade of writing C++ professionally, almost every instance of a memory leak, stomp or resource leak was someone trying to be "clever" and drop down to more C style code.

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

#100

Post by mfost »

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.

This completely ignores the advantages they have in code readability and reliability.

I can well deal with a little extra effort to order the initializations for those benefits.

Now, if you complained about the burden on refactoring member orders it poses on the other hand?

Post reply on HN