C++ Annotations | Hacker News Reader

C++ Annotations

icce.rug.nl

108 pointskbumsik34 comments

So I immediately checked my favorite language gotcha, the macro NULL. The text is entirely wrong. The macro NULL is harmful in both C and C++. It is not "stylistic" AT ALL.

Here's the problem with the macro: the macro NULL can be either 0 or can be (void * ) 0. The issue is that the former can be accidentally interpreted as an integer depending on context.

In both C and C++, this manifests when you pass NULL to a varargs function. Instead of passing in a null pointer, the compiler may instead pass in an integer zero. If pointers and ints have different sizes, hilarity ensues. If the null pointer does not have the same bit representation as int zero, hilarity ensues.

In C++, this happens even more commonly. If there is an operator overload and you pass in NULL, then if NULL is 0 it will chose the int overload, if NULL is (void * ) 0 it will chose a pointer overload.

Never use NULL. Ever.

> ... when you pass NULL to a varargs function. Instead of passing in a null pointer, the compiler may instead pass in an integer zero.

How can that happen? If I recall the standard, variadic functions have default promotion of non-declared args: integral promotion for integral types, floats to doubles. Why would the compiler want to convert a pointer (which (void*)0 is) to an integer?

> a pointer (which (void* )0 is)

In C: the macro NULL is an implementation-defined null pointer constant, which may be

> an integer constant expression with the value 0

> an integer constant expression with the value 0 cast to the type void*

In C++: the macro NULL is an implementation-defined null pointer constant, which may be

> an integral constant expression rvalue of integer type that evaluates to zero (until C++11)

> an integer literal with value zero, or a prvalue of type std::nullptr_t (since C++11)

What would you suggest using instead? The actual (void *) 0?

In C++, nullptr.

And in C?

In C, always use 0 and check for 0, it's the only safe way. For C++, it depends on the standard you're using.

Except when calling a varargs function, when you need to cast to the correct pointer type

But 0 isn't always null right?

Literal zero in a pointer context is interpreted by the compiler to mean "the null pointer." The compiler then compiles the null pointer into the code.

But then how do you get a pointer to zero (not null) in those systems?

First, that's inherently non-portable. That aside...

On most systems, the null pointer happens to be a pointer to address zero. For other systems, e.g. 8086 16-bit mode, you can create a intptr_t (which is the same size as a pointer) and set it to zero. Then cast it to a pointer. Such casting is always done bitwise, so it will work.

The compiler knows to turn the following into the null pointer

  void *p = (void *) 0;

but the compiler will NOT turn the following into a null pointer

  void *p = (void *) (uintptr_t) 0;

because the literal 0 is now in an integer context, not a pointer context.

BTW 0 is a valid literal value of a pointer type (so you do not need a cast).

Thank you!

Prior to nullptr, generally I used literal 0. In those cases which require disambiguation, I used (void * ) 0.

In C++ it'd be nullptr.

the macro NULL can be either 0

When is that the case? Like, in some specific library/compiler implementations?

In C and C++, 0 is an allowed definition of NULL. Before C++11, 0 was the only allowed definition of NULL.

It's becoming increasingly hard to gather any useful information about software development topic from a concise title because rampant terminology growth and (sometimes fueled by reuse of concepts with different terminology in different projects) to the point that concise titles are almost always ambiguous in some manner.

For example, I've seen this submission for hours now, and every time I assumed it was sort of function annotation/decorator syntax addition to achieve some interesting result, which didn't pique my interest at those times.

Is any other field quite as bad with this as software development seems to be?

This seems to be a particularly extreme case of unconventional terminology usage, but on the whole, the phenomenon you describe is the inevitable consequence of trying to be concise while also not inventing words. The information density of the existing language just can’t handle the depth of all the fields we try to use it for without inventing terminology.

Off the top of my head, I would claim that any large subfield of mathematics is probably as bad, if not worse, than software development (see: all the words used to describe “a collection of things”). I would expect this to be true for any sufficiently developed field of study.

The first sentence of the link may be enlightening. Instead of puzzling over it, why not just clicm the link and take a peek?

> This document is intended for knowledgeable users of C (or any other language using a C-like grammar, like Perl or Java) who would like to know more about, or make the transition to, C++

It's not puzzling, it's that you read a title and think it is something different.

Sure, immediately. But OP said "I've seen this submission for hours now", as if he has been trying to decipher it for a long time.

> But OP said "I've seen this submission for hours now", as if he has been trying to decipher it for a long time.

No, seen as in "Seen on the front page but it didn't interest me enough at the time to look into it given what I assumed it was about."

If you are in the Groningen region for a longer period, I can highly recommended taking Frank Brokken's C++ course [1]. I took the course over ten years ago and benefitted from it many years thereafter. He is also a great and very entertaining lecturer.

[1] he is the writer of the C++ annotations.

A nice detailed overview of C++ (not sure why it's titled "annotations", though).

As a previous C++ and current python dev I am not surprised to see 24 chapters on decorators in C++. (Joking ofcourse)

How is the accuracy and recency of this manual compared to Stroustrup's A Tour of C++? Has anyone here read both?

Here is his Gitlab [1]. Looking at the history at least he maintains the book very actively for years.

[1] https://gitlab.com/fbb-git/cppannotations/commits/master

This is a treasure. Dipping back into C++ after a couple decades makes this document pretty much essential.

Then you will need this as well https://github.com/AnthonyCalandra/modern-cpp-features

actively dipping back into c++. I've needed this and I didn't know it. thanks

Damn, son. Thank you.

Good read but class template argument deduction is not mentioned.

Reply on news.ycombinator.com