Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Using what kind of template technical, could be called "meta programming"?
Is there a good definition of what's and what's NOT meta programming?
Does our C++11 STL contain a lot of meta programming?
Is "type_traits" meta programming"?
Thanks a lot.
Q1. Using what kind of template technical, could be called "meta programming"?
Template metaprogramming refers to use of templates and the compiler to perform some of the key elements of programming: Looping, if-else branching, C/C++ switch like branching, recursion, etc.
The first such meta program was used to generate the first few prime numbers as compiler error messages. See http://www.erwin-unruh.de/primorig.html
Q2. Is there a good definition of what's and what's NOT meta programming?
A good definition can be found at Wikipedia.
Template metaprogramming (TMP) is a metaprogramming technique in which templates are used by a compiler to generate temporary source code, which is merged by the compiler with the rest of the source code and then compiled. The output of these templates include compile-time constants, data structures, and complete functions. The use of templates can be thought of as compile-time execution. The technique is used by a number of languages, the best-known being C++, but also Curl, D, and XL.
Q3. Does our C++11 STL contain a lot of meta programming?
Most likely but that's a guess. I haven't delved into any implementation of the standard library.
Q4. Is "type_traits" meta programming"?
Once again, I haven't delved into it but I imagine most of the functionality of "type_traits" is implemented using metaprogramming techniques.
"Metaprogramming" is used in informal speech to refer to a variety of programming techniques:
Information about types, i.e "type traits". This is the most straight forward type of meta, in that "meta" here means "about something"
(Ab)using the C preprocessor or templates. You are not really programming "in" C++ but rather a sublanguage. The IOCCC has plenty of examples of people using the C preprocessor to do various complete programs, like Towers of Hanoi and calculating prime numbers. The "classic" example of a template metaprogram is calculating fibonacci. In other words you are going "outside" the normal scope of C++ to create programs, which makes this usage similar to metagaming
Quines, creating programs that make programs that make programs, self-hosting compilers, etc. Here "meta" means "self-referential", like a fractal
Whether the standard library contains "metaprogramming" is implementation-defined. Some implementations go crazy with it, others don't.
There isn't really a good definition either, the word "meta" is ironically kind of fuzzy.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In http://www.stepanovpapers.com/notes.pdf, Alexander Stepanov mentions:
It is interesting to note that the only examples of inheritance that
remained in STL inherit from empty classes. Originally, there were
many uses of inheritance inside the containers and even iterators, but
they had to be removed because of the problems they caused.
What are the technical problems that precluded the use of inheritance in the STL?
I think I will put some comments directly from Alexander Stepanov (http://www.stlport.org/resources/StepanovUSA.html).
Question:
STL is full of creative uses of templates, such as symbolic
types exported from classes, or the pattern matching of a set of
overloaded algorithms onto iterator tags. Surely enough, no standard
C++ Programming book speaks about those idioms. How did you come to
these C++ code idioms?
Answer:
I knew exactly what I was trying to accomplish. So I tweaked
the language until I was able to get by. But it took me many years to
discover all the techniques. And I had many false starts. For example,
I spent years trying to find some use for inheritance and virtuals,
before I understood why that mechanism was fundamentally flawed and
should not be used. I am very happy that nobody could see all the
intermediate steps - most of them were very silly. It takes me years
to come up with anything half decent. It also helped that Bjarne was
willing to put certain features in the language just to enable some of
my idioms. He once refered to it as "just in time language design."
Next, I will allow myself to direct you to this great answer:
https://stackoverflow.com/a/1039904/210971
OOP is not the holy grail. It's a cute idea, and it was quite an
improvement over procedural languages back in the 70's when it was
invented. But it's honestly not all it's cracked up to be. In many
cases it is clumsy and verbose and it doesn't really promote reusable
code or modularity.
That is why the C++ community is today far more interested in generic
programming, and why everyone are finally starting to realize that
functional programming is quite clever as well. OOP on its own just
isn't a pretty sight.
And now something from me:
OOP rules dictates the way (inheritance, polymorphism, etc.) a programmer thinks about interaction between things (objects, entities, tribbles, etc.).
This is clearly visible in this simple Java example from time before adding support for generics (but these are not as verbose as in C++).
List v = new ArrayList();
v.add("test");
Integer i = (Integer)v.get(0); // Run time error
Although the code is compiled without error, it throws a runtime exception (java.lang.ClassCastException) when executing the third line of code. This type of problem can be avoided by using generics and is the primary motivation for using generics.
List<String> v = new ArrayList<>();
v.add("test");
Integer i = v.get(0); // (type error) compilation-time error
Alexander Stepanov recognized that generic approach can solve this issue, help in providing logical separation (abstraction) between data structures and algorithms. This is why there is so much emphasis on iterators, functors, and many other idioms that fit very well into generic world.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am reading Abrahams,Gurtovoy book about C++ metaprogramming. I must admit that I do not understand properly there explanation for using template metaprogramming. For example:
You want the code to be expressed in terms of the abstractions of the problem domain.
Or:
You would otherwise have to write a great deal of boilerplate implementation code.
Could someone elaborate on this?
I too use C++ for scientific computing and, yes, template meta-programming comes in very helpful. One use is to help with implementations of general purpose numerical methods. A typical example is std::sort, which is an abstraction of sorting in such a way that it works for whatever you want to sort.
Similarly, you may write, say, a templated spline interpolation that can interpolate y(x) for any type x that implements the concept of a scalar (orderable, operators + - *) and type y that is interpolateable (allows y+y, y-y, y*x). Once you have established such a template, you can use it to interpolate, say, some matrix type over a double (representing time, for instance) without any further adaptations: it just works immediately (the compiler must do some work, though).
You want the code to be expressed in terms of the abstractions of the problem domain.
Template Metaprogramming (TMP) can be used to separate and abstract different tasks in your code. For example, Boost.Serialization is implemented so as to be completely agnostic of your (the user's) code. You just have to provide a bit of glue, in the form of a serialize() member function, and Boost.Serialize will be able to work with your class seamlessly. And since this is all at compile-time, this flexibility does not come at any runtime cost (as opposed to polymorphism).
You would otherwise have to write a great deal of boilerplate implementation code.
TMP techniques can be used to generate code, and to efficiently factorize common code. For example, Boost.Intrusive lets you "import" behaviour in your classes (by various means, such as inheritance or type traits), and that is nothing else than generating code and injecting it into your class to transform it into, for example, a list node.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am curious to know the differences between a Wrapper and a Library.
From what I have been able to find online I can't really see any major difference between the two. I often came across "Wrapper Library" or "Library Wrapper" and it makes it seem as if they are basically one in the same.
However, my assumption is that a Library is a collection of finely tuned functions that provide a means to accomplish a task that isn't part of the core functionality in the language.
And a Wrapper is a facade that makes it easier and quicker to set up certain functionality within your program so that you have less typing to do.
These two descriptions just make it seem like it's the same thing with different wording to me though.. so I come to you Stackoverflow,
What are your opinions and professional points of view on Wrappers/Libraries?
Sidenote/Background:
This question stems from my C++ Design Patterns Class I finished a month ago:
In my C++ Software Design Patterns class we had to create a Socket Library that took the WinSock Library and created a Thin(Or Thick, our choice) Wrapper over it. We then had to create two applications that used our library so that we didn't have to repeat the basic set up and tedious coding of the WinSock Library. I ended up with 100% on the project but wish to know more about the actual differences or similarities because I want to expand on this project in my personal time.
In general, I personally think of it like this:
A library is typically an actual concrete implementation of some functionality.
A wrapper is mostly just a layer of abstraction around existing functionality. It is only intended to offer a better, cleaner interface (or at least one feels more native to the language or technology it targets) to something that already exists.
Now obviously there are times when the distinction between the two is crystal clear and times when the line is blurred, so some subjectivity may be inevitable in the latter scenarios. In other words, what you consider an implementation and what you consider simply an abstraction can be ambiguous occasionally.
For instance, a wrapper can have argument checking functionality or better state bookkeeping that the underlying system did not have. If this is mostly to serve the correctness of the abstraction, then it this still leans on the side of the wrapper. If some genuinely new functionality is added, it starts becoming a library and could be called a wrapper-library.
On the other hand, a full-fledged library may not be a wrapper at all, in the sense that it may leverage an underlying system to offer some functionality, but without exposing any considerable part of that underlying system in any clean interface (other than the specific functionality it adds). This would be called a library, but most probably it wouldn't be called a wrapper.
(I should clarify that what I said is how I think of the matter in general, not specifically in regard to C++. If the C++ world has less ambiguous definitions of these terms, please do correct me.)
Library is an generic implementation of any sort of functionality. Wrapper is a specific implementation intended to provide abstraction to existing library.
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 3 years ago.
Improve this question
I've been talking with friends and some completely agree that templates in C++ should be used, others disagree entirely.
Some of the good things are:
They are more safe to use (type safety).
They are a good way of doing generalizations for APIs.
What other good things can you tell me about C++ templates?
What bad things can you tell me about C++ templates?
Edit: One of the reasons I'm asking this is that I am studying for an exam and at the moment I am covering the topic of C++ templates. So I am trying to understand a bit more on them.
Templates are a very powerful mechanism which can simplify many things. However to use them properly requires much time and experience - in order to decide when their usage is appropriate.
For me the most important advantages are:
reducing the repetition of code (generic containers, algorithms)
reducing the repetition of code advanced (MPL and Fusion)
static polymorphism (=performance) and other compile time calculations
policy based design (flexibility, reusability, easier changes, etc)
increasing safety at no cost (i.e. dimension analysis via Boost Units, static assertions, concept checks)
functional programming (Phoenix), lazy evaluation, expression templates (we can create Domain-specific embedded languages in C++, we have great Proto library, we have Blitz++)
other less spectacular tools and tricks used in everyday life:
STL and the algorithms (what's the difference between for and for_each)
bind, lambda (or Phoenix) ( write clearer code, simplify things)
Boost Function (makes writing callbacks easier)
tuples (how to genericly hash a tuple? Use Fusion for example...)
TBB (parallel_for and other STL like algorithms and containers)
Can you imagine C++ without templates? Yes I can, in the early times you couldn't use them because of compiler limitations.
Would you write in C++ without templates? No, as I would lose many of the advantages mentioned above.
Downsides:
Compilation time (for example throw in Sprit, Phoenix, MPL and some Fusion and you can go for a coffee)
People who can use and understand templates are not that common (and these people are useful)
People who think that they can use and understand templates are quite common (and these people are dangerous, as they can make a hell out of your code. However most of them after some education/mentoring will join the group mentioned in the previous point)
template export support (lack of)
error messages could be less cryptic (after some learning you can find what you need, but still...)
I highly recommend the following books:
C++ Templates: The Complete Guide by David Vandevoorde and Nicolai Josuttis (thorough introduction to the subject of templates)
Modern C++ Design. Generic Programming and Design Patterns Applied by Andrei Alexandrescu (what is the less known way of using templates to simplify your code, make development easier and result in code robust to changes)
C++ Template Metaprogramming by David Abrahms and Aleksey Gutov (again - different way of using the templates)
More C++ Idioms from Wikibooks presents some nice ideas.
On the positive side, C++ templates:
Allow for generalization of type
Decrease the amount of redundant code you need to type
Help to build type-safe code
Are evaluated at compile-time
Can increase performance (as an alternative to polymorphism)
Help to build very powerful libraries
On the negative side:
Can get complicated quickly if one isn't careful
Most compilers give cryptic error messages
It can be difficult to use/debug highly templated code
Have at least one syntactic quirk ( the >> operator can interfere with templates)
Help make C++ very difficult to parse
All in all, careful consideration should be used as to when to use templates.
My 2c are rather negative.
C++ types were never designed to perform compile time calculations.
The notion of using types to achieve computational goals is very
clearly a hack – and moreover, one that was never sought but rather
stumbled upon
..
The reward for using MP in your code is the moment of satisfaction of
having solved a hard riddle. You did stuff in 100 lines that would
have otherwise taken 200. You grinded your way through
incomprehensible error messages to get to a point where if you needed
to extend the code to a new case, you would know the exact 3-line
template function to overload. Your maintainers, of course, would have
to invest infinitely more to achieve the same.
Good points: powerful; allows you to:
prescribe compile-time attributes and computation
describe generic algorithms and datastructures
do many other things that would otherwise be repetitive, boring, and mistake-prone
does them in-language, without macros (which can be far more hazardous and obscure!)
Bad points: powerful; allows you to:
provoke compile-time errors that are verbose, misleading, and obscure (though not as obscure and misleading as macros...)
create obscure and hazardous misdesigns (though not as readily as macros...)
cause code bloat if you're not careful (just like macros!)
Templates vastly increase the viable design space, which is not necessarily a bad thing, but it does make them that much harder to use well. Template code needs maintainters who understand not just the language features, but the design consequences of the language features; practically speaking, this means many developer groups avoid all but the simplest and most institutionalized applications of C++ templates.
In general, templates make the language much more complicated (and difficult to implement correctly!). Templates were not intentionally designed to be Turing-complete, but they are anyway -- thus, even though they can do just about anything, using them may turn out to be more trouble than it's worth.
Templates should be used sparingly.
"Awful to debug" and "hard to read" aren't great arguments against good template uses with good abstractions.
Better negative arguments would go towards the fact that the STL has a lot of "gotchas", and using templates for purposes the STL already covers is reinventing the wheel. Templates also increase link time, which can be a concern for some projects, and have a lot of idiosyncrasies in their syntax that can be arcane to people.
But the positives with generic code reuse, type traits, reflection, smart pointers, and even metaprograms often outweigh the negatives. The thing you have to be sure of is that templates are always used carefully and sparingly. They're not the best solution in every case, and often not even the second or third best solution.
You need people with enough experience writing them that they can avoid all the pitfalls and have a good radar for when the templates will complicate things more than helping.
One of the disadvantages I haven't seen mentioned yet is the subtle semantic differences between regular classes and instantiations of class templates. I can think of:
typedefed typenames in ancestor types aren't inherited by template classes.
The need to sprinkle typename and template keywords in appropriate places.
Member function templates cannot be virtual.
These things can usually be overcome, but they're a pain.
Some people hate templates (I do) because:
On maintainability pov, the wrong use of templates can have a negative effect ten times stronger than the initial advantage of time they were supposed to bring.
On optimization pov, compiler optimizations they allow are nothing compared to an optimal algorithm and the use of multi threading.
On compiling time pov, wrong use of templates can a very negative effect on parsing, compilation and linking phases, when poorly written templated declaration brings tons of useless parasite declarations in each compilation units (here is how 200 lines of code can produce an .obj of 1Mb).
To me templates are like a chainsaw with an integrated flame thrower that can also launch grenades. One time in my life I may have a specific need of that. But most of the time, I'm using a regular hammer and a simple saw to build things and I'm doing a pretty good job that way.
Advantage: Generic Datatypes can be created.
Disadvantage: Code Bloating
I don't see how they are hard to read. What is unreadable about
vector <string> names;
for example? What would you replace it with?
Reusable code is made with template. Its application is in accordance with the profile of each.
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 9 years ago.
Improve this question
I'm designing a high level, object oriented, garbage collected programming language, and I'm having a problem with how to do templates. I plan on creating a VM-type system, similar to .NET or JVM (but it will use LLVM under the hood). The problem is that I want to have powerful, C++-like templates, but with dynamic linking (so I could replace the template library without recompiling everything that uses it). I want to be able to compile a source file without having the definition of the templates. Code generation at JIT-time should be minimized.
Here are the options I'm thinking of:
Have the concept of a template library which is statically linked into each compilation unit. A template library would essentially be like an AST with blanks to be filled in when the template is instantiated. The problem with this is that if two files are compiled with different versions of the template library, they may be incompatible, or if the template library is buggy, everything will have to be recompiled. This is how C++ does it.
Have template libraries that are linked at JIT-time. This solves most of the problems but requires the IR to essentially be an AST. I would like the IR to be much lower level. This requires much more work for JIT-ing.
Have wimpy C#-like generics with only types as arguments. This is quite limiting, but allows simple code generation and dynamic linking.
Are there any other good ways I'm not thinking of? I'm leaning towards the first option, but I don't really like any of the options. What do you think is the best option?
I guess it depends on the amount of specialization you want, i.e. how powerful the compiler of templates has to be.
If you look at c++, the compiler can do all sorts of fancy stuff (like generate subclasses via recursion, probably compute a fractal inheritance graph as well as computing the numbers of Pi on the fly).
If you want that power, you probably need a powerful high-level JIT. FWIW, I think that would be cool. (Just include the full compiler in the runtime.)
Depends a bit on the rest of the language... if you have operator overloading, value types etc, then you are really complicating matters (and possibly missing out on great optimisation opportunities) by not going the C++ route: the code using the template would also have to be represented as an AST up to JIT time to allow maximum specialization.
Since C++ templates are essentially a form of macros, they allow much of all the bloat produced by duplication to be reduced before you get generate code.
Template types (at least in C++) tend to be the most core types that underly all other code, as such, if they change, assuming other code will still be compatible with it is not going to be true for all but the smallest changes.
What you're trying to achieve is nearly impossible. You have to leave pretty much all of the high level representation of your language for both the templates definitions and the code using those templates, and perform your JIT compilation from almost the level of slightly processed source code. If you're ok with that - you'd have to keep the rest of your compiler really trivial, and you won't be able to use any of the heavyweight LLVM optimisations. There are no other ways around, template metaprogramming relies on the availability of the high level information.
Think about how powerful are these templates going to be. You must remember that having a language that is compiled Just In Time, means that a lot of the heavy lifting will have to be done at load time and at run time. So, the more powerful you make your templates the less performance you will get from them.
If you are really going to that path, you may also include the compiler in the run time as Macke suggested. In fact there are plenty of languages that do this.
By doing this you are making your implementation of the language an "interpreted" or partially "interpreted" one. In those terms a template is just a fancy dress for match-replace-eval, and there is anything wrong with that, templates often work like that in dynamic languages. Just remember that at the end it will be Power vs Performance.
Note: when facing this kind of decisions it may be worth to step back a little. Identify the use cases and prioritize them, separate how to implement from the design so you can iterate the design without having the implementation be a cause of paralysis, yet still having it into consideration.
Each iteration you extend the design to cover more use cases while deciding what will be the best design. When you reach a design you like you can iterate then you can iterate on the implementation too. This methodology allows you to cover the more important cases first.
Yes, I'm suggesting an iterative incremental methodology. And I do this because this question is about the design of a language yet it seems much concerned about the implementation. It is necessary to keep the ideas grounded or you will end up in one of the extremes (too much powerful with pity performance or no templates at all for a high performance solution).