C++, I love you.

[Veltas]

Well people use Object type parameters to achieve these things anyway, when they really shouldn't. It's poor protection, but it also requires the most ugly type-casting.

I suppose you're right, now I think about it my issue with the generics system was that it was limiting me rather than just being difficult to use.

EDIT: I really do like using C++ templates, my issue would be with the large amount of extra syntax required at the front of the method definitions when they're written out of the class definition.

[rapidcoder]

C with classes died in the 80s

So why Qt still uses it and is pretty popular among C++ frameworks?

C++'s template system seems to do the job it was designed for very well. It's implementation is very obvious to most programmers using it because it is all compile-time dynamics.

Obvious? I recall a C++ assignment I took somewhere in the previous decade, it was just a 30 lines of code of some template. The task was to write down what that code prints. Everyone got a different result. Ok, that was expected, we were not experienced coders that time. We fired up an editor, input the program into it, compiled it with different compilers, ran it and... we got different results. We analyzed it very carefully, and there were *no* undefined behaviour in that code, just compilers got that slightly wrong. Nowadays compilers are better, but it took them about a decade to get there. And you call it obvious for programmers, if compiler-writers (which are by definition better-than-average) couldn't get them right for a decade?

ava's generics system is probably more powerful, probably slower, and I know for sure it's harder to use

Agreed it might be sometimes slightly slower (although 99% typecasts are elided, and the rest take one CPU cycle each) and sometimes faster (less code cache bloat), but harder to use? Java can give you at least readable error messages, not a 3 page-long essay on internal boost / STL structure. Also IDEs and debuggers understand Java generics without any problems, while in C++ it is still not a standard (it is fine with simple cases like basic string or vector, but not when you start using more advanced boost features).

[Veltas]

That is why you really never know what to expect from someone who titles himself a C++ coder (even if you know he is a smartass)

Cubbi wrote:

All it takes is a simple interview.

I beg to differ, interviews are very difficult to orchestrate! I mean, you can easily separate people who know very little about C++ from those who have a reasonable understanding of the language, but that's it.

Asking obscure questions about the finer points of the language or asking about design patterns doesn't help too much because a lot of very skilled programmers simply don't involve themselves with certain design patterns or by chance have never needed that obscure feature.

Interviews are an art, if anything.

[Veltas]

rapidcoder wrote:

We fired up an editor, input the program into it, compiled it with different compilers, ran it and... we got different results. We analyzed it very carefully, and there were *no* undefined behaviour in that code, just compilers got that slightly wrong. Nowadays compilers are better, but it took them about a decade to get there. And you call it obvious for programmers, if compiler-writers (which are by definition better-than-average) couldn't get them right for a decade?

I find this hard to believe. Was it an incredibly complicated template issue or was it basic? Because the vast majority of template code is very simple, and this sounds like identifying a very specific issue with certain compilers.

EDIT: I understand that it will likely be impossible, but maybe we could have the code? Or at least something similar! I understand it will probably work the same in all compilers now, but I would find it very interesting to see the confusion, nevertheless.

[rapidcoder]

That was 10 years ago, and I don't have the code anymore. In those times gcc choked on even basic template specializations. Probably it would pass just fine now. The confusion came mostly to how compilers called constructors/destructors, variable initialization, their order, which type specializations got selected etc. It was probably not only related to templates.

[Veltas]

Yes, it sounds like an issue with relation to templates but not caused by templates. I wouldn't say that C++ is an obvious language, there are a lot of implementation quirks that are exactly the opposite. But as far as templates go, surely they are just treated as separate classes according to the specialisation?

[Cubbi]

All it takes is a simple interview.

I beg to differ, interviews are very difficult to orchestrate!

Sure, an interview sufficient for a hiring decision is difficult. But coding style becomes apparent at the first "write me some code", especially when questioned on the design choices taken.

[LB]

rapidcoder wrote:

Unsafe? Only if you deliberately break the rules and ignore compiler warnings

The reason erasure exists is so that List<String> is compatible with just List in older libraries. If you're stuck having to use an older library for something then you just have to hope that they didn't accidentally do something that would have been caught with a warning using generics. Personally I don't want an Integer in my List<String> because I never check for that :)

[rapidcoder]

@LB yeah, but this is only dealing with legacy code, and it is still runtime-safe (you get a well defined exceptions instead of undefined behaviour).

[LB]

I guess with hard-coded projects it isn't a problem. I do a lot of projects involving reflection and erasure is a real pain.

[htirwin]

My interpretation so far, is that C++'s advantages in some circumstances are disadvantages in others, and the same applies to Java.

For example, C++ doesn't enforce a coding style. For an individual, small team, or very skilled and cohesive team, I would think this would be a big advantage.

But for a very large team, or a dysfunctional team or unskilled team, this could be a big disadvantage for obvious reasons.

And a language using garbage collection, or a rule that bars employees from using manual memory management, could be almost a necessity if your dealing with a bunch of programmers who you can't trust.

But again if your an individual or a small, or very cohesive and skilled team, you have an advantage having control over memory allocation.

It's kind of like the rule in a school computer lab: " no food, no drinks. ". You don't know what idiot is going to spill their drinks on the keyboard.

Of course there are reasons why even an individual or skilled cohesive team might want to use garbage collection. And there are times they might not want to. It could be a matter of convenience or performance, or development speed.

But I don't buy the idea that one language is better in general than the other in all applications, for example Java, over C++, just because it is made safer and easier for large teams to be managed.

I'm a perfectionist to the level that a few seconds difference in startup speed if nothing else, will make or break my decision which language to pick.

[LB]

Well spoken! Reinforces the idea that you should not dislike a language just because it's not right for your project.

[Veltas]

iseeplusplus wrote:

For example, C++ doesn't enforce a coding style. For an individual, small team, or very skilled and cohesive team, I would think this would be a big advantage.

But for a very large team, or a dysfunctional team or unskilled team, this could be a big disadvantage for obvious reasons.

Although it's not so important, I disagree that this is an advantage for small teams and a disadvantage for big teams. Surely it is a disadvantage for a small team as at least an enforced coding style would make code consistent, but for a large team an enforced style would restrict what they may do with enough people to consider a different style?

[htirwin]

Although it's not so important, I disagree that this is an advantage for small teams and a disadvantage for big teams. Surely it is a disadvantage for a small team as at least an enforced coding style would make code consistent, but for a large team an enforced style would restrict what they may do with enough people to consider a different style?

But a small team of skilled programmers can agree to code in a consistent style, and they have the advantage that they can customize their style on a case by case basis to better match the problem.

[Veltas]

@iseeplusplus

I see more of an issue with coming up with a good style for the problem with a small group rather than with a larger group.

[o1vk4iN6]

For example, C++ doesn't enforce a coding style. For an individual, small team, or very skilled and cohesive team, I would think this would be a big advantage.

But for a very large team, or a dysfunctional team or unskilled team, this could be a big disadvantage for obvious reasons.

How does Java enforce a coding style ? It simply forces classes to be restricted to one file and the be named the same as the class. You can still have different coding styles, everyone using their own naming convention.

[Veltas]

I think by coding style they're referring to the overall structure and design rather than naming conventions.

By the way Java has a guide for naming conventions so if you follow Java strictly then you all use the same naming convention anyway.

[rapidcoder]

When it comes to coding style, it is not that much important which style you agree to, as much as selecting some style and sticking to it, making the project consistent.

For example, C++ doesn't enforce a coding style. For an individual, small team, or very skilled and cohesive team, I would think this would be a big advantage.

But for a very large team, or a dysfunctional team or unskilled team, this could be a big disadvantage for obvious reasons.

It is not a matter of skill or size of the team. It is matter of dependencies. Considering a very limited number of features in standard library, in C++ you can't do any serious project without third party libraries. And here you face a problem of diverging coding styles / API design. As soon as you try to use two or more external libraries, your code starts to becoming a mess. E.g. try to use both STL/Boost and Qt in a single project - both define their own classes for collections, strings, but use completely different design conventions.

For me this is the same problem as in PHP. In theory, they say, a skilled programmer can write beautiful PHP code. But this almost never happens in reality. Every project ends up being a spaghetti of SQL, JavaScript embedded in HTML embedded in PHP, with inconsistent naming convention and complex code structure. The problem is more serious in C++, because it gives programmers much more room to invent their own programming styles.

[Cubbi]

rapidcoder wrote:

try to use both STL/Boost and Qt in a single project - both define their own classes for collections, strings, but use completely different design conventions.

I actually worked in such project - Qt was fairly tolerable as long the poject's core structure was following the usual C++/Boost conventions. As with any large old framework-defining library (Qt, ACE, RogueWave, or even MFC), there's a choice between loose coupling and tight integration.

(FWIW we maintained loose coupling, and different GUI setups were plugged in for different customers: some even got Java to do the graphics)