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

In Defense of C++

dayvster.com

Post reply on HN
Print view View original

461–470 of 470 posts

Re: In Defense of C++

#461

Post by 1718627440 »

duped wrote: post #57
jandrese wrote: post #12

Earlier quoted context omitted.

In Linuxland you at least have pkg-config to help with package management. It's not perfect but neither is any other package management solution. If I'm writing a small utility or something the Makefile typically looks something like this: CC=clang PACKAGES=libcurl libturbojpeg CFLAGS=-Wall -pedantic --std=gnu17 -g $(shell pkg-config --cflags $(PACKAGES)) LDLIBS=$(shell pkg-config --libs $(PACKAGES)) ALL: imagerunner…

Consider that to do this you must: - Use a build system like make, you can't just `c++ build` - Understand that C++ compilers by default have no idea where most things are, you have to tell them exactly where to search - Use an external tool that's not your build system or compiler to actually inform the compiler what those search paths are - Oh also understand the compiler doesn't actually output what you want, you…

> Understand that C++ compilers by default have no idea where most things are

C, C++ compilers by default expect libraries to be installed in the correct place, which would mean that you don't need to specify flags at all.

Also nothing stops you from writing:

    #include

Re: In Defense of C++

#462

Post by 1718627440 »

lelanthran wrote: post #384
butterisgood wrote: post #49

A pet peeve of mine is when people claim C++ is a superset of C. It really isn't. There's a lot of little nuanced differences that can bite you. Ignore the fact that having more keywords in C++ precludes the legality of some C code being C++. (`int class;`) void * implicit casting in C just works, but in C++ it must be an explicit cast (which is kind of funny considering all the confusing implicit behavior in C++). C…

> void * implicit casting in C just works, but in C++ it must be an explicit cast In C, casting a `void *` is a code smell, I feel. Most confusing one is how the meaning of `const` differs between C and C++; I'm pretty certain the C `const` keyword is broken compared to `const` in C++.

Yes, casting in general is a code smell. (Not as in never use it, but as in use it as less as possible of course.)

The thing is, void was introduced exactly to represent this use-case without casting. The type to represent random amount of bytes, check which type and then cast is called char *. void * is for when you know exactly which type it has you just need to pass it through a generic interface, which isn't supposed to know or touch the type. The other use case is for when the object hasn't a type yet, like from malloc.

Previously everything was typed char *, then void * was used to separate the cases: casting from char *, don't cast from void *. Now in C++ both are the same again.

Re: In Defense of C++

#463

Post by 1718627440 »

sunshowers wrote: post #408
account42 wrote: post #288

Earlier quoted context omitted.

Not an issue if you make use of the tools available: https://godbolt.org/z/xW14hGeoj

It looks like (a) this is a warning, not an error (why? the code is always wrong) and (b) the warning was added in clang 21 which came out this year. I also suspect that it wouldn't be able to detect complex cases that require interprocedural analysis. The bug I saw happened a few years ago, and convinced me to switch to Rust where it simply cannot happen.

A warning in C, C++ is the compiler saying "this is terribly broken, won't do what you want and I will exploit this". As opposed to an error, which means "I don't even know what you mean". Taking warnings lightly isn't the way to go in C or C++.

Re: In Defense of C++

#464

Post by 1718627440 »

Symmetry wrote: post #53
lordleft wrote: post #3

Great article. Modern C++ has come a really long way. I think lots of people have no idea about the newer features of the standard library and how much they minimize footguns.

I eagerly await the day when they do away with the distinction between ".cpp" and ".hpp" files and the textual substitution nature of "#include" and replace them all with a proper module system.

The distinction between *.cpp and *.hpp is purely convention, the compiler does not care at all.

Re: In Defense of C++

#465

Post by palata »

Defletter wrote: post #458
palata wrote: post #451

Earlier quoted context omitted.

> How does this justify the antipathy towards notions of a first-party build system and package manager? I don't feel particularly antipathic towards notions of first-party build system and package manager. I find it indeniably better to have a first-party build system instead of the fragmentation that exists in C/C++. On the other hand, I don't feel like asking a 20-year old project to leave autotools just because I…

Even though I understand why you prefer that, I feel like you're painting too rosy of an image. To quote Tom Delalande: "There are some projects where if it was 10% harder to write the code, the project would fail." I believe this deeply and that this is also true for the build system: your build config should not be rivalling your source code in terms of length. That's hyperbole in most cases, sure, and may well ind…

> but writing build configs should not be a skill issue

I think it shouldn't be a skill issue because a true professional should learn how to do it :-).

My build configs are systematically shorter than the bad ones.

Also I feel like many people really try to have CMake do everything, and as soon as you add custom functions in CMake, IMO you're doing it wrong. I have seen this pattern many times where people wrap CMake behind a Makefile, presumably because they hate having to run two commands (configure/build) instead of one (make). And then instead of having to deal with a terrible CMakeLists, they have to deal with a terrible CMakeLists and a terrible Makefile.

It's okay for the build instructions to say: "first you build the dependencies (or use a package manager for that), second you run this command to generate the protobuf files, and third you build the project". IMO if a developer cannot run 3 commands instead of one, they have to reflect on their own skills instead of blaming the tools :-).

Re: In Defense of C++

#466

Post by Defletter »

palata wrote: post #465
Defletter wrote: post #458

Earlier quoted context omitted.

Even though I understand why you prefer that, I feel like you're painting too rosy of an image. To quote Tom Delalande: "There are some projects where if it was 10% harder to write the code, the project would fail." I believe this deeply and that this is also true for the build system: your build config should not be rivalling your source code in terms of length. That's hyperbole in most cases, sure, and may well ind…

> but writing build configs should not be a skill issue I think it shouldn't be a skill issue because a true professional should learn how to do it :-). My build configs are systematically shorter than the bad ones. Also I feel like many people really try to have CMake do everything, and as soon as you add custom functions in CMake, IMO you're doing it wrong. I have seen this pattern many times where people wrap CMak…

> I think it shouldn't be a skill issue because a true professional should learn how to do it :-)

Therein lies the issue, in my opinion: I do not believe that someone should have to be a "true professional" to be able to use a language or its tooling. This is just "git gud" mentality, which as we all [should] know [by now] cannot be relied upon. It's like that "So you're telling me I have to get experience before I get experience?" meme about entry-level jobs: if you need to "git gud" before you can use C/C++ and its tooling properly, all that means is that they'll be writing appalling code and build configs in the mean time. That's bad. Take something like AzerothCore: I'd wager that most of its mods were made by enthusiasts and amateurs. I think that's fine, or at least should be, but I'm keenly aware that C/C++ and its tooling do not cater to, nor even really accommodate amateurs (jokey eg: https://www.youtube.com/watch?v=oTEiQx88B2U). That's bad. Obviously, this is heading into the realm of "what software are you trusting unwisely", but with languages like Rust, the trust issue doesn't often include incompetence, more-so just malice: I do not tend to fear that some Rust program has RCE-causing memory issues because someone strlen'd something they shouldn't.

Re: In Defense of C++

#467

Post by kronicum2025 »

Attrecomet wrote: post #274
kronicum2025 wrote: post #54

The safety part in this article is incorrect. There's a google doc somewhere where Google did an internal experiment and determined that safety c annot be achieved in C++ without an owning reference (essentially what Rust has).

Am I missing anything in the article about this problem in particular? Owning references are a part of modern C++, which should be covered by the author's arguments.

I meant to say exclusively owned references.

Re: In Defense of C++

#468

Post by palata »

Defletter wrote: post #466
palata wrote: post #465

Earlier quoted context omitted.

> but writing build configs should not be a skill issue I think it shouldn't be a skill issue because a true professional should learn how to do it :-). My build configs are systematically shorter than the bad ones. Also I feel like many people really try to have CMake do everything, and as soon as you add custom functions in CMake, IMO you're doing it wrong. I have seen this pattern many times where people wrap CMak…

> I think it shouldn't be a skill issue because a true professional should learn how to do it :-) Therein lies the issue, in my opinion: I do not believe that someone should have to be a "true professional" to be able to use a language or its tooling. This is just "git gud" mentality, which as we all [should] know [by now] cannot be relied upon. It's like that "So you're telling me I have to get experience before I g…

> It's like that "So you're telling me I have to get experience before I get experience?"

Not at all. I'm not saying that one should be an architect on day one. I'm saying that one should learn the basics on day one.

Learning how to install a package on a system and understanding that it means that a few files were copied in a few folders is basic. Anyone who cannot understand that does not deserve to be called a "software engineer". It has nothing to do with experience.

Re: In Defense of C++

#469

Post by Defletter »

palata wrote: post #468
Defletter wrote: post #466

Earlier quoted context omitted.

> I think it shouldn't be a skill issue because a true professional should learn how to do it :-) Therein lies the issue, in my opinion: I do not believe that someone should have to be a "true professional" to be able to use a language or its tooling. This is just "git gud" mentality, which as we all [should] know [by now] cannot be relied upon. It's like that "So you're telling me I have to get experience before I g…

> It's like that "So you're telling me I have to get experience before I get experience?" Not at all. I'm not saying that one should be an architect on day one. I'm saying that one should learn the basics on day one. Learning how to install a package on a system and understanding that it means that a few files were copied in a few folders is basic . Anyone who cannot understand that does not deserve to be called a "s…

> I'm saying that one should learn the basics on day one.

Except that C/C++ have entirely incongruous sets of basics compared to modern languages, which people coming to C/C++ for the first time are likely to have a passing familiarity with (unless it's their first language, of course). Yes, cmake configs can be pretty concise when only dealing with system packages, but this assumes that developers will want to do that, or whether they'll want to replicate the project-localness ideal, which complicates cmake configs. We're approaching this from entirely different places and is reminding me of the diametrically-opposed comments on this post (https://news.ycombinator.com/item?id=45328247) about READMEs.

Re: In Defense of C++

#470

Post by nurettin »

pod_krad wrote: post #457
nurettin wrote: post #283

Earlier quoted context omitted.

This is a failed attempt at muddying the waters. You don't know what move semantics is? You go learn what they are. Best/simplest way is to just disable your copy ctor. You need to know the operator overload semantics for a particular use case? It is not exactly hidden lore, there are even man pages (libstdc++-doc, man 3 std::ostream) or just use std::println. You are stuck instantiating std::vector? Then you will be…

It seems you didn't get the point. Why spending my time for learning those things, if in another language you may perfectly live without them?

Which imaginary language are you talking about where you don't have to learn any library functionality or quirks?
Post reply on HN