Why does C++ not have reflection?

Question

This is a somewhat bizarre question. My objectives are to understand the language design decision and to identify the possibilities of reflection in C++.

1. Why C++ language committee did not go towards implementing reflection in the language? Is reflection too difficult in a language that does not run on a virtual machine (like java)?

2. If one were to implement reflection for C++, what will be the challenges?

I guess the uses of reflection are well-known: editors can be more easily written, program code will be smaller, mocks can be generated for unit tests and so on. But it would be great if you could comment on uses of reflection too.

Answer 1

Reflection could be optional, like a preprocessor directive. Something like

#pragma enable reflection

That way we can have the best of both worlds, with out this pragma libraries would be created without reflection (without any overheads as discussed), then it would be up the individual developer whether they want speed or ease of use.

Answer 2

According to Alistair Cockburn, subtyping can't be guaranteed in a reflective environment.

Reflection is more relevant to latent typing systems. In C++, you know what type you've got and you know what you can do with it.

Answer 3

All languages should not try to incorporate every feature of every other language.

C++ is essentially a very, very sophisticated macro assembler. It is NOT (in a traditional sense) a high-level language like C#, Java, Objective-C, Smalltalk, etc.

It is good to have different tools for different jobs. If we only have hammers, all things are going to look like nails, etc. Having script languages is useful for some jobs, and reflective OO-languages (Java, Obj-C, C#) are useful for another class of jobs, and super-efficient bare-bones close-to-the-machine languages are useful for yet another class of jobs (C++, C, Assembler).

C++ does an amazing job of extending Assembler technology to incredible levels of complexity management, and abstractions to make programming larger, more complex tasks vastly more possible for human beings. But it is not necessarily a language that is the best suited for those who are approaching their problem from a strictly high-level perspective (Lisp, Smalltalk, Java, C#). If you need a language with those features to best implement a solution to your problems, then thank those who've created such languages for all of us to use!

But C++ is for those who, for whatever reason(s), need to have a strong correlation between their code and the underlying machine's operation. Whether its efficiency, or programming device drivers, or interaction with the lower-level OS services, or whatever, C++ is better suited to those tasks.

C#, Java, Objective-C all require a much larger, richer runtime system to support their execution. That runtime has to be delivered to the system in question - preinstalled to support the operation of your software. And that layer has to be maintained for various target systems, customized by SOME OTHER LANGUAGE to make it work on that platform. And that middle layer - that adaptive layer between the host OS and the your code - the runtime, is almost always written in a language like C or C++ where efficiency is #1, where understanding predictably the exact interaction between software and hardware can be well understood, and manipulated to maximum gain.

I love Smalltalk, Objective-C, and having a rich runtime system with reflection, meta-data, garbage collection, etc. Amazing code can be written to take advantage of these facilities! But that's simply a higher layer on the stack, a layer that must rest on lower layers, that themselves must ultimately sit upon the OS and the hardware. And we will always need a language that is best suited for building that layer: C++/C/Assembler.

Addendum: C++11/14 are continuing to expand C++ ability to support higher-level abstractions and systems. Threading, synchronization, precise memory models, more precise abstract machine definitions are enabling C++ developers to achieve many of the high-level abstractions that some of these high-level only languages used to have exclusive domain over, while continuing to provide close-to-metal performance and excellent predictability (i.e minimal runtime subsystems). Perhaps reflection facilities will be selectively enabled in a future revision of C++, for those who want it - or perhaps a library will provide such runtime services (maybe there is one now, or the beginnings of one in boost?).

Answer 4

Reflection can be and has been implemented in c++ before.

It is not a native c++ feature because it have an heavy cost (memory and speed) that should'nt be set by default by the language - the language is "maximum performance by default" oriented.

As you shouldn't pay for what you don't need, and as yous say yourself it's needed more in editors than in other applications, then it should be implemented only where you need it, and not "forced" to all the code (you don't need reflection on all the data you'll work with in a editor or other similar application).

Answer 5

The reason C++ doesn't have reflection is that this would require the compilers to add symbol information to the object files, like what members a class type has, information about the members, about the functions and everything. This essentially would render include files useless, as information shipped by declarations would then be read from those object files (modules then). In C++, a type definition can occur multiple times in a program by including the respective headers (provided that all those definitions are the same), so it would have to be decided where to put the information about that type, just as to name one complication here. The aggressive optimization done by a C++ compiler, which can optimize out dozens of class template instantiations, is another strong point. It's possible, but as C++ is compatible to C, this would become an awkward combination.

Answer 6

If you really want to understand the design decisions surrounding C++, find a copy of the The Annotated C++ Reference Manual by Ellis and Stroustrup. It's NOT up to date with the latest standard, but it goes through the original standard and explains how things work and often, how they got that way.