I think that it's pretty pointless. If you want a language that is more like Java then use Java. If anything, this kind of deception would ultimately hurt n00bs. You're basically trying to teach them a different language, in which case you might as well just teach them Java and then later teach them C++. I think you get a much better understanding of the overall process with C++ though so I would encourage you to just teach C++ as C++ was intended.

What you've done seems somewhat impressive, but it also seems rather complicated and probably is a nightmare to maintain.

Also, at the very least, I would implement:

std::ostream & operator<<(std::ostream & out, const Object & o)
{
    out << o.toString();
}

There's little point explicitly calling the toString method when you can let the language do it for you.

Isn't that a bit like turning wine into water

Indeed...an easy to use c++ API? who would have thought of that? it's crazy!!! it's heresy!!! :-).

Not that I don't agree with you.

C++ is at its best when used as intended - that is, program in a RAII idiom instead of tacking GC onto it, and play the template functionality to its full potential.

C++ is pretty good at what it's good at. It's just that before all those nice interpreted and hybrid languages like Python, C#, Java, etc. came along and became viable alternatives, C++ was used for pretty much everything, including jobs for which it is not the right tool.
Most software projects benefit from sacrificing a bit of runtime performance to gain a truckload of developer performance and pretty much get rid of memory allocation bugs altogether.

Whether this is a good thing remains questionable. There is a good reason newer languages don't do this anymore: Every single text editor on the planet that is remotely useful for day-to-day programming is capable of folding curly-bracket syntax, which means you can get the same compact view with a single-source-file model as with the traditional C/C++ header/source model, and hence, the "compact quick reference" argument is basically moot. It's the only non-technical argument for the two-file model though, so these days, the everything-in-one-file model is, from a human's point of view, the thing that makes sense.

But templates are the most useful feature in all of C++. C++ lacks a few features such as reflection, runtime code generation, and lambda expressions; templates almost fill that gap - not always, but close enough for most things.

Yeah, it would be extremely useful.

But it's so useful...code becomes much clearer. You know, one of the problems with c++ is that it's one of the hardest languages to read. Going back to your code, after a while, and it is a strange land.

It's certainly more work for the SDK programmer. Not so much more work for the end-user of the SDK. It even allows you to seal a class by not providing the implementation part in a public header.

Data was 'fully functional', and look what he did to Lt Yar!!!

Joking aside, I've come to dislike templates. After so many years about bragging about them, I now find them gross. They are necessary, because without them smart pointers wouldn't be possible, and they are also necessary for performance reasons, but it's an absolute overkill during development, especially if you use the most advanced stuff like boost.

I've tried to use boost::bidirectional_map, but the compile times are so long that I did my own version of the bidirectional_map.

I've tried to use boost::spirit, but the the compile times again are so long that I had to make my own parsing library and DSL that didn't have any templates.

I think templates are great stuff, but only when the computing resources are so limited that performance would suffer if templates are not used.

I think that a Java-like SDK is a good idea: it's like having another language together with c++, sharing the same IDE and compiler. You don't have to use the hardcore stuff, until performance suffers. When it does, then going low level would be extremely easy, since it's the same language that allows it to go low level.

This fits exactly with my idea. Having a good and simple SDK, even if it's a little slower than what it can be, will boost developer performance, which is a great benefit.

I don't think that implementation detail hiding had ever to do with compact quick reference. I think it was more related to the fragile base class idiom: change a little detail in the base class and see all the subclasses be recompiled.

In the way I have done the implementation hiding, changing the implementation class of a class would affect only the host class and the inheriting classes. The rest of the code would not need to be re-compiled.

For example, in the code I posted, if I need to change the STRING struct, only the code in file String.cpp would need a recompile (and the Object.cpp file, but that is not necessary if the Object class uses the String class instead of the STRING struct). Imagine how much code would need to be recompiled if there is a change the internals of std::basic_string (or any other class that is heavily used)!

If you are a solo developer, that is. If the code is to be edited for many years, from many people, the sensible thing to do is have one file per class.

He wasn't referring to projects split into multiple code files, but to separate declaration and definition files for the same code.

I happen to use reflection and lambda expressions all the time; in languages that make it painless, I also generate code all the time. These features need to be handled with care, but sometimes, they are the most elegant and straightforward solution to a given problem.

A few examples:
- A base class for JSON web services (to be used for AJAX calls). The class uses reflection to create a description of itself, and to map query string parameters to methods and arguments. Without reflection, this would have been seriously painful.
- That same base class also generates a javascript client for itself, which makes heavy use of lambdas to implement callbacks. Possible without lambdas, but ugly. It also happens to be runtime code generation, though on a different level than what I was talking about.
- Doing relational database-like operations (filter, sort, join) on collections of objects, in memory. Or really, functional programming in general. Basically crippled without lambdas.

There are tons of 'features' that are really just marketing buzzwords, but these are not.

Exactly.

The point is, you don't have to fold. You can, if you choose to. With header/source, you don't get that choice, at least not at such a fine-grained level.

I actually find myself thinking of reflection-based solutions too often. Meta-programming like that can save you a LOT of coding, but often enough the run-time cost is often too much. That's not to say that it never comes in handy. I've accomplished some pretty nice things with reflection that just aren't possible without it (mostly, I look to reflection to put trust in computers instead of people).

Lambdas really are very nice. C# is also a very nice language. I would certainly say that I prefer C# to Java, but Java is much more free and in practice much more platform independent so it gets a lot more points for that. Also, I really like Java's anonymous classes. C# has anonymous types, but they have their limitations.

Based on the OPs description it actually sounds a bit like Qt. It has a form of GC, a base QObject class, COW data types, private implementation classes and Java iterator variants for its data types.

My Canva5 project's Font class is structured like a simple data type, as in you can pass it by value or reference, and not worry about copies, it hides the actual font data in a private implementation class that is shared via shared_ptr.

Maybe this sounds nice... but I wouldn't use anything made by you, axilmar... you are too prone to saying "screw it" and deleting/removing support to these "C++ improvement" projects of yours. What happened to that garbage collection library of yours (several of them, in fact)? Or that new language?

I wanted to look at it a year or so after you made that thread, only to find it gone... I'm just making a suggestion of putting all these (possibly very useful) projects in some publicly available place.

GitHub them. It doesn't matter if nobody uses them. The space is free (up to 300 MB of open source data). If somebody gets use of them then great. And if not, at least you tried.