2

I'm a newbie on cplusplus, and thanks for answering my questions.

The paragraph in the stl_list.h is read as follow:

// NOTA BENE
// The stored instance is not actually of "allocator_type"'s
// type.  Instead we rebind the type to
// Allocator<List_node<Tp>>, which according to [20.1.5]/4
// should probably be the same.  List_node<Tp> is not the same
// size as Tp (it's two pointers larger), and specializations on
// Tp may go unused because List_node<Tp> is being bound
// instead.
//
// We put this to the test in the constructors and in
// get_allocator, where we use conversions between
// allocator_type and _Node_alloc_type. The conversion is
// required by table 32 in [20.1.5].
  1. Where can I find the [20.1.5]/4 and the table 32 stuffs like that??
  2. Why is the specializations on Tp may go unused? What does this actually mean? (If you can provide a piece of simple source code and a simple explanation, I'll really be appreciate it.)
  3. What if people do need the specializations, is there a way to hack it??:)
Adam
  • 91
  • 4
  • Latin phrase for note-well. Similar to "pay attention to this" – Rapptz Dec 01 '12 at 06:32
  • @Rapptz I don't think the OP is asking what "Nota bene" means. – Matt Ball Dec 01 '12 at 06:35
  • @MattBall I kind of just presumed he was confused over the meaning when I skimmed over it. – Rapptz Dec 01 '12 at 06:36
  • I ... dooooo know about what "Nota bene" means ... I mean I don't understand the paragraph that he asks us to pay attention on... – Adam Dec 01 '12 at 06:46
  • This is a reference to the C++ standard. Unfortunately the standard is not [freely available](http://stackoverflow.com/questions/81656/where-do-i-find-the-current-c-or-c-standard-documents). I only have a copy of the C++11 standard which has no section 20.1.5 so perhaps someone with a previous version can provide an answer. – David Brown Dec 01 '12 at 06:49
  • 1
    %>_<% Why don't they open it for free... What are they afraid of ... T_T Ah.. – Adam Dec 01 '12 at 06:55
  • A recent draft of the C++11 standard is [N3337](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf). – Keith Thompson Dec 01 '12 at 07:35
  • @Robert Harvey: There are specific and answerable questions in here. Why is it "not a real question"? It certainly isn't ambiguous, vague, incomplete, overly broad, or rhetorical. – Billy ONeal Dec 02 '12 at 19:13

3 Answers3

3

  1. As Paul already indicated, these are references to the C++ standard. (Though the link he posted is copyright infringing and is an old copy of the standard) You read a reference here like the following:

    N3376 23.2.1 [container.requirements.general]/6
^^^^^ Version of the standard working paper being discussed
      ^^^^^^ Clause / subclause in the standard being discussed
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ section name
                          paragraph number    ^

    The reason you will see the section heading in []s printed in a standard reference is because different working paper copies of the standard will move sections around with respect to the clause number, but the section heading is relatively constant. (E.g. so if someone was using a later standard working paper than N3376, they could just do a search for [container.requirements.general] and find the section I was talking about)
    The paragraph number is listed separately to distinguish it from a subclause number. E.g. is 23.2.1 paragraph 1 in subclause 23.2 or the whole subclause 23.2.1? Separating it makes this clearer.

  2. This means that if you create a template specialization for an allocator class, a template specialization against a given type may go unused; and have the primary template used instead. This is because a specialization of an allocator is based on type. Let's say you have a primary template my_allocator<Type> and a specialization for my_allocator<int> which does something special for int. But std::list is a linked list, so it needs to allocate list_node<int> objects, not ints. So it creates a my_allocator<list_node<int>> instead, which leaves the specialization for <int> unused.
    See Stephan T. Lavavej's excellent series, Core C++, part 5 of n "Template Specializations" for more examples and nitty gritty.

  3. You can't; at least not in a standard way. The internal name that list uses for its list nodes is defined by the implementation. You can't name that type in portable code to make the specialization.

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
2

As to your question 1:

It appears to be a reference to the ISO C++ standard, relating to allocator requirements. I found a copy of the 1998 C++ standard here:

http://www-d0.fnal.gov/~dladams/cxx_standard.pdf

have a look a page 354 (page 380) in the pdf. Table 32 appears 2 pages on.

As for your questions 2 & 3, that is way above my pay-grade. I might hazard that by specialisation they mean a class derived from Tp. But I just don't know for sure.

Andro Selva
  • 53,910
  • 52
  • 193
  • 240
Paul
  • 21
  • 1
1

For the std::list type, it will (generally) utilize a class like node (or something similar) to hold the value of type Tp as well as pointers to previous and next elements. Obviously when you use an allocator to create these values, what is needed is not actually a type of Tp but a type of node<Tp>. This is the reason why they need to rebind the allocator. Hence further along in the list class, you'll see something like std::allocator<Tp>::template rebind<node<Tp>>.

The reason specializations may go unused is that internally it's allocating node<Tp> instead of Tp. Hence, if we write our own allocator class and then specialize it for Tp, this specialization won't get used for std::list. For example:

template <typename T>
class my_allocator
{
     //typedefs
     pointer allocate(...);
     void deallocate(...);

     //Other member functions
};

template <>
class my_allocator<int>
{
     //Some specialization for int
     ...

};

Now, if we used std::list<int, my_allocator<int>>, since the allocator gets rebound, what we may end up utilizing my_allocator<node<int>> which is not specialized, hence will use the non-specialised version for my_allocator.

If such specializations are required for something like std::list, you may be able to hack it by specializing on whatever internal node-like class std::list uses, but this would almost certainly be non-portable, and I would recommended against it.

Yuushi
  • 25,132
  • 7
  • 63
  • 81