43

For instance why does most members in STL implementation have _M_ or _ or __ prefix? Why there is so much boilerplate code ?

What features C++ is lacking that would allow make vector (for instance) implementation clear and more concise?

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
Łukasz Lew
  • 48,526
  • 41
  • 139
  • 208
  • Which implementation of STL are you referring to? – morechilli Sep 22 '09 at 15:58
  • 7
    And why do you care about the implementation details? – David Thornley Sep 22 '09 at 16:02
  • 2
    Some STL implementations are deliberately written to be terse. The way the code is written is something well out of scope of the standard - the fact your implementation is standards compliant is all the information you should need in most circumstances. – Andrew Khosravian Sep 22 '09 at 16:02
  • 1
    I'm talking about implementation provided in linux with gcc. I care about the details because I read the source when documentation fails to provide me detais. – Łukasz Lew Sep 22 '09 at 16:23
  • 44
    You're going to get a lot of negative comments, but I applaud you for both being willing to read the code and to ask why it was written the way it was. Too many developers wouldn't try, and wouldn't care. – Kristopher Johnson Sep 22 '09 at 17:13
  • 6
    @Łukasz Lew: good that you read the code! As soon as you read certain amount of the code, suddenly, STL implementations stop being unreadable and become clear and obvious. – P Shved Sep 22 '09 at 18:03
  • 5
    When the documentation fails to provide you details, it is because the details are subject to change. So that's not a very good reason to read the source code. Anything you find in the source code, but not in the documentation may change in the next compiler release, so you shouldn't rely on it. – jalf Sep 22 '09 at 20:30
  • 4
    @Pavel: indeed that happened. I've read the code all day and now it's easy to read. Moreover, I've learned a few nice C++ idioms and patterns. Learned how exactly allocators work, how you can get readable code using advanced iterators, and more! – Łukasz Lew Sep 22 '09 at 22:45
  • @DavidThornley Maybe, people like reading largely successful codebases to learn from them. Your attitude is puzzling. – user904963 Dec 21 '21 at 01:09

3 Answers3

41

Implementations use names starting with an underscore followed by an uppercase letter or two underscores to avoid conflicts with user-defined macros. Such names are reserved in C++. For example, one could define a macro called Type and then #include <vector>. If vector implementations used Type as a template parameter name, it would break. However, one is not allowed to define macros called _Type (or __type, type__ etc.). Therefore, vector can safely use such names.

fredoverflow
  • 256,549
  • 94
  • 388
  • 662
robson3.14
  • 3,028
  • 2
  • 20
  • 19
  • +1 Indeed. GCC's implementation even contains a comment explaining why queue's underlying container is called c and is not "uglified as per style guidelines". – UncleBens Sep 22 '09 at 16:16
  • 3
    So C++ could have been improved by making macros system more powerfull :) – Łukasz Lew Sep 22 '09 at 16:24
  • 1
    That still doesn't protect against poorly named user defined macros that conflict with names of types or member functions (e.g. #define size 2). – bk1e Sep 23 '09 at 01:13
6

Lots of STL implementations also include checking for debug builds, such as verifying that two iterators are from the same container when comparing them, and watching for iterators going out of bounds. This involves fairly complex code to track the container and validity of every iterator created, but is invaluable for finding bugs. This code is also all interwoven with the standard release code with #ifdefs - even in the STL algorithms. So it's never going to be as clear as their most basic operation. Sites like this one show the most basic functionality of STL algorithms, stating their functionality is "equivalent to" the code they show. You won't see that in your header files though.

AshleysBrain
  • 22,335
  • 15
  • 88
  • 124
2

In addition to the good reasons robson and AshleysBrain have already given, one reason that C++ standard library implementations have such terse names and compact code is that virtually every C++ program (compilation unit, really) includes a large number of the standard library headers, and they are thus repeatedly recompiled (remember that they're largely inlined and template-based, whereas the C standard library headers only contain a handful of function declarations). A standard library written to "industry standard" style guidelines would take longer to compile and thus lead to the perception that a particular compiler was "slow". By minimizing whitespace and using short identifier names, the lexer and parser have less work to do, and the whole compilation process completes a little bit faster.

Another reason worth mentioning is that many standard library implementations (e.g. Dinkumware, Rogue Wave (old), etc.) can be used with several different compilers with widely different standards compliance and quirks. There's frequently a lot of macro hackery aimed at satisfying each supported platform.

Drew Hall
  • 28,429
  • 12
  • 61
  • 81