Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Reading C++ source code can obviously be a good way to learn and is just plain interesting when its a feature you know very little about. As far as standard library source goes this is difficult due to the uglifying of names.
Is the uglifying done through some sort of post-processing of the source code before it's inclusion in the standard library? If so, what happens to the original source code? Are there any repositories of non-uglified C++ Standard Library source code?
I'm interesting in looking at C++11 and soon C++14 features in particular.
I can't imagine maintaining code in this form would be very fun....
EDIT:
There's a proposal to do away with this process here.
When learning from standard library implementations, please first of all note that the standard library has to obey certain harsh constraints which don't apply to code written by normal users. Also, some of the operations done by standard C++ libraries are somewhat esoteric and I would be worried if they were ever used by normal user's code (if you have a low-level library team in you company, they might do some similar stuff, though). In particular on constraint standard libraries need to obey is that none of the names used conflicts with any names used anywhere by users. Since users could define funny macros, the standard library needs to use names reserved for the standard library in user-visible contexts, e.g., the header files:
names used in the standard C++ library for classes, functions, enumerations, etc. or tmeplates thereof (when applicable) are reserved.
all names starting with an underscore followed by a capital letter or names containing two consecutive undersscores are reserved in all contexts.
there are a couple of other reserved names which are, however, typically not used in the headers because they are mostly not reserved in the context of macro names.
The things you specifically do not want to copy from the standard C++ library is the naming of the include guards: these typically start with one or two underscores and are all uppercase characters. Users are not allowed to use any of these identifiers unless they are specifically allowed to use them (e.g. you can use __FILE__ and __LINE__ but you are not allowed to, e.g., write _FOOBAR anywhere in your program where it could be expanded by a macro (that is, I think you can write "_FOOBAR").
To answer your actual question: all standard C++ library implementations I'm aware of (libstdc++, libc++, Dinkumware, RougeWave, and my own) are written using "uglified" names and there is no program converting them into this form. Basically, any program would have to deal with lots of exceptions which isn't quite feasible. I think, standard C++ library implementers just get used to the funny names. For my implementation I had made an effort to name everything with a common prefix so that the uglification could be undone using a simple sed script but I haven't followed that pattern everywhere.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Looking for specific C++ environments (compilers, OSes, hardware, etc.) for which there's no standard library (e.g. "x version of gcc for the Nintendo 3DS")
Some C++ libraries such as Box2D or TinyXML2 that aim to be uber-portable use very little of the standard library, if at all. I don't fully understand this approach, however. What actively-used C++ environments lack support for (most, if not all) of the standard library?
C++ standard library support can vary between different compiler vendors and even between different versions of the same compiler. This is especially true on embedded systems and on the various consoles.
By "vary" I mean there can be bugs, features implemented differently, or even missing features. Android for example has a very minimal C++ standard library implementation.
There are many weird and wonderful C++ compilers out there; it's not just GCC and Visual Studio. Nintendo for example uses the Green Hills compiler.
So because of the variety of compilers out there, the best way to support a large number of them is to stick to only the features provided by the C standard library. Many portable libraries even avoid using more modern C++ features.
The only environments that I can think of are freestanding ones (operating system and single process embedded programs). Of course, some developers actively avoid using the STL, but this is more a design decision than a lack of support in the environment. I believe the biggest hurdle in these constrained environments is exception support (which many STL functions throw). To get support for these one has to port a C++ ABI and unwind library (to do stack unwinding and goto to the catch statement). There is nothing stopping one from implementing these required bits, but it is more dependencies which obviously result in bloat just for basic support for something like linked lists. To port the ABI see the OSDEV wiki entry.
There are other dependencies for the newer C++ standards (C++11 onwards). I can imagine std::thread requires a threading implementation such as pthreads. std::chrono will probably need some intermediate layer implemented between it and C standard library time. There are probably more STL functionalities that require operating system support.
The Template part of STL is also quite important. Templates often increase final binary size quite substantially. In the case of a std::list for instance, std::list<MyClass1> and std::list<MyClass2> will result in the specialisation of two different containers. The code will look very similar but will be duplicated to handle their element type specifically. Other implementations of linked lists often use a void pointer to link nodes and then cast it to the appropriate class when required. In this way, there is one instantiated list class for ints, char *, MyClass1, etc. The increased binary size is often unacceptable in embedded environments, but it must be noted that it also becomes a problem when LibA implements LibA::LinkedList and LibB LibB::LinkedList.
The quality of implementations has become less of a problem these days. It is also helpful that GCC targets many architectures so that the new compiler standards are available (as above, you still need to port some functionalities of the STL). The oldest GCC I have used was GCC v4.3 or something like that for an embedded PowerPC device. That was released in 2010 and had full STL support.
In summary, the need for libraries with a very focused functionality set can still help, but in my opinion they decrease how many platforms your project targets if they provide functionalities which wrap OS-dependent behaviour. For raw data structure and algorithm support you can't go wrong. In the end, you have to target some subset of platforms. In C++11 I believe you target 99% of used desktop/server operating systems and 99% of embedded Linux devices. As highlighted in another answer, Android has been a problem but this page seems to highlight to get all the bits required to get a really modern environment.
The Simple Answer is, when you choose not to include STL packages.
With most IDE's if your project has no #include <package_name> items that are calling to the STL, then the STL is not included at compile time.
Although there may be cases where you have to specifically exclude STL through the IDE/compiler
One of the big reasons to avoid the STL is to reduce the final compiled file size.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I normally use C#, not C++, which is the reason I asked this question.
I've seen it as normal in most C++ code to name constants in capitals with underscores, LIKE_THIS.
However, when I see C++ code (not that I've seen much of it), it looks immediately different from C#. Aside from the generic abundance of pointers and less formally-named/abbreviated stuff like WndProc and the Hungarian notation, half of the stuff is in all-capitals.
Even excluding constants, stuff like method names, physical structures/C++ things themselves (HRESULT), or sometimes even physical data types (BOOL) are in all-capitals with underscores.
This may/may not be common in C++ style (although I can't find it anywhere on google), why is this abundance of capitalization common in so many places? Or, where did it come from?
I've seen it as normal in most C++ code to name constants in capitals with underscores, LIKE_THIS.
Usually, all-caps identifiers are used for macros, to avoid confusion with "real" compiler names. Since in earlier C macros were the only way to have constants usable e.g. in array sizes, some people adopt this style for all constants (or at least for enum values). Personally, I just leave them for macros, where it's actually useful to make a distinction.
However, when I see C++ code (not that I've seen much of it), it looks immediately different from C#. Aside from the generic abundance of pointers and less formally-named/abbreviated stuff like WndProc and the Hungarian notation, half of the stuff is in all-capitals.
That would be the Windows API style, which comes from the late eighties, so it's normal that it looks nothing like .NET.
Windows-related types are typically all-caps, I suspect that comes from the fact that they too were macros (although currently they are all typedefs) actually, I just checked the windows.h from the Windows 1 SDK, and they were typedefs even then, so probably it was some kind of stylistic choice; constants are still macros, though.
Hungarian notation was invented in Microsoft by Charles Simonyi, and was widely adopted (and misunderstood) internally in the early years of Windows.
As for the abbreviations, that's typical of older APIs (look at the C standard library or the POSIX APIs, they are even terser), and I think that it can be justified both by technical and practical arguments:
older compilers and linkers had length limits for identifiers, which means that they wouldn't distinguish identifiers differing only from - say - the sixth letter onwards; so, you want to keep the meaningful letters at the beginning (incidentally, this seems to have influenced the C standard library - I heard that strncmp, strncat & co. have the n in the middle because of this);
when you work on an 80x25 terminal, you don't want to continue to scroll to read a single line, so names like, say, AttachedPropertyBrowsableWhenAttributePresentAttribute don't strike you as a stellar idea;
also, people worked in C++ way before Visual Studio and IntelliSense. I'm sure that some editors had autocompletion even way back then, but in simpler editors you don't want to spend the day writing ListViewVirtualItemsSelectionRangeChangedEventHandler by hand.
A widely used convention in C and C++ is to give all-caps names to macros and not to variables or functions. Such a style makes it easy to tell at a glance which identifiers are macros and which are not. This style doesn't appear in K&R, so I don't know how it originated, but it is fairly common today.
In C, macros are used to define constants. In C++, on the other hand, constants are usually const variables. Declaring constants as macros is C style, but many people write C++ code in C style.
ALL of your examples are style conventions specific to WinAPI and not C++, also the WInAPI is a C API not a C++ Api.
Because somebody decided in about 1975 that identifiers declared in the preprocessor needed to be distinguished from identifiers declared in the C language proper.
I have never agreed, and I've ben using C since 1982.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I like to try out many different programming languages but I can never really use many of them in real projects because all important libraries that I need are written in C++.
Usually I have to write a C-Interface which can be pretty time consuming, so I am wondering does a programming language exist that can seamlessly call any C++ code?
Many functions in C++ are defined in header files, and expected to be compiled into every application using them. It occasionally happens for C too, but for C++ it is far more common, particularly as class members for templated classes cannot be made available in advance for every potential template instantiation: there are infinitely many.
If compatibility with C++ requires a complete C++ parser and compiler, you've not really got a different language, you've got C++ with extensions. Even if one of those extensions is to make parts of the code look nothing like C++, it adds massive complexity for little benefit.
If you don't need complete and seamless compatibility with C++, then limited compatibility is available in some languages. There is D's Interfacing to C++, describing what works, what doesn't, and why not.
There is an experimental language that can do so, but there's only one developer (myself) and it's in such an early stage of development that it's not useful right now.
Here's a simple sample program:
Main() {
cpp("iostream").std.cout << "Hello, World!";
}
FTR, compiling this sample requires ADL, OR, template instantiation, ABI compliance, parsing the C++ header in question, and lots of fun stuff.
No language can seamlessly interop with C++. C interfaces are a good idea. It's important not to export all / many functions from the module, because it's time consuming as you noticed. Focus on solving one problem at time and export the function solving this problem to C.
On the other hand, if you really need to expose many functions or even classes to other language, you can use SWIG. Read its documentation and you'll notice how many problems it needs to deal with while creating the wrapping code. That's because any two languages are different and you can't change that. The solution to this problem is to use the greatest common interface of two languages - C.
The only solution that meets your requirements is V8 / Javascript from Google.
Is the only implementation of a scripting language written in C++ that I know of, plus the API themselves are exposed via C++ too .
The downside is that is not a simple project, is not exactly available on any platform, it's being developed according to the Google needs and there are no guidelines or standards, for example C++ is being versioned by ISO documents that are released each time a new milestone is out and each one of them defines the standard, V8 is more like an ongoing project with some big voids, especially in terms of invariances , standardization and concurrency.
For example there is nothing that keeps Google from changing the entire set of APIs from one version to the other, and unless you are counting on a really big team, I doubt that you can keep up with that.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Let me start with explaining what I mean with "magic". I will use two examples from Java:
Every class inherits (directly or indirectly) the Object class.
Operator overloading is not supported by Java but the + operator is defined for String objects.
This means that it is impossible to make an implementation of the Object and String classes in pure(*) Java. Now this is what I mean with "magic": to make an implementation of these classes, you will need some special support from the compiler.
What I always liked about C++ is that, as far as I know, there is no such "magic" going on in the STL, i.e. it is possible to implement the STL in pure C++.
Now my question is: is this true? Or are there parts of the STL that cannot be implemented in pure C++ and need some "magic"/special compiler support?
(*) With "pure" I mean without using any class libraries.
in other words, has anything been done to the compiler to allow for a 'special case' the STL needed to work?
No.
It was all implemented as 'pure' C++ code, using the magic of templates.
There has been some work done to compilers to improve the STL (I'm thinking about various optimisations) but otherwise, no, you could write the entire STL if you really wanted. Some people did - STLPort is an implementation that didn't have the backing of any compiler manufacturer.
Like gbjbaanb correctly said, the STL can be implemented in plain C++, without relying on any kind of compiler "magic".
However, if you go digging in the STL source code for your compiler, you'll probably see code that either isn't standard, or which you're not supposed to write yourself.
The STL can be implemented entirely in standard C++, but that doesn't mean compiler writers aren't allowed to improve it occasionally, using compiler-specific extensions. For example, they might insert non-standard code that ensures better error messages, or perhaps works around some flaw in their compiler, or maybe enables special optimizations by using extra features of that specific compiler.
They also consistently use names that you're not allowed to use. For example, template parameters are typically named something like _Type, which, since it starts with an underscore followed by a capital letter, is reserved for the implementation. The standard library is allowed to use them, but you and I are not. So if you were going to write your own STL implementation, you would have to make some minor changes, but that's not because of any magic, just a way to avoid name clashes between the standard library and user code.
As others have said, the STL is implementable in pure standard C++98. What hasn't been said is that the development of the STL was concurrent with the development of the C++ template mechanism, and largely drove the inclusion of certain features. I believe that Argument Dependent Lookup (ADL, aka Koenig Lookup), template template parameters, and default template arguments all came to C++ to serve Stepanov's STL development.
So, with STL, they moved the magic into the language itself. Nice that the standards committee recognized that if those features were useful for what would become the standard library, they might be useful for the rest of us as well!
If by STL you mean only the template portion of the C++ Standard Library, then it is perfectly possible to implement it without any "magic". Whether each given implementation actually uses any "magic" is a different question (there are portions of STL where "magic" would help, but not absolutely required).
Now, if you are talking about the entire C++ Standard Library, then it does indeed have a bit of "magic" in it. The classic example would be the library-provided ::operator new and ::operator delete implementations. We often call them "overloadable" in everyday language, while formally they are replaceable. The C++ language does not offer such functionality to the user. The user cannot write a replaceable function.
Another example would be the offsetof macro (inherited from the C Standard Library). While it is usually implemented in "pure C", the popular implementation is actually illegal from the pedantic point of view (causes undefined behavior). I haven't seen any formally legal implementations of offsetof, so I'm not sure whether they are even possible.
Another example would be (again, inherited from C) the macros for working with variable arguments. They obviously cannot be implemented in pure C or C++.
I'm pretty sure some type_traits require compiler magic, for example has_trivial_constructor, has_virtual_destructor or is_pod.
std::initializer_list needs compiler support and cannot be reimplemented as another class (as far as I know), though I'm not sure if it counts since it's in c++0x.
C++0x is going to standardise some de facto "magic" type traits.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2984.htm
"Additional Type Traits for C++0x"
This contains a few remarks such as "XXXX is believed to require compiler support."
See also
http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Type-Traits.html#Type-Traits
http://msdn.microsoft.com/en-us/library/ms177194(v=vs.80).aspx
As "gbjbaanb" rightly said, there is no magic involved in the implementation of STL. It is written in pure C++. You could implement it yourself but has been made readily available as a library to make your life simpler.
STL is standard (Standard Template Library). The standard specifies the requirements for STL implementations. From the usage point of view, there is no "magic", no special dependencies you have to take care of. It can be used on any major C++ compilers, on all platforms supported by those compilers.
I already read the FAQ, and i think maybe this is a subjective question, but i need to ask.
Does anyine knows what exactly (i mean formally) is a C++ language extensions.
I already saw examples, like nvdia CUDA c ext, Avalon transaction-based c++ ext.
So the point is something like a formal definition or so.
thxs anyway.
A language extension is simply anything that goes beyond what the language specification calls for. Your compiler might add new features, like special "min" and "max" operators. Your compiler might define the behavior of division by zero, which is otherwise undefined, according to the standard. It might provide additional parameters for your main function. It might be the incorporation of another language's features, such as allowing C-style variable-sized arrays in C++. It might be a facility for specifying a function's calling convention.
Using a language extension usually makes your code non-portable because when you take your code to another OS, compiler, or even compiler version, the extension may not be available anymore, or its behavior may be different from what you had originally used.
Please see Extensible programming:
Extensible programming is a term used
in computer science to describe a
style of computer programming that
focuses on mechanisms to extend the
programming language, compiler and
runtime environment.
and more to the point, the Extensible syntax section:
This simply means that the source
language(s) to be compiled must not be
closed, fixed, or static. It must be
possible to add new keywords,
concepts, and structures to the source
language(s).