24 Nov, 2009, jurdendurden wrote in the 1st comment:
Votes: 0
So. Here I am. I have introduced myself tonight, and decided to no longer just be a spectator here on these forums. I am learning through trial and error, with the help of Google and all the mud forums I have found on the web thus far. Currently, I am building an Ad&d based mud (using quickMUD found in the repository), and I'm wondering what sort of steps I would need to take in order to convert my mud from straight C to a C++ friendly environment. All feedback welcome :)
24 Nov, 2009, Greyankh wrote in the 2nd comment:
Votes: 0
Hello,

I too am starting that process. I have found, through my trials and errors, that having the server portion already written in C++ is much less time consuming. Two code bases I have begun using are, Tinymudserver and Awemud. Both are written in C++. I plan to hack them together because both offer features I want.

From that point, it is easier to take a codebase like Circle, Smaug, or Rom, and slowly rewrite the features. By doing this, you start to be able to map out where specific methods and functions are, how they access other parts, and in time, you will have something robust.

Good luck, and happy programming.
Grey
24 Nov, 2009, David Haley wrote in the 3rd comment:
Votes: 0
The most obvious first step is getting the C MUD to compile as C++, using g++ for example. This is easy but tedious. SmaugFUSS went through this process from 1.7 to 1.8 (or thereabouts). Other than normal C to C++ changes (like 'class' becoming a reserved keyword) there are issues with g++ being more strict than gcc. For example, it requires that constness be respected much more stringently than gcc does. This is annoying in the short term but a Good Thing in the long term – in any case, you have to deal with it when moving to C++.

A comment I make to everybody who's considering a move like this is to not convert things to classes merely for the sake of conversion. Convert things when you get real value for the conversion. This way, you won't spend days and days (and weeks and weeks) doing a whole bunch of work that gives you no real benefit.

One technical note is that if you want to use objects inside your structures, those structures must be allocated with 'new' instead of 'malloc' (for otherwise, the member object constructors are not called). A consequence of this is that they must be freed using 'delete' instead of 'free'.

I'll write more later, but for now it's time to grab some food. :smile:
24 Nov, 2009, JohnnyStarr wrote in the 4th comment:
Votes: 0
I converted my QuickMud base to compile in g++. It was 'tedious' to say the least.
The main benefits were being able to use new/delete. I wasn't really happy with the fact that it was a chore
to use std::string with the base's current use of char*. I know there are some that have converted all uses of
char* with std::string. But I found myself using C features more, just because I was comfortable with it. At the
end of the day, I agree with David that it is better to make changes as you need them, vs converting things for
the sake of it.

Anyway, if you have any questions with your QuickMud conversion, let me know :wink:
24 Nov, 2009, Runter wrote in the 5th comment:
Votes: 0
I think "enabling" is a better term than "converting" to C++. In any event, enabling C++ is much easier than actually converting to the conventions of C++. In the later case it's almost worth your time to just start from scratch if you're serious about it.
24 Nov, 2009, JohnnyStarr wrote in the 6th comment:
Votes: 0
Runter said:
I think "enabling" is a better term than "converting" to C++. In any event, enabling C++ is much easier than actually converting to the conventions of C++. In the later case it's almost worth your time to just start from scratch if you're serious about it.

When you have to rewrite hundreds of casts and 'convert' char* to const char* get back with me and tell me you're "enabling"
C++ :devil:

EDIT: it seems you are saying that you know how to "enable" ROM code to compile in g++ without
converting the above???
24 Nov, 2009, Runter wrote in the 7th comment:
Votes: 0
JohnnyStarr said:
Runter said:
I think "enabling" is a better term than "converting" to C++. In any event, enabling C++ is much easier than actually converting to the conventions of C++. In the later case it's almost worth your time to just start from scratch if you're serious about it.

When you have to rewrite hundreds of casts and 'convert' char* to const char* get back with me and tell me you're "enabling"
C++ :devil:

EDIT: it seems you are saying that you know how to "enable" ROM code to compile in g++ without
converting the above???


Got any examples other than dumb work that I could show any non programmer how to do?

And yeah, there are ways to get it to compile without explicit casts. That's really a compiler issue. The real question is how many C conventions do you want to keep in place? That's just another one on the long list—One that universally is accepted as a good change and thus even by default the compiler treats as error.

And yeah, I've "converted" a lot of projects to C++.
24 Nov, 2009, JohnnyStarr wrote in the 8th comment:
Votes: 0
What do you mean by dumb work?
Also, what compiler could you use that would allow
The above issues? FWIW, I wasnt trying to sound pompous, I'm just curious.
24 Nov, 2009, Mudder wrote in the 9th comment:
Votes: 0
Re: jurdendurden

Sounds like you're better off using a ROM base that is already C++ enabled. There are at least three out there, even a Merc++
I'm working with RaM fire and have similar goals (though I'm taking my time).

I plan on uploading a lot of the changes/fixes I made to the codebase before I begin to actually change anything. I'm currently just working on the base.
24 Nov, 2009, David Haley wrote in the 10th comment:
Votes: 0
There are very real advantages to using C++ conventions and OOP design in a framework that is otherwise mostly C. Write new code using the easier OOP techniques. Just don't waste time rewriting otherwise perfectly good code. Now, if you find yourself rewriting that code anyhow (because you have a pressing reason to do so, e.g. you want it to do something different functionally) then sure, rewrite it using C++ instead. That is how I work on my code: most of it is in C, but as I have reason to I move to C++. For example, the character objects are now objects with methods etc., because there are very useful reasons for hiding data as private members. But I made the mistake several times of trying to rewriting the entire MUD in C++ using proper data abstraction etc., and the result was rather consistently many weeks spent for basically nothing. Spend time improving things, not tearing down one layer of paint to add more or less the same thing back. Besides, you probably don't even know what your future requirements are, so why rewrite everything to your current requirements when your future requirements will change?

Note that you can use OOP in C as well, you just need more discipline to do so.
25 Nov, 2009, Greyankh wrote in the 11th comment:
Votes: 0
Quote
Sounds like you're better off using a ROM base that is already C++ enabled. There are at least three out there, even a Merc++
I'm working with RaM fire and have similar goals (though I'm taking my time).


Which codebases are these?

Grey
25 Nov, 2009, Davion wrote in the 12th comment:
Votes: 0
Greyankh said:
Quote
Sounds like you're better off using a ROM base that is already C++ enabled. There are at least three out there, even a Merc++
I'm working with RaM fire and have similar goals (though I'm taking my time).


Which codebases are these?

Grey


Here is Murk++ and here is RaM Fire. Enjoy! :)
25 Nov, 2009, Mudder wrote in the 13th comment:
Votes: 0
RaM fire - A is a Rom derivative. RaM has two projects, Ice = C and Fire = C++

Murk++ is a C++ version of Merc 2.2

G++ Clean Rom24b6 - A Rom base that compiles in C++

EDIT: Damn, Davion beat me to it.
25 Nov, 2009, Kayle wrote in the 14th comment:
Votes: 0
There's also SmaugFUSS 1.9, SWRFUSS 1.3, and SWFotEFUSS 1.4. But those aren't anything like ROM. But they all compile as C++.

[Edit:] The most recent versions and releases can be found at: SmaugMuds.org
25 Nov, 2009, Greyankh wrote in the 15th comment:
Votes: 0
Thanks.
25 Nov, 2009, Kline wrote in the 16th comment:
Votes: 0
+1 for AckFUSS as compiling in g++, too!

It has bits and pieces of C++ in some places, as I've needed to re-write or add them, but is still mostly in C following the mantra already said by others of only re-writing things as I need to, not just because I can.
0.0/16