Hacker News Reader

> His dismissal of C++ as "not having a build system" seems like considering the language without the ecosystem. Using cmake and llvm solves all of his gripes on C++.

Last week I debugged an issue in a big C++ codebase, where we were getting memory corruption. Source of the issue? Compiler, linker and build system being separate things and only compiler understanding types (also, lack of modules, which is another symptom of build system being separate from the language). Namely, conditional compilation was involved, someone made a struct which had a field in it based on whether a preprocessor constant was defined or not (passed with -D to the compiler on the command line). Turned out some files were compiled with the define and some not, so some files were compiled based on the assumption that this struct is N bytes long, and some with the assumption that this struct is N+M bytes long. But the linker doesn't have any information available to it to detect this error.

And then there is the issue that to write a C++ program these days, it doesn't suffice that you just know C++. Languages you need to know:

- C++

- language of your build system, which is always handicapped, yet Turing-complete

- Python

- if something goes wrong, and you need to debug something: Make with its custom shell-language

- shell

It's a tower of babel. For all the whining on users of other languages for using libraries, C++ users have a lot of complexity hidden in their build systems.

In Zig and the not-yet-released Jai, you only need to know the language you write your program in. The "if" in your language of choice is perfectly suitable for expressing conditional compilation. Structs in your language of choice are perfectly suitable for expressing declarative configuration.

Yep been there done that two months ago, took me two days (at least) to find the issue as a corruption which happen in -O3 but not in debug build which neither valgrind nor ASAN can find is pretty mysterious..

Unless you left out some details, this sounds more like plain UB and buggy c++ code manifesting itself with different symptoms depending on the O level.

This has not as much to do with the loosely coupled build system complexity you have to scaffold in a c++ project, more issues in the core language itself.

I won't go into detail but this was related to macros and separated compilations: if you're not careful with macros, the 'same' object can have different size in different .cpp..

>Namely, conditional compilation was involved, someone made a struct which had a field in it based on whether a preprocessor constant was defined or not

No offense but this just sounds like bad design. Haskell has the C preprocessor so technically that particular criticism would apply to it too, but nobody would say it's Haskell's problem just because in theory people could use this feature to write terrible code. (I understand maybe this approach was necessary for interfacting with some other vendor/legacy code somewhere, but in that case the fundamental issue is still bad code, not C++: the bad vendor/legacy code).

I've seen this sort of thing all the time. Not the part about different preprocessor defines in different files, but about having a struct's contents depend on some compile time conditions. It comes up when you want to track extra debug information but only for debug builds. It comes up if you need to store platform specific information in a common struct. It can come up if you have a major feature that you want to toggle on/off at compile time. Etc.

> Haskell has the C preprocessor

I'm not sure what you mean by that. Are you saying you can use #ifdef, #include etc. in Haskell code?

> No offense but this just sounds like bad design.

I agree. However that's just one way you get multiple definitions for the same struct. I think a language should detect such an error. It will detect it for functions. If linkers did not detect multiple function definitions, would you shrug it off by saying "having multiple function definitions is bad design"? (I'm asking in a non-accusatory way. I'm not sure how to word the question more gently.)

Many of us don't have the luxury of choosing the quality of code we're employed to debug. It would be nice if languages had some rudimentary sanity-checks to, well, preserve our sanity.

>I'm not sure what you mean by that. Are you saying you can use #ifdef, #include etc. in Haskell code?

Yep: https://guide.aelve.com/haskell/cpp-vww0qd72.

>Many of us don't have the luxury of choosing the quality of code we're employed to debug. It would be nice if languages had some rudimentary sanity-checks to, well, preserve our sanity.

I agree, I don't think C++ is especially bad in this regard. If people are going to write bad code, they can write it just as well in Java, C#, Python etc., they'll just use different language features to bring about the horrors. No language (apart from maybe Go, in its extreme simplicity) can save us from having to debug bad code.

Linux kernel has a lot of these compile time optional struct members.

I think they avoid this issue by using a config header file that contains the defines, so the compilation unit either compiles with the config header, or if it's not included and config macro is used, compilation fails altogether.

It's still possible to include different config header than you're expecting, though. But that's easier to defend against. (you can just include a config header directly via cmd line without using #include <...> in each compilation unit)

It's also better to use #if MACRO = 1 instead of #ifdef MACRO, because the first one will fail if MACRO is not defined.

Regarding the string type in Zig, in case some people are interested by this you can read those two threads from the Zig github repository to understand a bit better previous discussions (I would recommend reading them, they are both interesting):

-------

"Improved handling of strings and unicode", https://github.com/ziglang/zig/issues/234

Andrew answer:

> I'm not convinced that this is a language change rather than a standard library feature.

(source https://github.com/ziglang/zig/issues/234#issuecomment-28927...)

-------

"Proposal: Add String to the type system", https://github.com/ziglang/zig/issues/7734

Andre answer:

> We won't have a string type in the language.

> OP problem can be solved with a better std.fmt.format API which better communicates intent. This is a deficiency of the std lib, not the language

(source https://github.com/ziglang/zig/issues/7734#issuecomment-7581...)

> This combined with "strings" being byte buffers like in C are not a good thing.

The problem of C strings is that they are zero-terminated, not that they are byte buffers. Strings in Zig are foremost slice types (pointer/size pairs), but for C compatibility, Zig also has the concept of 'sentinel terminated arrays':

https://ziglang.org/documentation/master/#Sentinel-Terminate...

> how do you handle an umlaut in zig

Via UTF-8 encoding, as it should be.

> cmake...

I use cmake for my C and C++ stuff too because it's the defacto standard, but Rust's cargo or Zig's integrated build system are on a whole different level.

> utf-8 as it should be

Agreed, but now your standard library doesn't have string support, it has byte buffer support. That's no improvement over C, compared to rust.

The downside of a single string type built into the standard library or even into the language is that it needs to be both flexible and performant, and in my experience, those two things exclude each other (e.g. how do you append two high-level strings like "str1 + str2" without hidden allocation?).

Apart from that, Zig's string processing functions are not that bad, what's unexpected is that they are in the memory-operations part of the standard library, not in a specific "string module" (after all, the Zig compiler is (being) written in Zig, and the parser needs to do a lot of string-munching, so I guess we'll get more powerful string processing helper functions in the standard library over time).

But if I need to do lots of high-level string processing I probably wouldn't chose a systems programming language to begin with, languages like Python are a better match for this.

Zig does have utf8 APIs, though to be fair, the docs are quite sparse

The fact that they're not NULL terminated and the slices itself have length information is already a great improvement over C.

> how do you handle an umlaut in zig?

"Handle" how? If you're just shuffling bytes around, you don't need to worry about it. If you need to iterate through by codepoints, there's stdlib Utf8View module, though I understand this aspect of the standard library is set to change before 1.0.

The fact that multi-byte codepoints don't have bytes that could be ASCII gets you decently far for common things like splitting a string at a newline, or otherwise matching against a char.

edit: actually, were you talking about the code in the post? Looking at it now, I see it's buggy in this regard, if you're wanting a ? to match ü. I think basically what you'd do is in the branch corresponding to the ? you could use the stdlibs's utf8ByteSequenceLength function to skip the text ahead that many bytes, while advancing the pattern by just the one byte.

CMake, SCons, Autotools, Meson, Premake, to quote only them.

They are build systems alright, but they miss the most crucial point: dependency managment.

On the other side we have:

  - cargo for Rust
  - buck and buckaroo for C++ which seems nowhere near complete

Am I missing something?

Cmake is pretty good, but you're right it's no dependency manager. And dependency management us definitely tough in c++. There's vcpkg and conan though which are huge improvements over the status quo.

This is exactly my painpoint with C++ too. With Rust and such I'm one simple command line call away from installing a dependency. With C++ every dependency is a battle.

There is conan or vcpkg. I do wish crates.io and julia would make it easier to develop on non internet machines. The ease of dependency management has bred staggeringly deep dependency trees for rust and julia. If I could run a cargo command to get a human readable dependency list that I could then go to an internet facing machine and run a cargo command to put into a tgz to drag back over that would be helpful. Is there any progress on making a crates mirror for offline networks?

A list of dependencies:

https://doc.rust-lang.org/cargo/commands/cargo-tree.html

Download all dependencies locally:

https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

I think maybe I don't understand vendor. I thought you had to have your project on the internet facing machine to vendor its dependencies. Which I cannot do.

Likewise, I don’t understand the disconnect. You have to have your list of dependencies on an internet connected machine, yes, but you already allowed that. You said:

> I could then go to an internet facing machine and run a cargo command

Copy over your Cargo.toml to that machine, run vendor, copy the vendor files back.

<sheepish headslap> thanks!

Yes, Conan and vcpkg have gotten better lately, but that is a relatively recent development. Just two years ago I still had a hard time finding some common libraries with Conan. It's good that the situation is better now.

vcpkg install.

It integrates with cmake too!

Then again, for every project you have to then setup vcpkg and cmake. I thoroughly enjoy that Rust comes with a build system, package manager and test framework out-of-the-box. But it is good that the situation with C++ is getting better.

Yep no arguments there. It's not perfect, but it's nowhere near as bad as the article makes it out to be. Also, you only set up a project once, but it's compiled and iterated on many many more times. Having some initial friction isn't ideal but it's better to solve for the real problems which are maintaining a project.

meson has subprojects. Try building gtk4. If you don't have some deps on the system, meson will download and build them as necessary.

>This combined with "strings" being byte buffers like in C are not a good thing.

It depends what the problem you're facing with. If the problem is "people writing C++ code with terrible latency characteristics because they don't understand how it works underneath and the stdlib doesn't even provide a way to efficently concatenate strings (i.e. by using a buffer, not allocating new memory)", Zig's approach is a great thing.

> using cake and LLVM

Sure they (not sure about LLVM as a build system?) work but they really aren't all that great in my experience.

I've had excellent experience with cmake over the last 10 years. It's no cargo, that's for sure, but it gives you a crossplatform cross toolchain extensible reliable build system

Llvm was specifically in reference to the "tooling" comment in the blog post. Clang format and clang-tidy(which conveniently has a neat integration with cmake!)

How did I not notice it corrected cmake to cake...