std::vector of containers: better use pointers

Typical example: If you heavily use a vector of map, it’s more convenient to use a vector of pointers to maps. The java way.

If you drop the “pointers to”, then when you retrieve the map from the vector, you often get a copy, unless you do this:

map<int, int> * mapPtr = &v1[i];

By the way, here’s an initializer for std::map:

vec.push_back(map<int, int>{{32,1}} );

typedef syntax – demystified

See P178 [[nittygritty]] for a common usage of typedef — suppose you want to change the underlying type behind mytype from int to long or float…

I find the typedef syntax not as simple as it appeared. is the best explanation of the very confusing typedef syntax.

        int x; // declares a variable named ‘x’ of type ‘int’
typedef int x; // declares a type     named ‘x’ that is ‘int’

        int(*F)(size_t); // declares a variable named F of type ‘int(*)(size_t)’
typedef int(*F)(size_t); // declares a type     named F that is ‘int(*)(size_t)’

If you add the “typedef” prefix, instead of declaring a VARIABLE, you’ve declared a new TYPE-ALIAS instead.

c++syntax – class template – brief notes

[[absolutionC++]] covers ordinary class template and subclassing an /unconcretized/ class template. The syntax can be quite “flexible”. I guess some compilers might allow you to omit a symbol here or there. I prefer to follow the full syntax, same habit as with c# lambda expressions. Less likely to confuse myself when reading the code 6 months later.

In practice, we just need to follow a consistent syntax that works. No need to know if some unusual syntax is standard-conforming or not. But on some occasions like online quizzes, we may need to play the language lawyer. Let’s look at one simple aspect — It’s good to know where the dummy type name “T” or “S” should (not) be repeated.

After template , and when we first name our new class, we don’t put on its head —

template class BB   {};

However, subclassing this base class uses slightly different syntax —

template class DD: public BB{};

For an IKM c++ quiz, I used windows gcc to FAIL all of the below —

template class DD: public BB{}; //WRONG – new template must not be “decorated”
template class DD: public BB{}; // WRONG – base template must be “decorated”
template class DD: public BB{}; //WRONG – breaking both rules

Q: Do we ever use the class template BB without a concrete type and without a dummy type?
%%A: I haven’t seen any example. Looks like non-standard or obscure syntax

preprocessor syntax – a few tips #IKM

Never quizzed except in online QQ tests.

Based on an IKM question and my research on P372 [[ARM]]

1) redefine and “undef” a name is fine. I feel the “undef” feature is rather useful but unavailable in the compiler.

2) can check if a macro is defined or not, using
#if defined AA
#ifdef AA
#if !defined AA
#ifndef AA

3) a macro can appear in another preprocessor code, but this kinda code is frowned upon
#define AA2(jkl, xyz) {#xyz ## #jkl}
char result[] = AA2(def, abc); // will produce “abcdef” without space

##common L-value expressions in c++

Contrary to some claims, I feel an expression can be “usable as either L-value or R-value”.

Further, I feel most (or all?) L-value expressions are usable as R-values.

It’s instructive to look at all the expressions that can be L-value expressions

– pointer variable, but not a mere address. See
– pointer variable unwrapped, like *(myPtr)
– ref variable
– nonref variable
– subscript expression
– function returning a reference
– function returning a pointer? No

Warning ! I call this the little dark corner of L-value. Any time a function (or overloaded operator) modifies an object and returns a non-const reference thereto, you invite trouble because you allow it as a L-value. The modified object is now on the LHS of assignment!