Most of the boost libraries are simply header files (and typically very portable) that you can plop into your distribution (i.e., just pick what you want). A lot of the really useful stuff is slated to become part of the C++ standard.

Getting back to your problem… is the void* a true pointer to a heap allocated int, or is it an int that was cast to a void*? If it's a pointer to an int, you just need to de-reference after the cast… int x = *(static_cast<int*>(get_hash_entry(…)))

Hey that last de-reference did the trick; thanks! :D

Unless you're mixing data types, it is much better to solve this using templatized containers and avoid the casts entirely.

This is pretty common knowledge. I don't feel like retyping all the text you can find via 3 seconds on Google. Look up Smalltalk if you want to see what real OOP is all about (and Smalltalk has been around since the 60s, well before C++).



C++'s object system literally is just C structs with a virtual function table, and that's it. Conceptually they are totally different, but that implementation fact really limits what C++ was able to do with its object system. All of the other features that OOP had long, long before C++ was even conceived were left out of C++ because there is no way to efficiently implement them at the low-level niche C++ was meant to fill (systems programming). Languages like Smalltalk have been used to write OS kernels and the like, but they generally have performance issues at that level (and require a core written in assembler or C anyway).

Just a few examples of such features include multi-dispatch, true polymorphism ('duck typing' in modern parlance), reflection and introspection,



Yes, everything, with the sole exception of low-level direct-hardware access. If you're a fan of static typing (like me) then Ruby's dynamic nature may be considered something it does worse than C++, but there are plenty of true OOP languages that have static typing if that's what you're looking for.

C++ isn't a bad language. It's just not perfect, has a lot of limitations (which you had better be very familiar with if you want to claim to be competent at C++ – knowing a tool requires knowing when not to use it, after all), and there are better languages for a great many tasks these days, especially with the processing power of modern computers for which the raw bare metal C/C++ performance is no longer critical (and where managed languages are starting to pull off techniques that let them run faster than precompiled binaries).

You're actually serious, aren't you? Do you realize how far out on a limb you are with absolute (and indefensible) statements like that?

I think you're taking the statement just a little bit out of context. But that aside, you didn't do what you prescribed, namely back up your claims with concrete statements. So if this discussion is going to be at all interesting, you could start by sharing your opinions beyond the level of "omg u r ridiculous".

I don't want this discussion to be interesting, it's pointless. if Grimble thinks C++ has any kind of edge at all over modern languages aside from its low-level nature, that's his problem.

EDIT: and as a further note, I am not saying C++ sucks entirely and should never be used. I'm the author of a huge number of C++ apps and libraries and I almost took a job as the project lead for Apple's new LLVM/Clang-based C++ compiler. I just (through that experience) know that C++ has a HUGE number of limitations and that its advantages are very few in number compared to other languages. The topic has been discussed to death more times than I care to count, and I'm done debating with people who want to argue solely because they're emotionally attached to their favorite language and get pissy when anyone claims it's not The Best, be that C++, Ruby, Lua, Python, Java, or anything else.

I haven't made any claims, so what is it I need to back up exactly?

When someone makes claims like those made here, I'll call them on it. Not because I enjoy the ensuing and predictable efforts to defend those claims (and dig an even deeper hole), but because the person will likely think twice about it the next time, and the quality of the discussions will better for it.

Edit: I have no horse in this race BTW. My career path has gotten further away from C++ and application development in general.

Elanthis has given plenty of reasons for what he thinks the flaws are in C++. It's pretty easy to back out from that what he thinks Ruby/other languages do better, if you deign to take a very short moment to think about it: obviously, they address those flaws, and hence do better on those points.

You seem to object very strongly to the idea that Ruby does better at the things Elanthis listed, so presumably you have reasons for that. But you have twice now refused to share them with us.

Still, I'm tempted to agree with Elanthis that this discussion is pointless. So, well, yeah. Done here unless something more interesting comes up.

WOW! i was only gone 2 days and look what happened. :sad:

Besides all the juvenile arguments, I (the person who started this discussion for the purpose
of insight and education) appreciate the wealth of information. However, i dont see the big deal,
elanthis has a point, grimble has point, really i dont see how that can be resolved without
at least 20 more fruitless posts. :rolleyes: I think for the most part my questions were answered. :biggrin:

There is no "best" language, only a "best for a particular project, at a particular time." If you think otherwise, you're delusional. :)

I tend to use the "pain in the ass" method of deciding what language works best for the things I'm doing. The more hoops I have to jump through, the more system/library calls I need to memorize, and the more I end up having to use obscure/complicated features of a language, the more of a pain in the ass it is… and thus, the more sure I am that it's not the right tool for the job.

Doing a MUD in C++ is certainly possible. Is it easier than ruby? I doubt it. The very fact that you can't dynamically extend a system written in C++ without embedding a scripting system OR playing games with DLL's, tells me I'm going to be using some of those "PITA" features to get things done.

As far as snippets go…. no, you won't be able to use most of them unless you rewrite them. That's true, even if you stick to plain old ANSI C. Snippets tend to only work when applied to the stock version of whatever MUD they were released for, at the time they were released. The more you've modified things, the less likely they'll work "as is". At some point, it just becomes easier to skim the snippet to see what it does, and then write it yourself.

It's interesting to note that when you write this kind of code in C++, a lot of the initial time will be spent reimplementing dynamic language features in C++. For instance, a very useful thing to have is a generic mapping from an entity's attributes to values, without having to specify the type ahead of time, but where values are actually typed. (So that you could detect and prevent the assignment of a string to a number field.) In a dynamic language, this is very easy as you are equipped with introspection, full, easy and powerful run-time type information, and dynamic container types. To do this in C++, you have a lot of work to do, most of which would be implementing what the dynamic language gives you for free.

Another example is building some form of garbage collection or reference counting into the MUD. Basically free in most dynamic languages. (Well, in most modern language in general, really.)

C++ has its strengths, that is undeniable. But those strengths have to do with efficiency and low-level access, not high-level programming constructs. This is a well-known fact, and as Elanthis has said, this topic has been discussed over and over again in many places (forums, mailing lists, academic circles, software companies, …). Unless efficiency is the goal, or there is some kind of peculiar systems-related constraint, there is little reason to choose C++ for a new project. In fact, even when efficiency is important and memory is constrained, languages like Lua (which runs on many embedded systems) are being used by many developers the world over.