Hacker News Reader

Comment by woud420 | Hacker News Reader

While I agree that some Makefiles are terrible, I disagree that make is absolutely horrendous. It's sort of what you do with it; it's a copy paste garbled mess, of course it'll be terrible but you can make the same argument about maven, sbt and quite a few other build systems.

On another note, besides C legacy (memcpy, printf, malloc, etc.), could you point me towards something that is not type safe in C++ (preferably post C++11)? I find the argument a little bit disingenuous after claiming rust is type safe (you can do the same kind of non type safe magic with the unsafe keyword).

View on HN

Just as an FYI, “disingenuous” means that you think that the person making the argument actually believes that the argument is false, or is purposefully omitting relevant facts. It is more or less synonymous with “insincere”. I’m assuming that “disingenuous” is not what you meant.

I did mean insincere :). Thanks

To be clear it is inappropriate to call someone insincere when there isn’t good evidence for it. I see people throwing around the word “disingenuous” in Hacker News comments a bit too often. It’s an ad hominem disguised as actual discourse and a rare enough word that some people gloss over it or need to look it up. The accusation detracts from discussion about the topic at hand.

The idea that you were misusing the word was more appealing than the truth that you knew what it meant.

No I never claimed Rust is type safe. I don't know enough about it to make such a claim. I just read some articles and blog post and i really liked some concepts of it.

So I think some people are forgetting that I work and talk only about embedded development C/C++.

Generally what i mean with you can't trust the data is that memory can get corrupted in embedded very easily. There are some mechanisms to prevent it (MPU for example). The other thing that I see often is the usage of opaque pointer by vendors. That is not necessarily a problem with C++ but you will have to use it and deal with it.

But yeah you re right about modern C++ features being more type safe. I would love to use them but the problem is many of those std features are not usable in embedded or are not worth the cost.

> While I agree that some Makefiles are terrible, I disagree that make is absolutely horrendous.

I agree with the parent on this point (although make is not _the_ C/C++ build system) - makefiles are horrible. Make is arcane, full of quirks that bite you as a beginner, and suffers hugely from being not-portable (gnu make is not the same as other flavours, and make on windows is practically non-existent)

> could you point me towards something that is not type safe in C++

Not the parent but [0] is a reasonable example.

[0] https://gcc.godbolt.org/z/csjnM4

I think your example here is pretty disingenuous because you haven't created any types, merely aliases of 'meter' and 'centimeter' that are of type int.

A better example of breaking type safety would be to involve a reinterpret_cast or a C-style cast, or maybe pass something through a void*.

I don't disagree that I haven't created any types, but to someone who doesn't see the declaration of meter or centimeter, it can be difficult to know that. Especially if you combine it with almost always auto.

You can created tagged structs, but you inevitably end up needing to extract the value underneath.

Regarding casts and void pointers, I think they're a slightly less dangerous case. My Spidey senses tingles whenever I need casts - static (or to a certain extent dynamic) casts are normally ok, but a reinterpret cast or a void* parameter is going to warrant a discussion and explanation in a code review.

> I don't disagree that I haven't created any types, but to someone who doesn't see the declaration of meter or centimeter, it can be difficult to know that.

We definitely agree here. Better would be to use a library such as Boost Units, rather than naked aliases.

void* is definitely problematic, and I kill it every chance I get, but it persists in a lot of code due to C libs and unfortunate legacy dependencies.

Sorry I missed this.

> Better would be to use a library such as Boost Units, rather than naked aliases.

Completely agreed.

> void* is definitely problematic, and I kill it every chance I get, but it persists in a lot of code due to C libs and unfortunate legacy dependencies.

I've not seen it (thankfully) in anything other than actual C code or graphics code, but whenever I do see it, I make a mental note of "here be dragons" and make sure to take extra care around there... It's not ideal but it's life..

In a type safe C++ style, 'meters' would be a numeric-like class with explicit casting operators etc.

Would a single member struct work as well? Can C++ optimize that away?

Rust is type-safe (in most senses of the word) if you don't use unsafe. C++ is not.

> I find the argument a little bit disingenuous after claiming rust is type safe (you can do the same kind of non type safe magic with the unsafe keyword).

Rust is probably the most type safe language I’ve ever used, granted it’s not many, but definitely between Java, C, C++, JS, Python, Lisp, etc. If you put Rust in the same category because it has unsafe, you might as well just throw your hands up and say that no language, not a one is typesafe, with the exception of possibly Assembly, which practically treats everything as just a series of bits.

There is a misconception that b/c Rust has unsafe it is proof that it is itself unsafe, but this devalues the entire point of having any form a safety in language.

The language is typesafe, memory safe, and datarace safe, so long as you keep the guardrails on. Sometimes you take the guardrails away for very special reasons, but those are generally rare (unless you’re working with FFI, hardware, or low level concurrency). I have entire codebases of multiple thousands of lines in Rust without the need to use unsafe at all.

>On another note, besides C legacy (memcpy, printf, malloc, etc.), could you point me towards something that is not type safe in C++ (preferably post C++11)?

How about typedef's in general, what problem BOOST_STRONG_TYPEDEF solves (and its limitations)?

Reply on news.ycombinator.com