Errata

I'm a little way through your new book, and have to say I think its pretty good. Just a quick comment on p112 about the vtbl layout. I'm a COM veteran, so I've had a reasonable amount of experience in it.

The gcc layout is different because of the different style of 'offset correction' techniques used. That is the correction of the 'this' pointer when it gets passed to the function. gcc 2.9x and older (non MS) compilers use a technique where the offset is placed in the vtable next to the functions address. Thus when the function is called the objects pointer passed in is corrected by this offset, before the function is actually called.

In the case of VC + later gcc compilers, the technique used is function 'thunking' where a new function is created which corrects the pointer before the base classes function is called (now with the correct 'this'). The technique is known as 'vtable thunking'.

To illustrate the problem:

  struct IA
  {
    virtual void __stdcall DoA() = 0;
  };

  struct IB:public IA
  {
    virtual void __stdcall DoB() = 0;
  }

  struct CBase
    :public IA
  {
    /* override */void __stdcall DoA() { printf("CBase::DoA\n"); }
  }

  struct CDerived
    : public IB
    , public CBase
  {
    /* override */void __stdcall DoA() { printf("CDerived::DoA\n"); }
    /* override */void __stdcall DoB() { printf("CDerived::DoB\n"); }
  }

  int main(int,char *[])
  {
    CDerived der;
    IA *aptr = static_cast<CBase *>(&der);
    IA *bptr = static_cast<IB *>(&der);
  }

In this situation both aptr + bptr point to a IA interface pointer, but they are different IA interface vtables. So that a call to aptr is correctly routed to CDerived's DoA() function the 'this' pointer passed to the call is corrected so that it when its passed into CDerived's DoA() the this pointer is correctly set.

And in this case if you looked at the gcc2.9x vtable you would see different numbers for v3 and v4 (from your example) which would make this correction.

Ie in gcc it is the callers responsibility to fix up this. With VC and later compilers the callee does the fix up, through a generated/invisible 'thunking' function. This can be seen/explained via the disassembly more simply :)

C: I would like to comment on the spin mutex section (10.2.2). I think this class is not really "spinning" because of the call to sched_yield(). In all other implementations I have seen, a spinlock basically loops until the locking succeeds. The idea is that if the resource is only locked for a very short time, busy looping is cheaper than a context switch. So spinlocks may be very effective especially when there is a lot of contention. (Needless to say, this only makes sense on multiprocessor machines!)

A: You make a good point. I've updated the STLSoft spin_mutex class(es), so that it is now a class template - spin_mutex_base - that takes a policy class that determines whether the spin incorporates a yield or not. There are two specialisations typedef'd: spin_mutex_no_yield and spin_mutex_yield.

The spin_mutex class is now a typedef to spin_mutex_no_yield, unless STLSOFT_OLD_SPIN_MUTEX_BEHAVIOUR is #define'd, in which case it's a typedef to spin_mutex_yield.

These changes are available from STLSoft 1.9.1. beta 29 or later..

I have tried some of your samples, both in Borland 5.6.4 and GCC 3.2, and there is a problem with page 209, listing 14.1, which fails unexpectedly on GCC. I had to add the next overload:

  void reject_subscript_operator(void * const)
  {}

because GCC would fail to use the function for

  reject_subscript_operator(pv);

instantiating instead the template. I don't know which of those compilers is following the Standard rules for resolution, as there is a cv-qualifier implied, and C++ standard is pretty difficult to understand in such themes. Or are we in front of unspecified/implementation-specific material?

Since the writing of the book, the refinement of the Range concept has continued, and a new category - the Indirect Range - has been introduced which abstracts callback enumeration APIs. See www.rangelib.org for details. The new category is also discussed in the article "Ranges, part 1: Concepts and Implementation" in the October 2004 issue of C/C++ User's Journal.

Sam makes the following important point:

"Use of

  std::for_each(&ari[0], &ari[10], print_int);

is incorrect. Even thought it is likely to work for any compiler you will ever use, it is still ill-formed. It should be

  std::for_each(&ari[0], &ari[0] + 10, print_int);

The same applies for

  std::for_each(&ari[0], &ari[dimensionof(ari)], print_int);

which should be

  std::for_each(&ari[0], &ari[0] + dimensionof(ari), print_int);

and for

  std::for_each(&ar[0], &ar[N], f);

which should be

  std::for_each(&ar[0], &ar[0] + N, f);.

This technique, from Chapter 25, was presented to the world in the "Fast, Non-intrusive String Concatenation" article in the June 2004 issue of C/C++ Users Journal. Thanks to a reader - Sean Kelly - for pointing out that the technique assumes that the parameterising string class stores its character data contiguously. That should be ok in practice, since we know of no string class - std or otherwise - that does not do so. Nonetheless, it's a bug, and has been addressed in version 1.8.1 release of the STLSoft libraries.

It says a 'dynamic library is complete'. Jonathan says that this is "not necessarily so - you can have imports and exports within a dll - such that the dll has to have functions imported from it from the executable or another dll. I have used this on a dll system loading a device driver where the dll, had to use standard library calls, and they only worked with the standard library functions linked into the executable (as they were correctly set up prior to main). This was a while ago using Watcom/DOS but the point is the Dll standard supported imports/exports. I dunno if its used much with Win32 if at all.".

While I certainly take the point that a dynamic library may (and in fact almost always does) depend on symbols in other dynamic libraries, I'm not confident that one can depend on symbols defined inside the loading process; naturally this is a perfectly normal and well-used technique for static libraries. Certainly I'm pretty sure that one cannot do this with Win32 DLLs. I'd be interested to hear from anyone whether this is possible under UNIX/Linux.

the code illustrating the use of stlsoft::true_typedef with int should read

true_typedef<int, . . .> i1(1000);
int                      i2(1001);
true_typedef<int, . . .> i3(i2);
 

i1 <<= 2;
i1 = -i3;
i3 = i2 + i3;

I've got a comment on your dimensionof() macro (14.3). I liked it a lot and reimplemented our version of dimensionof() for all compilers that supported the syntax. Unfortunately it bombed in the wrong place. The situation boils down to:

  void f()
  {
    static const struct { int n; int m; } a[] = {{1,2},{3,4}};
    const int size = dimensionof(a);
  }

This refuses to compile as template parameters must have external linkage.

I don't see a clean solution except rewriting the code to use a type with external linkage. But as not all of our compilers support namespaces, it would mean inventing a suitably ugly typename to prevent nameclashes. (So, for now, I commented out the new version.)

I guess this caveat should be mentioned in the errata.

In the definition of 'value type' on page xxix, it is said that "Equality (and inequality) is reflexive, symmetric, and transitive". Inequality is not reflexive or transitive.

There's a problem with the use of the dimensionof() construct on arrays, when the type of the array is a locally defined struct/class. This is due to the restrictions on linkage of template parameterising types, as is discussed in Chapter 34.

The solution in the STLSoft libraries is pretty much a hack at this point. The stlsoft_num_elements() construct, which is equivalent to the dimensionof construct, uses a helper macro, called stlsoft_num_elements_() which implements that normal, "C", approach using sizeof(x) / sizeof(0[x]). It's hardly pretty, or unambiguous, however, so a better named macro is planned in the near future.

the sentence "The first using declaration is necessary because LSA_UNICODE_STRING type is defined in the global namespace, so Koenig lookup does not apply." should instead read "The first using-declaration is necessary because LSA_UNICODE_STRING is defined in the global namespace, and when Koenig Lookup goes searching there it won't find anything."

the statement

  process_array(apb, 10);

should read

  process_array(apb, dimensionof (apb));

Would you show me a small example of how the returning of the parameter f, where f is a caller-supplied function that is applied to elements of parameter c, would be used?

Thanks for taking the trouble to write to me.

The practice of returning a function object, by value, from an algorithm to which its been passed is widely followed in STL. One important reason is so that one can chain operations succinctly. Passing, and returning, by value is well founded in order to equally support passing function pointers and function object instances.

So, I wrote the for_all_postinc() to return f to follow this convention.

As for an example, I guess one could use it as follows:

  std::vector<int>  vi = ...;
  std::list<int>    li = ...;

  for_all_postinc(vi, for_all_postinc(li, some_function));

The advantage would be where the function object has a non-default constructor, so it saves the coder from having the potentially maintenance-fragile situation of specifying the same thing twice. It also, perhaps, affords the compiler better optimisation opportunity.

Hope that helps.

Q: The purpose of the parameter size is unclear for me. It seems that it is not used in the body of the first function make_array_proxy().

A: The first make_array_proxy() invokes the first array_proxy constructor, so there's no need to explicitly specify the size. The compiler "sees" an array (rather than a pointer) inside this function as well as outside.

Q: Did you consider an alternate code structure, such as the following?

...
}
else
{
  return unknown;
}
...

A: I think the reason I did it as shown was that the strcmp() tests were all in a clearly separate section, denoted by the extra indentation.

It could just as easily be as you say, but that's just not my style.

Q: Which wording do you prefer: "multi threaded" or "multi-threaded"?

A: I think I prefer the latter, but what I prefer most of all is to be consistent. ;)

Instead of:
  "John was also a one of the reviewers for this book"
it should read:
  "John was also one of the reviewers for this book"

the phrase "..., but the friendship declaration means that it can be altered by Rectangle."should read "..., but the friendship declaration means that it can be altered by LinkedList."

the phrase "Evaluates to true if r has reached its end condition, false otherwise" should instead read "Evaluates to true if r has not reached its end condition, false otherwise"

the phrase "Not that I'm not saying that the approach of multi_array is wrong, ..." should instead read "I'm not saying that the approach of multi_array is wrong, ..."

the phrase "But remember that auto_buffer does support non-POD types, and ..." should instead read "But remember that auto_buffer does not support non-POD types, and ..."

the template argument SPACE is erroneously specified as space

the template argument SPACE is erroneously specified as space

listing should read

 
PCAChar LongToStringA(LONG value) 
{ 
  const size_t  I2S_LIMIT = 0x7f; 
  TssValue      tssvalue  = Tss_GetSlotValue(sh_hkeyA); 
  PAChar        buffer; 
  if(0 == tssvalue) 
  { 
    tssvalue = (TssValue)Mem_Alloc_NoTrack(sizeof(AChar) * (1 + I2S_LIMIT))); 
    . . . 
    Tss_SetSlotValue(sh_hkeyA, tssvalue, NULL); 
  } 
  buffer = SyCastRaw(PAChar, tssvalue); 
  return integer_to_string(buffer, 1 + I2S_LIMIT, value); 
} 

in the copy-assignment constructor member initializer list m_monitorFN should read m_monitor

argument p in

  return static_cast(p);

and

  return static_cast(p);

should be m_p

in the phrase "... concatenation seeding (see section 24.4) ...", 24.4 should read 25.4

in the phrase "... the well-known C+ mechanism ...", C+ should read C++

in the phrase "... shim general case -- the second in the list above -- is defined ...", second should be first

The member types pointer_type and reference_type should be pointer and reference, respectively

The variable a should be b in the expression boost::polymorphic_cast<Derived*>(a)

The variable p should be py in the expression func(interface_cast_noaddref<IX>(p))

The GetInstance() method must be defined static.

The GetInstance() method must be defined static.

The GetInstance() method must be defined static.

"Without the static, the linker would complain ..." should read "Were it not declared within an anoymous namespace, the linker would complain ..."

"Stipulating the object files for object1.cpp, object2.cpp and object3.cpp ... ..." should read "Stipulating the object files for main.cpp, object2.cpp and object3.cpp...".

"Before we and move on ..." should read "Before we move on ...".

There are two scope2 variables. The second one should be scope3

  printf("%s => %s", path, find_filename(fileName));

should read:

  printf("%s => %s", fileName, ffn(fileName));

The MIL of mem_buffer written as:

  mem_buffer(size_t size)
    : m_size(cb)
    , m_buffer(. . .)

should read:

  mem_buffer(size_t size)
    : m_size(size)
    , m_buffer(. . .)

The variable i8 should be named si8. The variable ui64 should be declared as of type uint64_t.

The comments for contexts 2 and 3 in the code should be the opposite way round.

unused_return_value_monitor constructor should not be explicit, otherwise the code in listing 28.2 (page 442) will not compile. (The reason this crept in is that I condensed the actual separate one parameter and two parameter constructors in the STLSoft class into two for the book listing, and instinctively added the explicit. There's something to be said for compiling one's writing ...

The reference to section 10.11 in fact refers to section 20.11

class RefCounter also derives publicly from S, as well as from T (as shown in the code snipet from the beginning of section 22.4)

The ParentClass token in the member initialiser list for the second constructor should be T.

The definition of must_be_pod is missing the preceeding template <typename T>

There are two ? tokens, when there should only be one:

  # define assert(x) ((!x) ?

    ? assert_function(#x,__FILE__,__LINE__)

    : ((void)0))

The declaration
  Resource *m_vs;
Should read:
  VisualSystem *m_vs;

In the 3rd ctor of ptr_cast, the member initialisation has two typos:

  ptr_cast(pointer_type pt)
    : m_p(t)

should be

  ptr_cast(pointer pt)
    : m_p(pt)

the phrase

"... mystuff_gcc.a (mystuff_a.lib for Win32) ..."

should read

"... mystuff_gcc.a (mystuff_gcc.lib for Win32) ..."

Types of m_var and m_revert were defined in terms of V, when they should be in terms of T.

  template< typename T >
  class ValueScope
  {
    ...

  private:
    T &m_var;
    T m_revert;
  };

The statement
  return OnParseSymbol();
should read
  return cw.OnParseSymbol();

Instead of:
  "... experience a memory system during debugging ..."
it should read:
  "... experience a memory exception during debugging ..."

"Anytime in this chapter that I refer to operator &() it will be the unary form, which is the address of operator. The binary form, which is the bitwise OR operator, is an entirely different beast."

Should read:

"Anytime in this chapter that I refer to operator &() it will be the unary form, which is the address of operator. The binary form, which is the bitwise AND operator, is an entirely different beast."

The statement
  int *&device = dc.m_device;
Should read:
  int &device = dc.m_device;

The statement
  int *&device = dc.m_file;
Should read:
  int *&device = dc.m_device;

"rationale" should be "rational" (twice)

Instead of:
  "[Vand2003]. The Comprehensive Guide ..."
it should read:
  "[Vand2003]. The Complete Guide ..."

the final reference to DayofWeek should be DayOfWeek

Instead of:
  "Comeau, GCC, and Intel do not supported nested functions in either guise."
it should read:
  "Comeau, GCC, and Intel do not support nested functions in either guise."

The line:

  if(NULL==value)

should read:

  if(NULL==thing)

The variable declaration:

  Tss key_func(. . .);

has a typo - it's TssKey - and also looks too much like a function declaration. It's better expressed as follows:

  TssKey key_func(closeThing, . . .);

the ic variable should be of type IImpC*, not IImpCpp* as shown

the three instances of reinterpret_cast<ULARGE_INTEGER&) should be reinterpret_cast<ULARGE_INTEGER&>

the default constructor method should be named LinkedList, not Rectangle

The decrement operator "--" has not been printed correctly, instead looking like the "—" character.

The interpret() function return type is Type, and not void.

"... flavous of Linux ..." should be "... flavours of Linux ..."

There is a semi-colon missing from the line str2.Empty();

The statement
  pthread_mutex_lock(&service.unlock);
should read
  pthread_mutex_unlock(service.lock);

The use of the member type class_type (as described later in section 18.5.3; standing for the full type of a specialised class template, or the type of a non-template class) is premature. Each occurrence of it in this listing should instead be atomic_integer

the statement

  return WeekDay.m_value;

should read

  return DayOfWeek.m_value;

the expression

  &C::P##_offset

should read

  &C::P##_offset##_C

the variable cchDest is declared twice

the author is Frederick P. Brooks

the expression

  #define dimensionof(x) sizeof(byte_array_of_same_dimension_as((x)));

should read

  #define dimensionof(x) sizeof(byte_array_of_same_dimension_as((x)))

the expression

  buffer[index] = '\0';

should read

  stack_buffer[index] = '\0';