6

I came across this post where an iterable queue was introduced. The OP used a protected variable called c from the std::queue in the implementation.

Is this totally valid? Would this variable have the same name over all implementations? In other words, does the standard state clearly that this variable must be named c?

Community
  • 1
  • 1
Humam Helfawi
  • 19,566
  • 15
  • 85
  • 160

1 Answers1

10

For reference, the exact definition of std::queue is listed here. So in answer to

In other words, does the standard state clearly that this variable must be named c?

Yes, it is in this case (and it is similar for other container adapters);

template <class T, class Container = deque<T>>
  class queue {
  protected:
    Container c;
    // ...
  };

In general, however, the names of the protected and private names and members are not standardised since the types are not all built to be derived from and the implementation is an implementation detail (and doesn't form part of the public API); e.g. std::vector doesn't list any protected names.

Some std containers and classes do define the names of protected members, in particular the iostreams library comes to mind - basically the types that are intended to be derived from.

As a follow up - do all the compilers/libraries use c? It appears as though at least the mainstream ones do (libstdc++, libc++ and MSVC). libstdc++ is interesting in that it includes the follow comment on the variable;

/**
 *  'c' is the underlying container.  Maintainers wondering why
 *  this isn't uglified as per style guidelines should note that
 *  this name is specified in the standard, [23.2.3.1].  (Why?
 *  Presumably for the same reason that it's protected instead
 *  of private: to allow derivation.  But none of the other
 *  containers allow for derivation.  Odd.)
 */
_Sequence c;
Niall
  • 30,036
  • 10
  • 99
  • 142
  • I wouldn't be surprised if this were an editorial accident in a sense: a variable name given for exposition that's accidentally become normative. Even if that's not the case, it's not wildly speculative to imagine that a stdlib implementer may have the same thought and treat it as non-normative. As such, despite the apparent guarantee, I'm still not sure I'd rely on this. It's a strange and "broken" usage of `std::queue` anyway. – Lightness Races in Orbit Aug 11 '16 at 09:19
  • @LightnessRacesinOrbit. Could be. IIRC, in the TR1, `std::array` had a name for the data member, but there was an associated comment, to the effect of `T elems[N]; // Exposition only`. I'm not sure what the motivation for the variable `c` in the `std::queue` is, it seems to have been there as far back as C++98. – Niall Aug 11 '16 at 09:24
  • @Niall: If we cared more (do we? I don't :D) we could take a census of existing mainstream implementations, and _if_ they all use `c` then ask the committee to confirm whether the intention is for this to be expositional or not (perhaps even by adding a note in the text itself). And if they don't then we already have our answer, I guess. – Lightness Races in Orbit Aug 11 '16 at 09:26
  • @LightnessRacesinOrbit. Now that you said it - curiosity killed the cat. It looks like libstdc++, libc++ and MSVC all use the name `c` (but the `Container` type name varies (libstdc++ uses `_Sequence`). – Niall Aug 11 '16 at 09:36
  • libstdc++ contains the following comment as well - `/** 'c' is the underlying container. Maintainers wondering why this isn't uglified as per style guidelines should note that this name is specified in the standard, [23.2.3.1]. (Why? Presumably for the same reason that it's protected instead of private: to allow derivation. But none of the other containers allow for derivation. Odd.) */` - it seems as the maintainers are aware of it... – Niall Aug 11 '16 at 09:36
  • 1
    Also I like how they literally have a style guideline mandating that things get "uglified" – Lightness Races in Orbit Aug 11 '16 at 09:42
  • std::queue is not a container, it's a container adapter. and he other container adapters (priority_queue and stack) follow the same convention of naming the underlying container "c". The comment in the libc++ code seems inaccurate. – Arvid Aug 11 '16 at 14:56
  • 1
    @LightnessRacesinOrbit This is common in implementations of the standard library so that the implementation uses only names reserved to the implementation, thereby avoiding collisions with names used by the application. If the implementation used a pretty name like `length`, then the application could break the implementation by doing `#define length 0`. – Raymond Chen Aug 12 '16 at 05:42
  • @RaymondChen: A leading underscore (which is reserved to the implementation for precisely this reason - maybe throw in a capital letter for good measure) will do, no? Maybe that's what they mean by "uglifying" but it's not _that_ ugly.. – Lightness Races in Orbit Aug 12 '16 at 09:00
  • 2
    @LightnessRacesinOrbit If you read the linked source code, you'll see that all internal identifiers begin with either an underscore and capital letter, or two underscores. (These are identifiers reserved to the implementation.) So it's rather apparent that that's what they mean by uglification. If you search for the style guide, you can find [a formal definition of uglification](https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html). – Raymond Chen Aug 12 '16 at 14:57
  • @Raymond Half of what you just said is repeating what I'd already said... fell into a bit of UB-triggered time travel, did we? ;) Thanks for the link, though, which confirms that "uglification" is indeed nothing more than sticking to reserved identifiers. – Lightness Races in Orbit Aug 12 '16 at 17:10
  • @LightnessRacesinOrbit I was just pointing out that what you said could be answered by (gasp) reading the source code. – Raymond Chen Aug 13 '16 at 14:13
  • @RaymondChen: Actually the answer to what constitutes "uglification" can only be found with the formal definition of uglification that you provided, not the source code :) – Lightness Races in Orbit Aug 13 '16 at 15:47
  • @LightnessRacesinOrbit You can infer the definition from the source code. The formal definition was just for confirmation. – Raymond Chen Aug 13 '16 at 16:19
  • @RaymondChen: Sorry, no, I can't agree with that. Just because some variable is annotated with text stating that "some other variables are uglified", doesn't mean you can look at the overarching convention of using leading underscores and know just from that that that's all that uglification means! It might make sense if you already know the answer, but otherwise it's wild extrapolation. Anyway, we have our answer now so that's that. (too many "that"s...) – Lightness Races in Orbit Aug 13 '16 at 17:43