Advice on what language to use

nobodythere

I started windows programming with pure C++ on Visual Studio, found it to be a pain in the hole. E.g. because it was such a low-level language, window events for each control on a form ended up being all in the same function just because of the way windows works.

I heard about MFC, which I think is some sort of wrapper library for C++ that makes things easier... I think MFC is outdated now though or something...

So I'm just wondering what are the latest IDE/libraries/languages I can use that don't involve virtual machine things (like .NET/Java) and that are backwards compatible down to windows 98.

ianhobo

So I'm just wondering what are the latest IDE/libraries/languages I can use that don't involve virtual machine things (like .NET/Java) and that are backwards compatible down to windows 98.

I'm presuming from what you've said thats its requirement for you to be able to have/write gui's for your programs?
In my opinion, the two easiest ways are .Net and Java, but both of which are interpreted languages and you don't want that.

For windows GUI's, unfortunatly you have limited remaining options. And to be honest, i think that if you found c++ " a pain in the hole", you'd find java,c#,managed c++ a pain too.

Why don't you want to use an interpreted language? What are you trying to do?

fasty

MFC is still used quite a bit but yeah, it's considered outdated. It's a mishmash of wrapper classes and macros that hide away all the Win32 stuff you've already looked at. Once you get your head around it it's okay.

Alternatives would be WTL, which is a not very well documented library from Microsoft or something cross platform like wxWidgets.

Mutant_Fruit

ianhobo wrote: »

the two easiest ways are .Net and Java, but both of which are interpreted languages and you don't want that.

I don't believe either of those languages are interpreted. Both of those languages are *managed* languages though, which i think is possibly what you meant.

When a C# application is run, or library is loaded, it is compiled (once) into machine code and that's the code that is executed. This gives significantly faster performance than an interpreted language.

ianhobo

No, I believe I'm right in what I'm saying, compiling is the act of outputting machine/platform specific binary code. C sharp is "compiled" as you say, first into an intermediate language (CIL) , then into MSIL to allow it to be more specific. It doesn't get directly compiled for a specific platform until you produce/publish an .exe file, it is quite different to compiling C or C++. You still need to have the .Net environment installed to run any .Net program, unlike C or C++, which because it is compiled to a specific platform will run without the need for any additional software to be installed. The process is the same for java. java -> java bytecode -> interpreted by the JVM at runtime.

Being "managed" has nothing to do with at all, that simply means that any control of memory is removed from the programmer. You have no direct pointer manipulation, no memory allocation, and you most likely have a garbage collector of some sort.

ianhobo

From the horses mouth...

Java programs are run (or interpreted) by another program called the Java VM

http://java.sun.com/developer/onlineTraining/Programming/BasicJava1/compile.html

marco_polo

ianhobo wrote: »

No, I believe I'm right in what I'm saying, compiling is the act of outputting machine/platform specific binary code. C sharp is "compiled" as you say, first into an intermediate language (CIL) , then into MSIL to allow it to be more specific. It doesn't get directly compiled for a specific platform until you produce/publish an .exe file, it is quite different to compiling C or C++. You still need to have the .Net environment installed to run any .Net program, unlike C or C++, which because it is compiled to a specific platform will run without the need for any additional software to be installed. The process is the same for java. java -> java bytecode -> interpreted by the JVM at runtime.

Being "managed" has nothing to do with at all, that simply means that any control of memory is removed from the programmer. You have no direct pointer manipulation, no memory allocation, and you most likely have a garbage collector of some sort.

Being managed is very strongly linked with "semi-interpreted " languages such as Java and C#. Managed code is generally taken to mean any code that is executed by a virtual machine and not directly by the CPU. A virtual machine is responsible for a range of checks and safeguards to ensure that the code does not do anything that it is not supposed to do. Although of course the syntax of the language / compiller has a big role to play in what is allowed or not before we even get to this stage.

If being managed has nothing to do with whether a language is compilled directly to machine code or "interpreted, then what runs the garbage collector for example?

Not starting a fight just making a point , I find this this is truely one of the least clear areas of computer language terminology

Ginger

ianhobo wrote: »

No, I believe I'm right in what I'm saying, compiling is the act of outputting machine/platform specific binary code. C sharp is "compiled" as you say, first into an intermediate language (CIL) , then into MSIL to allow it to be more specific. It doesn't get directly compiled for a specific platform until you produce/publish an .exe file, it is quite different to compiling C or C++. You still need to have the .Net environment installed to run any .Net program, unlike C or C++, which because it is compiled to a specific platform will run without the need for any additional software to be installed. The process is the same for java. java -> java bytecode -> interpreted by the JVM at runtime.

Being "managed" has nothing to do with at all, that simply means that any control of memory is removed from the programmer. You have no direct pointer manipulation, no memory allocation, and you most likely have a garbage collector of some sort.

Well if you want specific platform stuff you just use NGEN to precompile the exe to more native code for the current platform.

In relation to needing the .NET Framework, you still needed the VCRT for Visual C++ (at least some parts of it anyways) which is not an interpreted language.

Usually interpreted language is not precompiled such as ASP and Ruby etc.
@Grasshoppa..

Does your application have to be windows based or would it be possible to run it in browser?

Also while maybe a long shot, VB GUI with C++ dlls could be an option as you could seperate the whole business logic into the DLLs and still design a GUI in VB6. Tho it would get messy with datatypes and the likes (hence partly where the .NET framework comes in)

You can use .NET 1.1 on Windows 98 if you wish, and also have the runtime included in the installer to be sure.

ianhobo

marco_polo wrote: »

"semi-interpreted "

...Nice

If being managed has nothing to do with whether a language is compilled directly to machine code or "interpreted, then what runs the garbage collector for example?

There are degrees of management too. But I still don't think "Managed" code is specific to interpreted languages. There are 10 to a penny C and C++ memory managers out there for these compiled languages. With these managers in use, I believe it is then "managed" code. All dynamic memory usage is removed from the programmer (at the expense of speed) and all references (variables,objects) are managed by this library. But it all still compiles, to platform specific binary code.

Garbage collectors are also available for C and C++, languages that in our current context would be deemed un-managed.
But like in C,C++,C sharp, Java, the garbage collector is just another process/function/thread etc that is run

C sharp uses a "JIT" (what microsoft call a "compiler") optimiser to transform the CIL into more efficient code. In this sense then, it is the code itself managing the garbage collection, unlike in Java wheres it external (ish) with the JVM
Didn't explain that as clearly as I would have liked, but I hope you get what I mean.

I find this this is truly one of the least clear areas of computer language terminology

it is, with many definitions available. The above is my own definition

ianhobo

Ginger wrote: »

In relation to needing the .NET Framework, you still needed the VCRT for Visual C++ (at least some parts of it anyways) which is not an interpreted language.

But only if you were using com interfaces, something which is specific to windows. You could/can still write completely independent c++ code that needs no additional dependencies.

Evil Phil

And wasn't the VCRT just a collection of libraries?

Ginger

Maybe I should have said VBRuntime instead

Q_Ball

I used WxWidgets for C++ in my final year. Its a handy enough lib for GUI C++ applications

Mutant_Fruit

ianhobo wrote: »

No, I believe I'm right in what I'm saying, compiling is the act of outputting machine/platform specific binary code. C sharp is "compiled" as you say, first into an intermediate language (CIL) , then into MSIL to allow it to be more specific

First read this: http://en.wikipedia.org/wiki/Interpreter_(computing)#Efficiency
Then read this: http://en.wikipedia.org/wiki/Interpreter_(computing)#Just-in-time_compilation

An interpretor interprets each line every time, a compiler just does it once. In C, the compiler is run before the program is executed, hence it is a 'compiled' language as the machine code is generated before you ever run the program. This means the program must be 'compiled' for each individual platform.

In both Java and C# the compiler is run when you double click on the .exe, and so machine code is generated on startup. This means that the program does not have to be compiled for each individual platform. C# is smart enough to only compile code when it is first called, and then stores the result. I'm unsure as to the exact process Java uses to JIT their code, but i assume it's similar.

So, compiler == fast, as the code is 'interpreted' once, whereas an 'interpreter' is slow, because the code is interpreted each and every time a line is executed. That's the difference, as i see it.

marco_polo

Mutant_Fruit wrote: »

First read this: http://en.wikipedia.org/wiki/Interpreter_(computing)#Efficiency
Then read this: http://en.wikipedia.org/wiki/Interpreter_(computing)#Just-in-time_compilation

An interpretor interprets each line every time, a compiler just does it once. In C, the compiler is run before the program is executed, hence it is a 'compiled' language as the machine code is generated before you ever run the program. This means the program must be 'compiled' for each individual platform.

In both Java and C# the compiler is run when you double click on the .exe, and so machine code is generated on startup. This means that the program does not have to be compiled for each individual platform. C# is smart enough to only compile code when it is first called, and then stores the result. I'm unsure as to the exact process Java uses to JIT their code, but i assume it's similar.

So, compiler == fast, as the code is 'interpreted' once, whereas an 'interpreter' is slow, because the code is interpreted each and every time a line is executed. That's the difference, as i see it.

Java has a VM called "Hotspot", it's JIT compiller works a little diffferently to C#. It allows you to specify a client or a server version of the JVM. Programs using the "client" VM are quicker to start up as it performs less code optimisation upfront, the server VM takes much longer to start up but gives much better overall performance once running. As this code optimisation process has gotten so sophisticated and C# or Java are not executing code 'line by line' anymore I would not consider them to be interpreted languages in any real sense.

Cantab.

grasshopa wrote: »

I started windows programming with pure C++ on Visual Studio, found it to be a pain in the hole. E.g. because it was such a low-level language, window events for each control on a form ended up being all in the same function just because of the way windows works.

I heard about MFC, which I think is some sort of wrapper library for C++ that makes things easier... I think MFC is outdated now though or something...

So I'm just wondering what are the latest IDE/libraries/languages I can use that don't involve virtual machine things (like .NET/Java) and that are backwards compatible down to windows 98.

I'll second wxWidgets -- your code will be extremely portable and efficient.

C# is good for rapid GUI development -- have to say Microsoft's visual studio 2005/2008 is impressive... You'll be forever tied to windows OS though and all the continualy updating that goes with it.

I found when you start writing threads in C# GUIs in visual studio, things can get messy very quickly. I understand C# forms aren't thread-safe and you need to pass thread control messages using delegates. Basically if your GUI involves communicating with slow or unresponsive things (i.e. comms networks or comms ports), C# in visual studio 2005 can be a pain in the ass!

Java is great for networking, threading and loads of other stuff. It's quite reliable and intuitive. Problem with Java is that you don't get that "native feel" and it's becoming harder and harder to integrate Java apps seamlessly into the windows environment...

As ever, there are loads of trade-offs to consider.

Mutant_Fruit

Cantab. wrote: »

You'll be forever tied to windows OS though and all the continualy updating that goes with it.

C# is portable to MacOS and Linux and god knows how many different embedded devices.

Cantab. wrote: »

I found when you start writing threads in C# GUIs in visual studio, things can get messy very quickly. I understand C# forms aren't thread-safe and you need to pass thread control messages using delegates.

You seem to be mixing up concepts here. Thread safety is something that is an issue in every programming language (except for those languages which don't have threads) and isn't something that's only an issue in C# GUIs. In fact, Java GUI's have exactly the same problems with exactly the same solutions. If in C# you'd need a thread to avoid blocking the GUI, you'd need a thread in Java too. It's no more complicated in C# than it is in Java.

Also, i'm not quite sure what you mean by 'passing thread control messages using delegates'. A delegate can be considered a pointer to a function. It doesn't actually do anything as such.

Basically if your GUI involves communicating with slow or unresponsive things (i.e. comms networks or comms ports), C# in visual studio 2005 can be a pain in the ass!

How exactly is it that C# in visual studio is a pain in the ass when dealing with long running processes? How exactly is it C# differs as compared to Java which makes it that much harder to accomplish the task?

Cantab.

Mutant_Fruit wrote: »

You seem to be mixing up concepts here. Thread safety is something that is an issue in every programming language (except for those languages which don't have threads) and isn't something that's only an issue in C# GUIs. In fact, Java GUI's have exactly the same problems with exactly the same solutions. If in C# you'd need a thread to avoid blocking the GUI, you'd need a thread in Java too. It's no more complicated in C# than it is in Java.

Also, i'm not quite sure what you mean by 'passing thread control messages using delegates'. A delegate can be considered a pointer to a function. It doesn't actually do anything as such.


How exactly is it that C# in visual studio is a pain in the ass when dealing with long running processes? How exactly is it C# differs as compared to Java which makes it that much harder to accomplish the task?

To be honest, I find the syntax in C# for sending messages to/from threads a pain in the ass. It's bulky and unelegant.

Mutant_Fruit

Cantab. wrote: »

To be honest, I find the syntax in C# for sending messages to/from threads a pain in the ass. It's bulky and unelegant.

What syntax? I'm still not sure what you're talking about. You don't 'send a message' to a thread. The closest thing is to fire a signal which a thread is monitoring so the thread knows how to continue, and i actually find that rather neat and tidy. In the example below, note the simplicity in creating the thread and in controlling it's execution:

    public class Test
    {
        public ManualResetEvent signal;

        public void MainMethod()
        {
            // Create a separate thread which will run 'MyMethod'
            Thread t = new Thread(MyMethod);

            // Make sure the signal is set to false
            signal.Reset();

            // Start the second thread so i can complete work1 while this thread is completing work2
            t.Start();

            // Do work2 in parallel with work1
            DoWork2();

            // When work2 is finished, set the signal so the thread knows it can continue
            signal.Set();
        }

        public void MyMethod()
        {
            // Do work1 in parallel with work2
            DoWork1();

            // Wait until work2 is finished. As soon as signal.Set() is called, the thread can
            // continue past this point. If it reaches here before .Set() is called, it will
            // block and wait
            signal.WaitOne();

            // Do the remaining bit of work which relies on Work1 and Work2 being finished.
            DoWorkBasedOn1And2();
        }
    }

Cantab.

Mutant_Fruit wrote: »

What syntax? I'm still not sure what you're talking about. You don't 'send a message' to a thread. The closest thing is to fire a signal which a thread is monitoring so the thread knows how to continue, and i actually find that rather neat and tidy. In the example below, note the simplicity in creating the thread and in controlling it's execution:

    public class Test
    {
        public ManualResetEvent signal;

        public void MainMethod()
        {
            // Create a separate thread which will run 'MyMethod'
            Thread t = new Thread(MyMethod);

            // Make sure the signal is set to false
            signal.Reset();

            // Start the second thread so i can complete work1 while this thread is completing work2
            t.Start();

            // Do work2 in parallel with work1
            DoWork2();

            // When work2 is finished, set the signal so the thread knows it can continue
            signal.Set();
        }

        public void MyMethod()
        {
            // Do work1 in parallel with work2
            DoWork1();

            // Wait until work2 is finished. As soon as signal.Set() is called, the thread can
            // continue past this point. If it reaches here before .Set() is called, it will
            // block and wait
            signal.WaitOne();

            // Do the remaining bit of work which relies on Work1 and Work2 being finished.
            DoWorkBasedOn1And2();
        }
    }

That's great, you've demonstrated to everyone that you can follow a C# API.

Have you ever actually tried to write a c# program with multiple forms and threads?

You can find articles like this all over google.

Mutant_Fruit

Cantab. wrote: »

Have you ever actually tried to write a c# program with multiple forms and threads?

Yup.

Cantab. wrote: »

You can find articles like this all over google.

That's true, you can find bad articles everywhere. I have to say, that's definitely one of the worst ones i've seen with regards to threading a GUI. I saw one before which had 'async' sockets which were just synchronous sockets run in a separate thread. I saw another one which said asynchronous sockets didn't scale and the only way to build a scalable networking application was to use synchronous sockets and socket.select().

Yes, thats what your code can look like if you go mad with delegates. Yes, there are better ways to do it such as passing all parameters to the thread to start off with, and having one single 'UpdateGui' method which updates as necessary. That significantly reduces the amount of helper code you need.

How does java solve the issue? It seems like it can do it in exactly the same way:

Java code:

EventQueue.invokeLater(new Runnable() {
public void run() {
if (model.contains(i))
model.removeElement(i);
else
model.addElement(i);
}
});

In C#, the direct equivalent (which works and is thread safe) is:

BeginInvoke(delegate {
    if (model.contains(i))
        model.removeElement(i);
    else
        model.addElement(i);
    });

The above taken from: http://www2.sys-con.com/ITSG/virtualcd/java/archives/0605/ford/index.html

EDIT:

delegate void SetStringDelegate(string parameter);
delegate void SetBoolDelegate(bool parameter);

Can be reduced to:

delegate void SingleParamater<T>(T parameter);

And

delegate int GetIntDelegate();
delegate string GetStringDelegate(); 

can be reduced to:

delegate T GetDelegate<T>();

That's only a tiny tidyup though, there's still loads of other tricks to reduce lines of code.

Evil Phil

I have to say, generics really do rock the kasbah. I've written a single class that instantiates all our objects from our datasets (using generics) and its saved us a lot of development time.

Cantab.

Mutant_Fruit wrote: »

Yup.


That's true, you can find bad articles everywhere. I have to say, that's definitely one of the worst ones i've seen with regards to threading a GUI. I saw one before which had 'async' sockets which were just synchronous sockets run in a separate thread. I saw another one which said asynchronous sockets didn't scale and the only way to build a scalable networking application was to use synchronous sockets and socket.select().

Yes, thats what your code can look like if you go mad with delegates. Yes, there are better ways to do it such as passing all parameters to the thread to start off with, and having one single 'UpdateGui' method which updates as necessary. That significantly reduces the amount of helper code you need.

How does java solve the issue? It seems like it can do it in exactly the same way:

Java code:

EventQueue.invokeLater(new Runnable() {
public void run() {
if (model.contains(i))
model.removeElement(i);
else
model.addElement(i);
}
});

In C#, the direct equivalent (which works and is thread safe) is:

BeginInvoke(delegate {
    if (model.contains(i))
        model.removeElement(i);
    else
        model.addElement(i);
    });

The above taken from: http://www2.sys-con.com/ITSG/virtualcd/java/archives/0605/ford/index.html

EDIT:

delegate void SetStringDelegate(string parameter);
delegate void SetBoolDelegate(bool parameter);

Can be reduced to:

delegate void SingleParamater<T>(T parameter);

And

delegate int GetIntDelegate();
delegate string GetStringDelegate(); 

can be reduced to:

delegate T GetDelegate<T>();

That's only a tiny tidyup though, there's still loads of other tricks to reduce lines of code.

Agreed. It's still bulky though. I've seen such helper classes before. In Java, for simple applications like the OP was referring to, you can just use AWT (or limit yourself to thread-safe Swing component methods) which can be safely invoked from any thread.