They still haven't implemented extern.

[K.I.L.E.R]

My solutions to templates:
I used to have a single file and I defined all my template declarations in there and just included it within my appropriate headers.

Currently I do this:

#ifndef VIRTUALKEYBOARD_CPP
#define VIRTUALKEYBOARD_CPP

#include "VirtualKeyboard.hpp"

//Definitions go here

#endif

Here is how I use it:

#include "VirtualKeyboard.hpp"
#include "VirtualKeyboard.cpp"

I do this ONLY for template classes.

What do you guys think of this approach vs my previous one?
I kicked my previous approach ages ago, I'm very surprised that every time I come back to doing my work in C++ that "extern" has yet to be implemented.
Why?

 

[DemoCoder]

Don't you mean "export". "export" is the separation compilation model for templates, not extern.

 

[K.I.L.E.R]

Sorry, I'm an idiot.

 

[Frank]

K.I.L.E.R, the header files are there for a reason. Compare them to class declarations. They use properties and encapsulation for a good reason. Try to only export the stuff you need to be visible.

For polymorphism and inheritance, you should make the stuff that might be replaced virtual and protected instead of static and private. And make a nice hierarchy of it. And only use operator overloading if you have a very unambigious definition of what it should do.

You will be very happy you do it like that the moment you have to work in a team. Or have to change something you wrote six months or more ago.


Edit: if you have to include more because it doesn't work otherwise, you should rewrite your library.

 

[DemoCoder]

You're not understanding him DiGuru. He wants to separate declaration from definition, just like in C, where you declare function prototypes in .h and put the code in .c. With variables, you of course declare them "extern". Code which uses those functions then only needs the .h file. (functions are auto-extern in C) The implementation will be resolved by the linker.

Separate compilation of templates in the C++ standard can only be done with the "export" keyword, but most compilers don't implement it. The idea is that the compiler doesn't need to see the definition (code) of a template until the linker stage. Still far less useful than say Java/C#, because the linker still needs access to the template definition source code anyway.

 

[Frank]

Ok. Let me rephrase that post:

Isn't it much more convenient and understandable to use classes and method overloading instead of templates? Because that's basically what you do. And you can use any method of any of the newer classes by declaring it as the base class and casting it to the required one.

But I have to admit, I never use templates myself. So I might be totally wrong.

 

[Colourless]

Lookup template "explicit instantiation".

It can be a pain in the ass but all compilers should support it using the standard methods. If you dont want to have to do a #include for the code then you'll have to do it using explicit instantiation.

Of course according to microsofts documentation, the 'extern' keyword when used with templates will prevent the automatic instantiation meaning if you use extern on templates you must use explicit instantiation.

 

[Frank]

Yes, but that's because you don't have explicit abstract definitions in C++. So the compiler generates the whole class again, and switches the old definitions for the new declarations.

Inheriting a new class still seems simpler to me. Sure, you have to cast your pointer, but I want that anyway.

Or do I miss something?

 

[K.I.L.E.R]

I've actually thought about doing what you've suggested DiGuru but it would create more work. If you have a look at my code I'm using templates + ABC with many polymorphic entities.

Templates seem like an anomaly in the way they are handled compared to everything else.
I don't go out of my way to use templates but there are places where they just fit and I cannot help but use them.

 

[DemoCoder]

OO cannot replace true parametric polymorphism. Moreover, C++ templates are not really parametric polymorphism, but compile time metaprogramming. OO happens at runtime (late binding), template resolution expansion in C++ happens at compile time.

Java was saddled for years with attempting to work around lack of parametric polymorphism, the result was less type-safe code and a huge reduction of productivity due to needless replication or class interfaces (with type parameters restricted to subtypes that you would instantiate a collection)

Nothing is as fruitless and wasteful of a developers time then having to subclass Vector (of Object), overload the add() method to say, have an add(Animal), and overload add(Object) with runtime type checks.. Or, as many people would do, create a new AnimalVector, enscapulate a Vector inside it (to hide the generic Object methods) and reimplement all of the normal Vector methods via delegation.

The way parametric polymorphism with type-inferencing works in ML/Haskell/Clean et al blows the OO approaches out of the water. You end up with far more expressive power and less clutter.

If I want to write a reverse function, I say

reverse [] = []
reverse x:xs = reverse(xs) ++ [x]

And I'm done, I'll reverse a list of anything. Without Generics, you'll end up with a half dozen overloaded reverse() functions. With Generics/function templates, you end up with

List<T> reverse(List<T> t)
{
   if(t.isEmpty()) return new ArrayList<T>();
   return reverse(rest(t)).add(head(t));
}

Much uglier. With ML type systems, you rarely have to deal with type arguments except when pattern matching most of the time.

 

[Frank]

What I would like for such constructs, would be a method/language element that lets me loop through all available properties/methods and each of the overloads they have. Like you can with controls. A way to expose the class semantics as collections.

 

[DemoCoder]

You can practically do that with every language except C/C++. Java has had reflection built in for ages. Smalltalk, Self, Javascript, SBCL, C#, Python, Ruby, etc, pretty much all of them allow runtime introspection without COM-style vtable hacks to emulate it.

In fact, in many languages not only can you introspect classes/objects at runtime, but you can dynamically modify the properties, the inheritance hierarchy, alter methods, etc all at runtime.

In terms of language power, C/C++ style languages are terribly unexpressive.