Let's switch to C++ ?

[jrgp]

I don't want some careless scripter crashing my PC and messing with anything else I got running.

The C scripts would be ran on the server, and if they were written carelessly they'd muck up the server, not your own client. And if the server was written in a clever way, the scripts would be sandboxed and unable to interfere with the server's main thread and those of other scripts.

[HeavyMetal.Penguin91]

Thanks for clearing that up - now I can't think of any arguments for Pascal.

[LORD KILLA]

All I can say is... this is pathetic.

LORD KILLA, please, make your own game in C++ first. I know you haven't done it. I also know that you have no programming experience and that you don't probably know what a debugger is.

In short; someone lock this topic for good.

2) structs != classes. A struct is slightly similar to a class, except it has no methods (functions) and all members (variables) are public. Other than that, they are not interchangeable and the only reason c++ has them is to support older C libraries that people might want.

Otherwise good, but the only difference between struct and class is the fact that all the members of a struct are public by default. For class they are private by default. Keeps the backwards compatibility that way. So you could replace all the classes with structs if you wanted to, as long as you keep the access levels compatible. Same vice versa.

Well, I'd recommend you not to just 'think' what people know. I know a lot about programming stuff (i know C++, C#, VB and Pascal(only soldat-pascal)).

[jrgp]

If you're that sufficient in software development, then go make your own game instead of demanding changes that will never take place.

[Clawbug]

(Forget to deallocate some dynamic memory in C   and you could crash your OS - I know I have ).

10 The PROGRAMMER forgets to free the allocated memory -> PROGRAMMER made the mistake. Besides, blame Windows for crashing.

The problem is NOT the programming language. It's the PROGRAM. If your houre collapses, you blame the builder and the architecture, not the tools used.

This is rubbish - I can't be bothered to give a proper argument, but if the tools had no effect on the programmer, we'd all still be f**king around with punched cards and binary or assembly.

GOTO 10

The topic is about C++, which is fairly safe as long as the PROGRAMMER knows what he/she is doing. E.g. stay away from pointers and use smart pointers when really needed(shouldn't even happen really), use constructors only to initalize variables, don't use exceptions etc.

Sloppy software is due to lack of knowledge about the issues in hand. This applies to high level languages too; they are slow. If the software runs too slow, then the developer didn't have enough knowledge about the speed limitations due to sloppy language used, or then the developer has no knowledge about optimizing the code and using optimal algorithms and data structures. Again, it's the developer to blame for sloppy software, not the tool used. If the tool is bad, then the developer is to be blmamed for using wrong tool.

All I can say is... this is pathetic.

LORD KILLA, please, make your own game in C++ first. I know you haven't done it. I also know that you have no programming experience and that you don't probably know what a debugger is.

In short; someone lock this topic for good.

2) structs != classes. A struct is slightly similar to a class, except it has no methods (functions) and all members (variables) are public. Other than that, they are not interchangeable and the only reason c++ has them is to support older C libraries that people might want.

Otherwise good, but the only difference between struct and class is the fact that all the members of a struct are public by default. For class they are private by default. Keeps the backwards compatibility that way. So you could replace all the classes with structs if you wanted to, as long as you keep the access levels compatible. Same vice versa.

Well, I'd recommend you not to just 'think' what people know. I know a lot about programming stuff (i know C++, C#, VB and Pascal(only soldat-pascal)).

This quote makes me convinced that you don't really know what you're talking about:

Why don't we switch to C++ instead of old pascal, wich is instable as scripting core?

It's the program logic which fails. Who is responsible for program logic, compiler or programmer?

[VirtualTT]

Arguments in the first post are complete nonsense...
I'm not even going to comment them...

About using C++ for scripting:
This idea fails cause C++ isn't very suitable as scripting language. C++ is extremely difficult to parse. And it's syntax has a lot of unnecessary complexity while most of it's features aren't going to be supported for scripting. (Also it seem that some ppl here don't understand that only pascal syntax is used for scripting (not pascal language!) and this question should sound like "Should C++ syntax be used for soldat server scripting?")

However i see some suitable application for C++ in soldat:
As you all probably know, Soldat is using outdated JEDI library as DirectX 8 wrapper (D3DX81ab.dll). And i bet it's a cause of most of the Soldat low-fps problems and various incompatibilities. So writing new wrapper and switching Soldat to DirectX 9 would solve them. And using C++ for this is a natural choice since DerectX is made to be used with C++. Writing new DirectX wrapper seem to be quite a complex task, but i think it's not that difficult since Soldat probably doesn't use most of the JEDI functionality. And this would definitely make most of soldat players more satisfied with it. (especially compared with this usless for everyone (except for few advanced soldat-rentals admins) SQL support...)

[Neosano]

It would be neat if the server was extensible by dynamic libraries, but there would be absolutely no point forcing people to use C++.

And is there any point forcing me to use pascal? That's just a pain in my balls. Thank you for clearing that I deserve it. You're a real sadist.

Voted yes, but not c++ please. Java is awesome.

Just for clearing - server crashes not because of the scripts. It crashes because of what they do. I'm not sure what are you guys talking about. (stability ??wtf) So you'll make the script almost independent of the server. SO WHAT? Server will crash and your script will continue working, WHERE'S THE STABILITY?

But of course, we're like 20 years late. Pascal is already forgotten. No one uses it, cmon, bitches, move to java.

[Clawbug]

Voted yes, but not c++ please. Java is awesome. .

Yes, but not Java please. Google's programming language - Go is awesome. :p

[Neosano]

Voted yes, but not c++ please. Java is awesome. .

Yes, but not Java please. Google's programming language - Go is awesome. :p

Are you kidding?? What is this shit? WHY?? Java is stable and ok.

[Clawbug]

Voted yes, but not c++ please. Java is awesome. .

Yes, but not Java please. Google's programming language - Go is awesome. :p

Are you kidding?? What is this s**t? WHY?? Java is stable and ok.

I am dead serious. IMO Java just plain sucks. A great resource hog for nothing, slow and bloated, and there's nothing why one wouldn't prefer C# over it. And when it comes to real-time software, I'd prefer having the software written with efficiency as one of the top priorities.

Sure, Java and C# are both great for non-time-critical software(for example, I'd never start doing an email client with C or C++), and they allow quite rapid development but really, they are one of the reasons why software becomes slower faster than hardware become faster.

Right tool for the right task.

[Neosano]

I guess it's not easy to run C# in linux.
There's some project called mono, but I haven't tried it
Java is fast enough to work with soldat server.

[VirtualTT]

Neosano: you can write soldat scripts on Java right now simply using translator. Yet again, stop messing programming languages and scripting syntax.

[ramirez]

It would be neat if the server was extensible by dynamic libraries, but there would be absolutely no point forcing people to use C++.

And is there any point forcing me to use pascal? That's just a pain in my balls. Thank you for clearing that I deserve it. You're a real sadist.

If you read the rest of my post, I was actually suggesting moving away from Pascal too. But Pascal is still better for scripting than C++ is.

The topic is about C++, which is fairly safe as long as the PROGRAMMER knows what he/she is doing. E.g. stay away from pointers and use smart pointers when really needed(shouldn't even happen really), use constructors only to initalize variables, don't use exceptions etc.

Where did you get the "don't use exceptions"? The only way constructor can really tell that something went wrong, is to throw an exception (and this is the preferred way to do things in C++). Maybe you're thinking destructors; destructors should never throw exceptions, but there's absolutely nothing wrong with a constructor throwing an exception.

[Clawbug]

Where did you get the "don't use exceptions"? The only way constructor can really tell that something went wrong, is to throw an exception (and this is the preferred way to do things in C++). Maybe you're thinking destructors; destructors should never throw exceptions, but there's absolutely nothing wrong with a constructor throwing an exception.

Consider this:

Code: [Select]

void this()
{
    MyObject* SomeObj = new MyObject();

    that();

    delete SomeObj;   
}

What of that() throws an exception? Or there are 1+n functions which may throws exceptions in the code? It would require to write separate resource manager to keep track of things lying around. Usually it's just easier to stick without using exceptions.

Then again, it is just up to the programmer to counter issues like this. At least I find it way more pleasant to work without having to deal with exceptions, at least with the small scale projects I've been working on.

Though, all the hassle can be avoided by using smart pointers only, so yeah. Up to the developer, I guess.

[ramirez]

That isn't the fault exceptions, that is just faulty design. Exceptions make error management much cleaner and simpler, and you should use them. I could just as well as make an argument that "what if the programmer forgets to delete the object?" (eg. remove that last line from the function). Because that's what really is happening there; the programmer is forgetting to delete the object in one of the return paths. On one hand it can show that the programmer is inexperienced, but on the other hand even good programmers can make mistakes like this, that's why it's good to code in a way that you don't have to pay attention to stuff like that (more on that later).

Even without exceptions, you could easily write the code incorrectly like this:

Code: [Select]

void this()
{
    MyObject* SomeObj = new MyObject();

    if (that() == -1) return; // oops! forgot to delete something?

    delete SomeObj;   
}
Basically that is the very same thing, the fault is completely the programmer's. In a situation like that, the proper way to do deal with the situation is catching the exception and re-throwing it:

Code: [Select]

void this()
{
    MyObject* SomeObj = new MyObject();

    try {
        that();
    } catch (...) {
        delete SomeObj;
        throw; // re-throw
    }

    delete SomeObj;   
}
However since this kind of design becomes quite ugly and messy fast if you have multiple exit paths, it's recommended that you use a pointer object that deals with freeing the memory when the pointer goes out of scope (since when an exception is thrown, the stack is unwound normally, so the pointer object's destructor still gets called). You don't always need a smart pointer for this, something like auto_ptr that is included in the current standard library is often sufficient:

Code: [Select]

void this()
{
    std::auto_ptr<MyObject> SomeObj = new MyObject();

    that();
}
If that() throws, auto_ptr will free SomeObj at that time. Please note that auto_ptr is *not* smart pointer though, it does not reference count (it can transfer ownership though, but that's irrelevant in this situation). Its purpose it to simply ensure that a pointer is deallocated upon exiting a scope. That being said, even if you don't use exceptions if your function has many exit paths it's generally a good idea to use auto_ptr (or some smart pointer), because you can just as easily make the mistake of not freeing some object without exceptions.

Anyway, exception handling is something that any good programmer should use. It makes the application design that much better. You can easily catch fatal errors in one place and give a nice error to user, and you can properly clean up the program instead of having to ugly stuff like exit(); on fatal errors. And no need to check if function return error codes (ugh!), you can just trust that if a function returns something, it's what it's supposed to return. When people don't use exceptions, most people just completely ignore error checking and reporting because it's just plain gruesome and major pain in the ass to do. Exceptions let you code in a way that you don't have to be concerned about whether every second function returns a valid value, or an error code, while still properly dealing with exceptional cases when they do occur.

EDIT. And going back to constructors, since they can't return anything, the only other way than using exceptions would be to have a like an additional member object that marks the object as valid or invalid, and then each method of the class would need to check that value before using it. Not only is that more inefficient, but it's pretty tiresome to write code like that. Basically read this: http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.2

[iDante]

Java, C++, C, etc, are not so good for scripting.
I'd stick with languages designed for it. JavaScript is awesome, Lua, Python, things like that.

I'm just fine with soldat pascal though.

[Neosano]

That isn't the fault exceptions, that is just faulty design. Exceptions make error management much cleaner and simpler, and you should use them. I could just as well as make an argument that "what if the programmer forgets to delete the object?" (eg. remove that last line from the function). Because that's what really is happening there; the programmer is forgetting to delete the object in one of the return paths. On one hand it can show that the programmer is inexperienced, but on the other hand even good programmers can make mistakes like this, that's why it's good to code in a way that you don't have to pay attention to stuff like that (more on that later).

Even without exceptions, you could easily write the code incorrectly like this:

Code: [Select]

void this()
{
    MyObject* SomeObj = new MyObject();

    if (that() == -1) return; // oops! forgot to delete something?

    delete SomeObj;   
}
Basically that is the very same thing, the fault is completely the programmer's. In a situation like that, the proper way to do deal with the situation is catching the exception and re-throwing it:

Code: [Select]

void this()
{
    MyObject* SomeObj = new MyObject();

    try {
        that();
    } catch (...) {
        delete SomeObj;
        throw; // re-throw
    }

    delete SomeObj;   
}
However since this kind of design becomes quite ugly and messy fast if you have multiple exit paths, it's recommended that you use a pointer object that deals with freeing the memory when the pointer goes out of scope (since when an exception is thrown, the stack is unwound normally, so the pointer object's destructor still gets called). You don't always need a smart pointer for this, something like auto_ptr that is included in the current standard library is often sufficient:

Code: [Select]

void this()
{
    std::auto_ptr<MyObject> SomeObj = new MyObject();

    that();
}
If that() throws, auto_ptr will free SomeObj at that time. Please note that auto_ptr is *not* smart pointer though, it does not reference count (it can transfer ownership though, but that's irrelevant in this situation). Its purpose it to simply ensure that a pointer is deallocated upon exiting a scope. That being said, even if you don't use exceptions if your function has many exit paths it's generally a good idea to use auto_ptr (or some smart pointer), because you can just as easily make the mistake of not freeing some object without exceptions.

Anyway, exception handling is something that any good programmer should use. It makes the application design that much better. You can easily catch fatal errors in one place and give a nice error to user, and you can properly clean up the program instead of having to ugly stuff like exit(); on fatal errors. And no need to check if function return error codes (ugh!), you can just trust that if a function returns something, it's what it's supposed to return. When people don't use exceptions, most people just completely ignore error checking and reporting because it's just plain gruesome and major pain in the ass to do. Exceptions let you code in a way that you don't have to be concerned about whether every second function returns a valid value, or an error code, while still properly dealing with exceptional cases when they do occur.

EDIT. And going back to constructors, since they can't return anything, the only other way than using exceptions would be to have a like an additional member object that marks the object as valid or invalid, and then each method of the class would need to check that value before using it. Not only is that more inefficient, but it's pretty tiresome to write code like that. Basically read this: http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.2

What the hell? Ever heard of garbage collection? No need to blow your ass doing this s**t. Cmon It's 2010, do you know when C came out?

[jrgp]

What the hell? Ever heard of garbage collection? No need to blow your ass doing this s**t. Cmon It's 2010, do you know when C came out?

Mandatory garbage collection severely limits what you can do, which is why C, Assembler, and others still have a very important place.

[ramirez]

What the hell? Ever heard of garbage collection? No need to blow your ass doing this s**t. Cmon It's 2010, do you know when C came out?

Sure I have, but we're discussing a language without garbage collection so that is kind of irrelevant.
And the code was C++, not C.

[Neosano]

jrgp,
They're forgotten already. How old are you omg?
The only reason to use them is if you need something with really good performance, for example physics engines. Still I wouldn't suggest using this old crap.

ramirez,
I haven't tried using C and C++ for long, there's just no need to do this. That's why I don't see any difference. Old is old.
C# is ok, it's much like java.

and


C is a general-purpose computer programming language developed in 1972


C++ was developed by Bjarne Stroustrup starting in 1979 at Bell Labs as an enhancement to the C programming language and originally named "C with Classes". It was renamed C++ in 1983
(thanks wikipedia)

So C is 31 years old, and C++ is 27 years old. They're even older than me and you. Have fun.

From: January 11, 2010, 08:14:04 amAnd I voted YES for switching to another language, doesn't really matter which one, but not c++