[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  c++ support

c++ support

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


Pages: 1 2  3  4  5  6  

Posted by finnish   Russia  (18 posts)  [Biography] 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
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] 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.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] 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
[Go to top] top

Posted by Flannel   USA  (1,230 posts)  [Biography] 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.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] 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
[Go to top] top

Posted by Nick Gammon   Australia  (22,973 posts)  [Biography] 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
[Go to top] top

Posted by Poromenos   Greece  (1,037 posts)  [Biography] 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!
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] 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
[Go to top] top

Posted by Poromenos   Greece  (1,037 posts)  [Biography] 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!
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] 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.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] 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
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] 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.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] 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
[Go to top] top

Posted by Ian Kirker   (30 posts)  [Biography] 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
[Go to top] top

Posted by Flannel   USA  (1,230 posts)  [Biography] 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.
[Go to top] top

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.


149,418 views.

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

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

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]