> > In this case though, it makes it incredibly easy for both myself,
> >and others to use the pre-existing c code. With the exception of
> >replacing str_dup's with _stridup's (and a few others like that, since I
> >didn't copy in all of the utilities), it was cut and paste, compile and
> >go.
> > This means that alot of the relevant changes people make to their
> >systems will be also nearly directly copyable. The won't have to learn
> >how to insert class members, with accessor functions or all that jazz.
> >They can get a working product right away, by copying code they already
> >know works.
>
> Question on this... would it have been possible to simpy write an interface
> that used the existing OLC files directly, such that we could just copy our
> own files over yours and have it compile basically? The reason being that
> I've made some rather extensive changes to redit.c, and would rather not
> have to go through it all again... heh.
There is no such thing as 'olc files' unless you're refering to
the [rsmoz]edit.[ch] files. In which case, what would be the point. All
of the _x_edit.[ch] files just have to do with the interface, not with
what actually gets saved (cept some range validation). The commands they
call (like save to disk, etc) are nearly identical to the commands the
editor uses. So, you can plunk whatever changes you make in your files
into the editor, don't even have to create a new class, or additional
methods or anything - just create a new dialog control
(textbox/checkbox/etc) and associate a member of the editor class with it
via the class wizard DDX/DDV controls, and you're done.
Of course, you can also add something to the 'onchange' or
'lostfocus' for that control to see if they entered a correct thing.
There's really no good method though, for taking what is a
text-based editor, which saves data based on the relative postion of other
data which may or may not also be in the process of creation/alteration,
and then save and load (and validate) said data.... and take that and turn
it into an offline, single user graphical display.
We talked about scripts beforehand, for defining how the dialog
controls should look, what gets loaded/saved/etc, but it would be many
levels more complex to write that, than to write the editor itself.
As for the C vs. C++ issues, generally speaking, C programs are
more optimal than their correctly made C++ counterparts. That is, if you
compare and correctly weight speed, program size, memory usage, etc, C
comes out on top more often. Some of it's simply because C is not as
complex as C++; C++ has to validate at run-time the arguments to
functions, since you can not only overload operators, but also provide
virtual(and then overloaded) functions, etc..
Basically, C++ makes it harder for the computer, by making it
easier for a programmer to write extensible/etc code.
I don't think that a program has to be in C++ to make it good,
though it may make it easier for medicore programmers to alter without
cutting their own throats. As far as I've seen, most C++ code ends up
being a bit more sloppy, maybe because the programmer never had to force
themselves to be origanized in another language, like C.
Of course, that's my opinion, and entirely subjective.
PjD
P.S. Looks like I'll not get the editor version out this weekend afterall
- girlfriend has been complaining about not enough together time, and
tomorrow we're doing a motorcycle trip to a state park for some hiking,
among other things.
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT