
C++ Annotations - kbumsik
http://www.icce.rug.nl/documents/cplusplus/
======
cjensen
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.

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

~~~
CopperWing
In C++, nullptr.

~~~
cjs_2
And in C?

~~~
craigching
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.

~~~
guipsp
But 0 isn't always null right?

~~~
cjensen
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.

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

~~~
cjensen
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.

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

------
kbenson
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?

~~~
oh_sigh
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++

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

~~~
oh_sigh
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.

~~~
kbenson
> 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."

------
danieldk
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.

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

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

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

~~~
kbumsik
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](https://gitlab.com/fbb-
git/cppannotations/commits/master)

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

~~~
stephen82
Then you will need this as well [https://github.com/AnthonyCalandra/modern-
cpp-features](https://github.com/AnthonyCalandra/modern-cpp-features)

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

------
DrTung
Good read but class template argument deduction is not mentioned.

