Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Entire forum ➜ MUSHclient ➜ Suggestions ➜ c++ support

c++ support

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3 4 5 6

Posted by

finnish Russia (18 posts) Bio

Date

Mon 29 Sep 2003 10:33 PM (UTC)

Message

hello there.
just thought it would be ltta easier to use C++ scripting instead of perlscript or maybe along with.
c++ and perl are similar languages not to say more.
and maybe it would save a lotta space, becausewhen i have to install activeperl it takes approx. 30mb of disk space

she never loved me why should anyone

Posted by

Shadowfyr USA (1,788 posts) Bio

Date

Reply #1 on Tue 30 Sep 2003 12:26 AM (UTC)

Message

It would also take 30mb of space to install a C++ scripting system, "assuming" such a thing exists. The scripting in Mushclient is not built into the client, but uses an external 'engine'. This means that any script type you want to run requires one of these engines to operate with Mushclient, and then only if Mushclient knows how to connect to it. If scripting where built in, then Mushclient would be an extra 30MB in size, would not support 4 different languages and would probably be a lot slower.

Assuming you could find a C++ script engine and it was actually smaller than 30MB, then Mushclient would still need to be changed to support that engine.

Basically, to explain it another way. If you have a printer and a copy of Word, you also need a 'driver' to sit in between and make them talk to each other. No driver, and the printer won't do anything. Same with a script. Without an engine (the driver) in between Mushclient and your script, all you have is a file with a bunch of C++ commands in it.

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #2 on Tue 30 Sep 2003 04:29 AM (UTC)

Message

I've never heard of a C++ scripting engine. I don't even think that C++ can do such a thing, but I could be wrong on that.

The big problem with C++, at least, in its most common form, is that it is not interpreted. It is compiled. That would make it considerably more difficult to use as a scripting languages, if not impossible. All the scripting engines are basically virtual machines for your script - this means that perhaps Java would be a better alternative than C++ to use as a scripting language, even if personally I'm not terribly fond of it.

What might be possible, on the other hand, but completely different, would be to have a DLL interface - i.e. dynamically load a given DLL and call a function in that library. However, I'm not absolutely positive that will work either. You would probably need to have some form of common protocol for a common entry point function, and then have a way of passing back and forth events, methods and such. This is probably far more trouble than it's actually worth.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Flannel USA (1,230 posts) Bio

Date

Reply #3 on Tue 30 Sep 2003 05:12 AM (UTC)

Message

loading a DLL is exactly what MC does. It loads the vbscript/etc dll and uses that as the go between. Try clicking onRegister DLL on the script menu, and youll see what I mean.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #4 on Tue 30 Sep 2003 07:06 AM (UTC)

Message

I don't believe we're talking about the same kind of DLL. I believe that the DLL that MC is loading, vbscript.dll, is the interpreter, the virtual machine, whatever you want to call it that executes the VB script. The DLL that I was referring to would be your C/C++ code, compiled into a DLL - not an interpreter. Hence the difficulty, because you would have to know the entry points, and the addresses of whatever functions you want to call.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (23,122 posts) Bio Forum Administrator

Date

Reply #5 on Tue 30 Sep 2003 07:07 AM (UTC)

Message

I agree with the comment that C++ is generally compiled not interpreted, and thus would be a funny script engine. Java is similar, if you want C++ style syntax, use that.

Personally I wouldn't compare C++ and Perl, contrast maybe, but not compare.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Poromenos Greece (1,037 posts) Bio

Date

Reply #6 on Tue 30 Sep 2003 12:07 PM (UTC)

Message

That DLL idea sounds interesting... Not that there's something MUSHClient can't do now, or that it's not slow enough to need compiled code, but out of curiosity, could it be done? Maybe specify a DLL whose functions triggers/aliases/whatever called? Or does it have to be declared beforehand (at MUClient compile time)?

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #7 on Tue 30 Sep 2003 05:11 PM (UTC)

Message

That's the thing Poromenos, to access functions inside a DLL you need to know their address. I'm not fully aware of the exact mechanisms of this; I believe that the DLL contains a symbol table of function vs address, but your program has to have declared something to the effect of "I want this function from that DLL, but I don't know its address quite yet". This would mean that you could, in theory, have a default DLL that was empty for every single event, trigger, function, whatever you would want it to contain - MUSHclient would need this declared at compile time. Then you could make a replacement DLL that contained the same functions, that did something useful this time, and the symbol lookup would find the right addresses.

I'm not sure if it's possible to have a common entry point that is a function that, given a string (for a function name) will return a pointer to the function, much like the table lookups in table.c of SMAUG. I don't know if this would work from an application to a DLL though.

An interesting question is how the C++ program would know how to call MUSHclient functions, e.g. World.Note "hello".

Still, like you said, MUSHclient can already do just about everything you need it to do, and having this extra DLL lying around seems like it could be very unsafe for program execution. The nice thing about scripts is that they're fairly controlled, and it's hard to have them break (too badly) your program. C++ on the other hand could hose your running application, and do all sorts of very nasty things if mistakes are made. I don't think it's a good idea to have DLL support, myself, considering the problem it's trying to solve.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Poromenos Greece (1,037 posts) Bio

Date

Reply #8 on Tue 30 Sep 2003 05:25 PM (UTC)

Message

Come to think of it, I also think it wouldn't be worth the hassle... It's not that needed, anyway...

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!

Posted by

Shadowfyr USA (1,788 posts) Bio

Date

Reply #9 on Tue 30 Sep 2003 06:18 PM (UTC)

Message

Scripting (except for Python) doesn't support this. You would need something like:

Declare Function GetDeskTopWindow Lib "user32" ()

Scripting doesn't support the 'Declare' option and I doubt any of the rest will work. When you execute CreateObject for a database or the like you are connecting to an ActiveX component using the IUnknown or IDispatch functions that are automatically added to ActiveX. In theory, other DLLs also have a table containing all the intefaces, but they are are set to expose them to scripts or other ActiveX interfaces. It is also pointlessly silly, since compiling the C++ code into a DLL, but not choosing to make it ActiveX would be dumb in this case. lol

As for a C++ engine.. Most muds use some version of C that impliments inheritance and the like for the internal code that makes them run. So interpreted C in not an impossibility, C++ wouldn't be either, but it wouldn't be a full implimentation. The problem is that as far as I know, no one has built an ActiveX based engine for it. Generally the trend has been to develope scripting languages that have the features you need for that. C++ tends to be far more complex than needed to do scripting.

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #10 on Tue 30 Sep 2003 08:05 PM (UTC)

Message

This may just be being picky, but what you're describing isn't actually interpreting C - it's interpreting a C-like language. There's a huge difference between those two.

Interpreting C, in the proper sense of the term, would mean having an interpreter that could execute ANY C code and give proper results. And I doubt that MUDs actually have such interpreters. Their engines just implement the features of C - basically the syntax, basic statements, whatever - that they want to use, and then they leave the rest. For instance, could those interpreters handle malloc function calls and complete pointer manipulation?

What do you mean by inheritance in C?

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shadowfyr USA (1,788 posts) Bio

Date

Reply #11 on Tue 30 Sep 2003 08:21 PM (UTC)

Message

Ok.. You may be right in the sense that it isn't true C, but then JavaScript isn't true Java, VBScript isn't true VB, etc. The engines doesn't compile any of those things into native code, thus malloc and the like would be handled by the engine, not directly. A C or C++ engine wouldn't be any different.

And by inheritance, I mean just that, the ability to have a single base class that you can instance and expand as needed. Maybe this is only true in LPC muds though. A lot of new ones seem to use databases heavilly, so when you make a new mob you are making a copy of some basic database entry, not creating an entirely new object based off a previous structure.

In any case. All scripts are interpreted. The may have the ability to compile themselves into a sort of tokenized form that executes like a real instruction set in the engine, but they are still being intepretted in the sence that they are not running native code. There is no reason why a limited form of C or C++ could not be designed to do this. There just aren't any around.

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #12 on Wed 01 Oct 2003 12:16 AM (UTC)

Message

But you see, that's exactly my point. This C-like language wouldn't be C... and Javascript, VBscript don't pretend to be Java and VB, hence the script. They pretend to be small language SIMILAR to their "parent" in syntax, but don't make the claim at all that it's the same language, or even that you have the same functionality.

Inheritance in C in that case doesn't make a lot of sense to me. If you want to have inheritance, why bother with C and why not just use C++? Unless you're talking about "fake" inheritance, and don't actually have proper classes with methods and v-table lookups and all that. Still, I think it's odd to put inheritance into C, because that's already been done (with ObjectiveC and C++ for instance.)

I don't believe I ever said that a limited form of C/C++ (as in, a language that had similar syntax but not the same semantics and functionality) couldn't be implemented in a scripting form - in fact, I wrote a scripting engine for my MUD that uses a language I wrote that has syntax very similar to C. The whole point I was trying to make is that it isn't worth it in this case, as you're not adding functionality, you're just adding a new kind of syntax. And making a proper C interpreter engine that actually had full C functionality would not be an easy task at all.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Ian Kirker (30 posts) Bio

Date

Reply #13 on Fri 21 Nov 2003 08:02 PM (UTC)

Message

LUA (www.lua.org) is an extension language that could do what you (finnish) want, if you can work out a way to implement it yourself. :P

-Ian

Posted by

Flannel USA (1,230 posts) Bio

Date

Reply #14 on Mon 01 Mar 2004 01:47 AM (UTC)

Message

Just browsing around sourceforge, and found this...
http://csl.sourceforge.net/csl.html
Its a C scripting language, which I havent read much about, but I was reading about it, and I remembered this discussion.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

171,402 views.

This is page 1, subject is 6 pages long: 1 2 3 4 5 6

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.