13 May, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
Ok, so i know there is a G++ compliant Rom2.4 out there, also MERK++ is great, but the project i've already been working on for the last year is Quickmud, not to mention all the changes i've made.

So, because of the benefits of using some C++ functionality, i've found it might be time to make my project G++ compliant right? Well, i figure, hey, all i have to do is compare the clean Rom2.4 to my QuickMud and make some changes to make it work. Well, i've found that this is not as easy as i thought.

So, because i dont have a clue how to fix each line error, what do you guys think i should do. is there anything i can read over without years of C++ to make the changes? Or, would you guys have a problem with me uploading the errors and seeing what it is i need to change?
13 May, 2009, David Haley wrote in the 2nd comment:
Votes: 0
Almost all of the errors belong to one of a small number of categories. The main ones are:

- words that are now reserved in C++. E.g., 'class'. Solutions include renaming 'class' to 'cls', 'Class', 'claz', …

- g++ being stricter than gcc about type casting. Most of this involves just adding in explicit casts where necessary.

- g++ being stricter about const correctness. This is the biggest and perhaps most annoying one to fix. I'll assume for now that you know what the const keyword does (please tell me if you want a refresher). In gcc, you can do things like this:

void foo(char* s) { … }
const char* s = …;
foo(s);

Line three is a violation of const correctness because s is supposed to be an immutable string but function foo expects a mutable string. For some reason (which is actually somewhat unclear to me) gcc has been fairly lax about this and allowed it. The result can be pretty bad, ranging from unexpected string changes to segmentation faults. g++ has recently (as of 4, IIRC) become more strict about enforcing const correctness. Although this is a Very Good Thing in the long run, in the short term (unfortunately for us) a lot of MUD code has historically not been very good at writing fully correct code. Strings in particular are used incorrectly in several instances. It took a fair amount of work to fix this for FUSS (you can learn more by exploring the forums there), and I imagine the same to be true for these fixed up versions that you're speaking of.

Still, even though it's a fair bit of work, a lot of it isn't really hard and a lot of the warnings are really the same thing over and over again.

The gist of it is that functions need to be redeclared to accept const strings when they can (which is whenever you don't need to modify the argument), and you need to work around things when you can't (which is when the function really does need to modify its argument). The most annoying change in particular is having to make all do_funs take a const char* parameter for the command argument.
13 May, 2009, elanthis wrote in the 3rd comment:
Votes: 0
David Haley said:
- words that are now reserved in C++. E.g., 'class'. Solutions include renaming 'class' to 'cls', 'Class', 'claz', …


'klass' is another favorite. :)

Quote
Line three is a violation of const correctness because s is supposed to be an immutable string but function foo expects a mutable string. For some reason (which is actually somewhat unclear to me) gcc has been fairly lax about this and allowed it.


I believe the main reason was to work around the goofy C string API. For example, strchr() is both useful for const and non-const strings. However, if you define it as taking a const string then it cannot return a non-const pointer, but if you define it as taking a non-const string then you can't use it for const strings. The definitions in C++'s <cstring> header just have an overloaded const and non-const version of strchr() but the main C headers can't do that.

I recall there being some discussion about adding special constructs to C in GCC for system headers to allow overloading for that case, but I don't know if anything is going to actually be done. I do recall reading something about needing to be more careful with strchr() in GCC 4.4, so maybe they did end up doing that.

There are a number of other C/C++ incompatibilities that mostly come down to C being weaker. You can't use ++ or – on an enum type in C++ for example. There's also some differences with unnamed structs and unnamed unions. You can also run into troubles with some headers, which is why it is generally recommended that C++ programs use the C++ headers like <cstring> instead of the C <string.h>, although this is by no means required and 99% of the time unnecessary.
13 May, 2009, David Haley wrote in the 4th comment:
Votes: 0
elanthis said:
I believe the main reason was to work around the goofy C string API. For example, strchr() is both useful for const and non-const strings. However, if you define it as taking a const string then it cannot return a non-const pointer, but if you define it as taking a non-const string then you can't use it for const strings. The definitions in C++'s <cstring> header just have an overloaded const and non-const version of strchr() but the main C headers can't do that.

Ah, that makes sense. It kind of smells like fixing the infection by amputating the whole limb, though. On the other hand, the alternative of having strchr and cstrchr is maybe annoying to some people, but IMO it preserves the purity and hence sanity of the language. (What point is there in having constness if you don't need to respect it?)
13 May, 2009, elanthis wrote in the 5th comment:
Votes: 0
Tell that to the ANSI committee. Not much GNU/GCC can do about it, really, other than using one kind of hack or another.
13 May, 2009, David Haley wrote in the 6th comment:
Votes: 0
Oh, for what it's worth, wasn't meaning to blame it on GNU.
0.0/6