Portable Coding and Cross-Platform Libraries?

Bradee-oh! queries: "My brother and I were just commissioned to develop a large energy management system for a few big college campuses in the area. It will be written in C/C++. We know that in 6 months, when a preliminary test system will be installed, it will be running on NT/2000 servers. The software will be tested on NT for up to 12 months and a final version will run on NT a year after that. We also know that around that time, it will shift to *nix servers, and we're expected to account for that in development. The question is, what sorts of cross platform libraries will make this as painless as possible? I've never made it a point to code for 2 platforms at once in any language other that Java. Aside from the GUI, which we've already agreed to use QT 3.0 for, we specifically are looking for cross-platform libraries for multi-threading, serial port I/O, and network I/O."

"Ideal libraries would be open source and free, though those aren't as important as tested/stable/reliable. What are your recommendations? Anyone have experience writing for multiple platforms at once with threading, serial I/O, and network I/O all in mind? The ideal scenario would be to recompile on the new platform without changing a line of code - will this type of portability be possible?"

Comments

You have the answer

[dda]

You have the answer : Java has all what you need.

Re:You have the answer

[Anonymous Coward]

As much as I loathe Java... I have to agree in this case.

Re:You have the answer

[Navarre]

Sure, except speed. Java sucks.

Re:You have the answer

[jawtheshark]

Crippled? Hmmm, I don't know if that is true. Java in itself is an elegant language which has some limitations due to trying to support such a wide range of platforms transparently. You have to know what you are doing, that is all...but that counts for any language.
Java code runs fast (really fast) in a lot of cases, mostly the only thing that "feels" slow is the GUI. You can really enhance responsiveness by including intelligent Threading. You can also avoid creating of throwaway objects, thus limiting Garbage collection.
For the GUI, just don't use Swing if you don't need to... AWT is enough for simple frontends, yes it is not perfect, but it is faster. I suppose it is even possible to write your own native implementation linking to, for example, QT libraries or W32 libraries. Not portable, lot of work, but speed ensure.
Some people tend to forget: using a vitual machine inherently takes some performance, but that is the price to pay for excellent multi-platform support. Note that it's still is better to do test on all the platforms you want to support, but the implementation is done once. Especially when using applications (not applets, because of browsers (non)support ), mult-platform Java applications tend to work astonishingly well in my experience.

Re:You have the answer

[Andreas Rueckert]

Don't be so harsh. I moved from C++ to Java a few years ago and have no regrets. I use ArgoUML on a JDK 1.2.2, which is slow, compared to the JDK 1.3.1 on my other platform. Point is, that it's fast _enough_ to be very useful. Tons of problems, where Java might help to get a solution.

Re:You have the answer

[dda]

I've worked on several projects using the Java platform, where the portability was one of the the major issue.
I could also tell you that the major part of these applications were in a banking environment, where reliability and security were, of course, vital.
It included Threading, I/O , GUI, ...
The problem with Java is quite offen not the language itself, but the programmers which are not able to understand the basic
O.O. principles, and to keep the logic as simple as possible.
Furthermore, Java performances have been really improved since the version 1.0

Re:You have the answer

[tjansen]

And I still don't get why those people who insist on Java programming cannot see how screwed up Java is. Just look at any of the well-known Java projects (JUnit, the Jakarta stuff) and watch how insane programming in Java is. "We don't have method pointers, so we use the method name and reflection". "We do not have preprocessors or macros, so we cut&paste the code and modify each copy a little bit". "We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need". "Lets make everything a bean, use reflection to access it and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"... I admit that C++ is harder to learn, just because of its pure size, but it really pays off because it contains so many features that are really make your life easier without using all the ugly cludges that the Java guys must do (unfortunately I am one of them and do this 8hrs/d).

Re:You have the answer

[Anonymous Coward]

Considering your low Slashdot ID, you must still be coding assembler on a PDP-10.... You know, there have been some evolutions since you began coding.

Re:You have the answer

[matzi11a]

((buy more Mhz) && (save on dev time) == save on cash)

Re:You have the answer

[dda]

Well, I have already worked on a project which was quite similar to the one explained in the problem we try to solve. I used C++, but the only difference with this project was that it had to run on a Windows environment ONLY. I don't want to begin explanations on pointers, inheritance and that kind of stuffs. It only seems to me you're an old school guy, for who it was too hard to leave the good old C to reach a full O.O. technology.

Re:You have the answer

[tbone1]

Unless the specs are that it is to be written in C/C++.

And this is all too common, I'm afraid. I once had to implement a massive, heavy-fines-for-errors project that needed to compare massive associative arrays in C instead of Perl. Why? Because the boss didn't like Perl.

Re:You have the answer

[jawtheshark]

Oh, yes....and C++ hasn't got his bizarre constructs? Ever seen projects with overuse and inconsistent use of templates? Hoplessly obscured and wicked #defines that change every second include file. Or triple/quadruply-inherited classes that don't make a real sense anymore?
Come on, every language has it's inherent problems....and guess what, that is because no language really is perfect.
You don't like introspection? Now, well, I don't use it often either but it is way more flexible to a pointer to method. How do you know what parameters that method use in the specific library that is around? In Java you can at least intercept the fact that a certain method exists or not and handle it accordingly...even perhaps offering a good alternative.
I used to program C++, and I liked it... I switched to Java because I found it interesting. Now perhaps it is time try switch back to C++ for some time and apply everything I learned about good OO.

It's all about bad programmers, not about bad languages.

Re:You have the answer

[statusbar]

Actually, no, but he DOES already have the answer.

QT 3.0 supplies everything he needs for platform independent sockets, threads as well as the gui. Serial port access is easy enough on both platforms to do yourself.

My only suggestion is to have a spare linux box with a cron job that checks out the latest sources from cvs, compiles, and emails you the error messages. Then he will be notified as soon as he checks in some sources that only compile on the lame VC++ compiler. I do that all the time and it is much easier to fix the portability problems as you go instead of in one big chunk at the end.

--jeff

Re:You have the answer

[Anonymous Coward]

Well, indeed I began with ASM , but only on 80X86 P and just for one year, the time to understand how it works in a low level. Then I started C and noticed how the procedural code could be good ( not the spaghetti one :)) . Later, I noticed a lack in what I was doing, it was something we could call a class, a principle in fact, because you know you can reach a quite good level of OO emulation in C just using structs of pointers. Anyway, the time of C++ was good, my unix platforms were really happy. Then arrived the time of the maturity : a full O.O. platform .. waw !. It was called Java. Nevertheless, all of these language have still their places. I just explained which one was the best here.

Re:You have the answer

[tjansen]

I don't say that it is impossible to write bad code in C++.
I say that Java when using Java you have the choice of either writing ugly or redundant and error-prone code.

Re:You have the answer

[vstanescu]

I had some problems when writing a monitoring application in Java that had to run 24/7/365, because of some strange memory leaks in thread creation, that were causing the JVM to allocate about 500Mb in memory in two days. Finally i solved it by keeping the threads and reusing them instead of starting new ones when needed. There was no problem with my code (referenced objects or so on), the only fault was GC's. So i decided that this was not a good job for java, my C++ rewrite runs fine without a halt since february.

Re:You have the answer

[tjansen]

No, actually I was a writing Java full time for over 3 years before coming to that conclusion. There are so many things that I cannot express in Java without being redundant which always annoyed me. I didn't have any significant experience in C++ (or any other OO language) before.

Re:You have the answer

[jawtheshark]

Bizarre...we are working here on a Java based e-banking application and our Bugzilla has been empty for three weeks, despite testers turning our application inside out.

Actually I think the code looks elegant most of the time, and the error-handling is very robust. It just looks to me that you never saw good Java code. I'm sorry for you, you missed something :-)

Re:You have the answer

[Anonymous Coward]

Why is it that every time someone mentions a project that is to be done in C++ (the CUSTOMER wants it that way!) some idiot comes along and without even asking if there might be reasons for C++ says, 'Use Java'. Bleh! Don't you have some applet to write ? Go away!

Re:You have the answer

[dda]

"Ideal libraries would be open source and free, though those aren't as important as tested/stable/reliable. What are your recommendations? Anyone have experience writing for multiple platforms at once with threading, serial I/O, and network I/O all in mind? The ideal scenario would be to recompile on the new platform without changing a line of code - will this type of portability be possible?"
I though that was the main point.
He's trying to find a solution,I just wanted to share my experience.

Re:You have the answer

[animaal]

You're comparing apples and oranges.

"We don't have method pointers, so we use the method name and reflection"

In C/C++, retrieving a function from a (previously unseen) DLL requires a method name too. In Java, reflection does this. However, once you have the method, Java can pass a reference to it around using the Method object, whereas C++ passes a function pointer.

"We do not have preprocessors or macros, so we cut&paste the code and modify each copy a little bit"

Preprocessors and macros are generally a bad thing. They are effectively cut-and-paste at compile time, and they are a pain at debug time. There are usually better ways to achieve the same thing, in both C++ and Java.

"We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need"

That is either a gross generalisation, or a bad understanding of design. Java allows objects to contain static methods, which can be invoked from anywhere else, without instantiating the object that contains the static object.

"Lets make everything a bean, use reflection to access it and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"

This is a criticism of bad Java programmers using an object-based technology. You could as easily say "Lets make everything a COM object, and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"

Java and C++ are separate technologies, with different strengths. You wouldn't write Quake3 in Java, and you'd have trouble writing a cross-platform, easily deployable, non-memory-leaking business application in C++.

People who cannot understand a technology will do stupid things with it. This applies to both C++ and Java. The difference seems to be that mediocre developers have had more time to become decent C++ programmers than they've had to become decent Java programmers (since Java is newer). Good developers keep an open mind, and decide on a project-by-project basis what the most suitable language/technology is.

Re:You have the answer

[joerg]

Of course, there are some deficiencies in java, but your arguments are pure nonsense:

"We don't have method pointers, so we use the method name and reflection".
We use pointers (yes, there are sort of pointers in java) to objects, and invoke methods on the pointed-to objects. reflection is used for other purposes.

"We do not have preprocessors or macros, so we cut&paste the code and modify each copy a little bit".
We have constants for that (final static ...).

"We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need".
I don understand your point here!

"Lets make everything a bean, use reflection to access it and separate the code in 5 layers - ok, we write 10 times the code of a simple solution, but look how easy it is to do this change"
What is your point here? The Bean pattern is useful but not for everything. Reflection is used for examining objects of unknown origin. It is generally not used for method invocation. Nobody does. Separation of code into layers has to do with architecture and could as well be applied to C++. For some projects it is really useful.

Re:You have the answer

[tjansen]

In C/C++, retrieving a function from a (previously unseen) DLL requires a method name too. In Java, reflection does this. However, once you have the method, Java can pass a reference to it around using the Method object, whereas C++ passes a function pointer.

Just look at the APIs of, for example, JUnit. Because they want to avoid creating a single class for each method they start messing around with method names. Many users of beans do similar things, for example the Jakarta Beanutils and Struts that uses it.

Preprocessors and macros are generally a bad thing. They are effectively cut-and-paste at compile time, and they are a pain at debug time.


Actually I wanted to say "Preprocessors and templates". I think that proeprocessors are very useful though, but more for initialization and testing. It is often much easier to write a few macros than to design you own file (/XML/etc) format to describe something, at least if the data is known to be stable.

That is either a gross generalisation, or a badunderstanding of design. Java allows objects to contain static methods, which can be invoked from anywhere else, without instantiating the object that contains the static object.

You can excplicitly see this in JUnit, they are to lazy to write Assert.assertTrue(), so they let the TestCase class inherit from Assert. There is no other relationship between those classes.

Re:You have the answer

[tjansen]

We use pointers (yes, there are sort of pointers in java) to objects, and invoke methods on the pointed-to objects. reflection is used for other purposes.
Many APIs use reflection as a convenient replacement for the lack of method pointers - it is so much easier to use a method name and a object reference than creating a new (inner) class for each method.

"We are too lazy to write the long static method invocations, so we just inherit from the class that contains the methods that we need".
I don understand your point here!
That there are people who are fed up with writing Classname.methodname for each invocation of a static method so they use inheritance to get rid of it.
You either have to write 20 or more characters for each invocation, which can make complicated code unreadable and is annoying to type, or you write wrappers for each static method in your own class, or you inherit from the class that is providing the static methods.

What is your point here? The Bean pattern is useful but not for everything. Reflection is used for examining objects of unknown origin. It is generally not used for method invocation. Nobody does.
Actually many people do this, because it is by far the most convenient solution for many problems. Just look at the Jakarta stuff.

Re:You have the answer

[jwarwick816]

We developed a large desktop application in Java and had horrible performance results. We have now switched to Qt 3.0, which gives you network and thread support. I agree that you'll probably have to do serial port stuff on your own.

Re:You have the answer

[fredrik70]

Just a short Q: what VM was that???
Did you ever consider switching to another VM?

Re:You have the answer

[spooge21]

If I could mod your comment as a Troll I would. You state "Face the truth, java is a cripled language for lots of reasons" without giving any details to back that statement up.

Why is Java crippled? Because it has a feature-rich cross-platform standard API? Because it has built in multi-threading? Because it makes writing network code a snap? Because Sun actively supports it and listens to developer requests through the Java Community Process? Because it has modern JIT compilers and HotSpot which makes its runtime speed more then acceptable? Because it has a large number of useful APIs provided by open source developers such as myself?

Please, don't spread the FUD.

Re:You have the answer

[sbrown123]

Redundant? You mean simple? Yes, we can't have programming languages that make our lifes as developers simple. And lets write the most complicated code possible and let someone else maintain it.

Ugly? If you are comparing it to C, its like comparing apples to apples. They use the same structure and style!

Error prone? Try creating a memory leak or mishandle a pointer in Java. What? You cant do that in Java? You mean the two largest causes of bugs dont exist in Java? And it comes with exception handling? Oh my!!!

I program in both languages. C is nice for speed and raw power. But if I wanted a robust, cross platform, and error handled code (not free of bugs, but these bugs are not caused by Java but generally by us error prone humans) I would turn to Java. I have also been a huge fan of Java-C cross usage (many purist Java programmers may leave me here) using JNI and GCC (MingGw for Windows). That gives me a best-of-breed approach, power of C with the scalability and control of Java. I love these two in concert!!

Re:You have the answer

[tjansen]

Redundant & ugly?
Redundant means that because of the lack of function templates, method pointers, macros and multiple inheritance (or an equivalent) you constantly create code similar to existent code. Java forces you to do cut&paste programming, which is ugly. If you have two functions that are very similar, but differ in one or two subtle details (different datatypes, call different methods) you have to write them twice. If you find a bug in the first you must correct it in the second implementation, too.
It also hurts re-use. Re-use of algorithms is very complicated in Java. Even in simple cases, like sorting an array of integers/floats, it is not possible in Java unless you wrap everything in objects. Just compare the Java collection classes to the STL.
Redundancy is IMHO a more dangerous source of errors than memory leaks. Memory leaks are avoidable, because they are usually only a sign of a bad design. In a good C++ design you should avoid heap allocations, if you don't cant you still have smart pointers, and if you cannot use them you should create a simple but strict policy for memory management. Java's design flaws make classical human errors likely. Small errors that were made while doing copy&paste stuff, subtle errors in algorithms because you have to implement them over&over again, errors in resource deallocation when an exception occurs because the code paths of exceptions are hard to follow.

Re:You have the answer

[Anonymous Coward]

Umm, you *do* realize that Java garbage collection isn't a magical mystical fix-it-all? Chances are, there were still references being held to old objects somewhere - GUI applications in particular end up with these problems since programmers tend to act like AWT and SWING have no side-effects of their own. (i.e. "there were still references being held to old objects somewhere" see above ;-)

Re:You have the answer

[JumboMessiah]

I used to work at a large mortgage company here in the U.S. About a year ago, they scrapped a customer workbench application that was (to that development point) written in java. The reason being is that the cost of replacing every agent PC (over a 1000 of them) with faster processors and more RAM was too cost prohibiting. The agent PCs at the time were midrange PII's (333's and up) with 64MB of ram. The decision was made after doing numerous tests with the agents testing the application and recording their response to it. Agents were frustrated with the lack of response from the application (which is vital when your on the phone with a customer). From the test, they determined that to attain the performance required, they'd have to retrofit the agent PCs to at least PIII-650 with 256MB of ram. This workbench app is a very large application. From that point, development switched to VC++ to keep the vested cost they already had in their agent setups.

Re:You have the answer

[kelzer]

Many APIs use reflection as a convenient replacement for the lack of method pointers - it is so much easier to use a method name and a object reference than creating a new (inner) class for each method.

So let's add pointers to Java? And while we're at it, let's add multiple inheritance, operator overloading, a macro preprocessor, etc., and end up with a slower version of C++. And then we can address the slowness by getting rid of the JVM and compiling to native machine code. Of course, we'll have to add a sizeof operator, and fill our headers will lot's of #ifdef I386 macros, but that's OK, because then Java would be almost as good as C++.

Pointers don't exist in Java for a reason. Are pointers evil? Of course not, they're great! But they have some serious drawbacks, so Java chose to avoid them to improve stability and security.

That there are people who are fed up with writing Classname.methodname for each invocation of a static method so they use inheritance to get rid of it.

You either have to write 20 or more characters for each invocation, which can make complicated code unreadable and is annoying to type, or you write wrappers for each static method in your own class, or you inherit from the class that is providing the static methods.

Many would argue that forcing the programmer to put the explicit "class.method()" instead of just "method()" in their code makes it clearer to later maintainers exactly what's being called.

And Martin Fowler would argue that if the code is that complicated, you need to do some refactoring!

Just look at the Jakarta stuff.

Which Jakarta stuff? There are over 20 distinct projects. Most of them are very, very good. Ant is gaining a lot of momentum and is being included with many new open source projects. The same can be said of Struts, and Velocity is a very important component of ArgoUML. And we all know that Tomcat, with version 4.0, has evolved into a very good quality JSP/Servlet platform.

Re:You have the answer

[Anonymous Coward]

> We use pointers (yes, there are sort of
> pointers in java) to objects, and invoke
> methods on the pointed-to objects

But can you have pointers to methods? I don't think that's supported...nor templates - hey, let's do a C-style cast from Object and lose all typesafety! No operator overloading...gotta love good ol' String.equals()!

Re:You have the answer

[bug1]

I didnt give a reason as i didnt think i would be questioned.

Its interpreted.. or rather run time compiled, call it what you will it will _never_ be as fast as c.

It requires a virtual machine, so it will always be more bloated than c.

As the "portability" that you and others in this thread mention, gcc is portable. if you want portable code dont make it closed source.

There are "feature-rich" libraries that can be linked to in c also.

Java's only good point is its easy to program in, its the modern day equivalent of basic, or visual basic. Once you become a more advanced programmer, the benefit of being easy to programming in is of reduced benefit.

Sun will never let java be really free.. they want to control it just as badly as any other large mega-corporation would, its just about money for them.

Re:You have the answer

[Anonymous Coward]

As the "portability" that you and others in this thread mention, gcc is portable. if you want portable code dont make it closed source.

Portability has nothing to do with the open-ness of the source. Quit posting stupid stuff, TIA!

--
Anon #42

Re:You have the answer

[vulg4r_m0nk]

Fucking Christ ...

Are you aware that Java can be compiled to native code giving it damn near equivalent performance to C++?

Are you aware that you can run c code from within a Java app?

Are you aware that hardware is goddamn cheap and the 'bloat' from a VM is dwarfed in comparison to a powerful box?

And it's worth noting as well that Java is often easier to program in not b/c of the much cited absence of pointers, but b/c it's a well-organized language unlike so many others.

Re:You have the answer

[Novus]

Oh dear. What a load of FUD. I hope I'm not feeding a troll here.

Its interpreted.. or rather run time compiled, call it what you will it will _never_ be as fast as c.

Just-in-time compilation is roughly equivalent to compiling, then executing; this is hardly an uncommon scenario with C programs, is it?

It requires a virtual machine, so it will always be more bloated than c.

Again, this is untrue. Java can easily be compiled to native code.

As the "portability" that you and others in this thread mention, gcc is portable. if you want portable code dont make it closed source.

Closed source is admittedly harded to port, but GCC isn't enough to provide a homogenous environment. E.g. GUI libraries vary a lot between e.g. Windows, Unix and Mac. These are highly cross-platform in Java.

There are "feature-rich" libraries that can be linked to in c also.

This part is quite true. However, the standard Java libraries are more feature-rich than the corresponding standard C libraries.

Java's only good point is its easy to program in, its the modern day equivalent of basic, or visual basic. Once you become a more advanced programmer, the benefit of being easy to programming in is of reduced benefit.

Ease of use is an advantage to experienced programmers, too (as anyone who's spent ages chasing memory leaks can attest)!

Sun will never let java be really free.. they want to control it just as badly as any other large mega-corporation would, its just about money for them.

Actually, considering the existence of third-party implementations like Kaffe, Sun probably can't close Java completely even if they want to!

Re:You have the answer

[bug1]

I interpret your points about speed and size as meaning its not much worse than c, but it is still worse.

Graphics libraries are worse than any other type of library as far as portability goes, there are a few about, but i conceed a point there.

Sun will always own the name rights to Java, so i imagine they could easly and swiftly force kaffe to no longer use the Java trademark in relation to their product.
They could make it very difficult for anyone to make a java compiler without their blessing, as they have done to MS. (which strikes me as poetic justice)

Re:You have the answer

[Anonymous Coward]

> Its interpreted.. or rather run time compiled, call it what you will it will _never_ be as fast as c.

And C will never be as fast as assembler. What's
your point? Why aren't you writing your apps in
assembler - it is faster and can do everything C
can.

> It requires a virtual machine, so it will always be more bloated than c.

ditto.

> Java's only good point is its easy to program in, its the modern day equivalent of basic, or visual basic. Once you become a more advanced programmer, the benefit of being easy to programming in is of reduced benefit.

So presumably you're still programming in assembler then?

I'm afraid you don't seem to have a point.

Re:You have the answer

[RetroGeek]

I hope you are not basing your dislike of Java just on JUnit.

Because CUnit is even worse. If you want/need to add an extra test, you must re-compile/link your application before you can run the test. So in effect the test bed becomes part of your application.

In Java and JUnit, the JUnit part is separate from your application. It simply instantiates the classes from a .JAR file (or however you have set it up). Then, if everything works correctly, you can send your app to integration testing without changing one line. In CUnit, you must at the very least change which libraries are linked in, or change #defines to exclude the test code, then re-compile/link your app again. And if you have a memory leak, then just the fact that you have different code between your test app and your production app can change where the leak manifests itself. That is if your test code does not its own memory leak.

I have worked in both C, C++, and Java (and many more languages, but that's a different thread) and I vastly prefer Java. I too miss pointers and #defines, but in reality when I am looking at code written by someone else or code I wrote a year ago, give me Java every time. The minor performance difference (in the order of micro-seconds) is a small price to pay (server side).

As for the GUI, IBM has created a FAST set of classes for their new Workbench called Ecplise.

Re:You have the answer

[MillionthMonkey]

Why is it that every time someone mentions a project that is to be done in C++ (the CUSTOMER wants it that way!) some idiot comes along and without even asking if there might be reasons for C++ says, 'Use Java'. Bleh! Don't you have some applet to write ? Go away!
Yes, but customers can be stupid. They want things written in languages that they saw an article about in their latest management newsletters. Or they demand web pages that have the look and feel of Windows applications (which needlessly introduces mind-rotting amounts of JavaScript). Some customers have valid reasons for wanting a specific language or technology. Some are just demanding the latest fad. You can't let a customer dictate your technical decisions on what is the best tool for a specific job. Would you want your doctor to only prescribe you the drugs you saw commercials for on TV?
We wrote a scientific application suite in Java because almost half our customers insisted on using Macs. The other half wanted it to run on Windows. And a few wanted to run it on Linux. People complain that Java is slow for stuff like that, and it is if you don't pay attention to what you're writing, but a good programmer can put together an efficient algorithm without too much trouble. Java has worked out quite well for us.

Re:You have the answer

[Anonymous Coward]

If you want to use C++, check out the ACE libraries. They are free, robust, and cross platform. http://www.cs.wustl.edu/~schmidt/ACE.html

Re:You have the answer

[Spy Hunter]

Once you become a more advanced programmer, the benefit of being easy to programming in is of reduced benefit.

Uh... what? You can code faster, with fewer errors, and get more done! I don't think the benefits decrease at all.

Re:You have the answer

[Anonymous Coward]

Java programmers always think the customer is stupid - because the Java programmers always think they know better. Nevermind that the Java solution is slow enough to bring tears to your eyes. Java programmers DO KNOW one thing however - that's how to say "Java"! Java Java Java Java Java - why don't we use Java Java Java Java Java Java! Did I mention Java!? Java Java Java! Hooray for Java!

Re:You have the answer

[MrBoring]

I think the troll moderation is undeserved. The C++ vs Java comparison may be slanted, but at least has justifications to back up the opinion.

Before you think Java is fast enough, just run Ant on a large project. It's either slow because it's based on XML or slow because it's Java, or both. Yet, it is powerful, and has some elegance to it.

Also, to the Java crowd--Don't forget the original post said, C++. Convincing someone to use a different language and/or platform is something of a skill aside from programming, and might not be possible. This is a business issue, not a technical one.

Re:You have the answer

[Jonathan C. Patschke]

Redundant? You mean simple?

Odd spell-checker you have there. Here's a test for you: Design a system of objects that contain at least two independent characteristics (say, for example, in a MOO, an object can either be enterable (like a room or a bag), and carryable (like a sword)). Now, implement it in such a way that a class can have any subset of those characteristics. Hmm... that'd be pretty easy with multiple-inheritance. Since you're doing the exact same thing on each object, you could just inherit an object that implements that characteristic. However, you can't do that in Java, so you're stuck implementing (key word here) the interface on each class (since, remember, any class may have any subset of characteristics, so you can't rely on direct inheritance). Thus, redundant code. Even if you use the visitor pattern, you're still reimplementing the visitor boilerplate in each class, instead of just an inheritance clause. I suppose you could implement each feature as a bean, and the define each dynamically, but your constructors would all look differently, and it would be a bitch to fix if you ever needed to change the bean-interface.

Try creating a memory leak or mishandle a pointer in Java. What? You cant do that in Java?

Try using Swing and Java3D (or any other JNI-based library) in the same application. Then, try loading a huge (at least 128 megabyte) dataset into the application in such a way that the data need travel over the JNI link. That's right, using only Sun-supplied code, you too can completely bomb your application in portable ways under Windows NT, IRIX, and Solaris! It seems that Java GCs large objects in such a way that pointers drift while the JNI-linked libraries need them to be fixed. Java is not a panacea. I'd say that something like Qt (combined with the STL) is much closer to what the original poster was looking for. It's portable, it's C++, which is what the poster was asking for, and it's far more scalable for a desktop app.

Re:You have the answer

[FatherOfONe]

I generally like the best tool for the job, but in this case he has a point. Java does make a lot of sense. However you statement about "slow enough to bring tears to your eyes" is ignorant.

I will argue that 99% of the business applications out there could easily be written in Java, by good coders and perform as well or better than C or C++ code.

Lastly, I am a little confused about you rant. Do you want coders to be lathargic COBOL coders, who don't give a rats ass about anything, or do you want people who are excited about a language?

Re:You have the answer

[Computer suck!]

and then you have cross compilers fro java (java to native exe/bin).

Re:You have the answer

[Anonymous Coward]

In this case, the old canard 'It is the poor carpenter who blames his tools' comes to mind.

Never cut and paste code. Factor common code into service methods. Duh.

If you are using method pointers or reflection, you probably screwed up your design, unless you are dynamically updating the code, either from your end, or allowing the user to do so, or interacting with user-generated code in some way.
If you designed in C-style with method pointers and then hacked that design for java, you should hire a lead developer.

If you don't like java, and refuse to do anything other than find hacks to write java code in C style, get another job. Alternately, learn some more about how nice java is for designing systems of simple parts for performing complex tasks, and enjoy work. Your choice.

Re:You have the answer

[bug1]

When your an advanced programmer you make less mistakes, you shouldnt be confused by syntax, you should be using programs that help you to track down the nasty errors (try dmalloc)

Re:You have the answer

[bug1]

I dont use assembler because its not portable at all, where as C was designed to be portable, its only the external libraries that may not be portable.

C is the ideal all round programming language

Re:You have the answer

[Screaming Lunatic]

Turing test time:

A program written in C++ can be written in Java. Both languages are complete.

However...

Java is not OO complete. There's a subtle difference there. No multiple inheritence, no operator overloading. Sure these features may be "dangerous", but let the programmer make the decision, not the language.

Poor floating point support. Check this paper.

Not to mention the virtual machine being inherently slow.

The fact that Java is proprietary language controlled by Sun.

These are the reasons to sway you from Java (if they are important in producing your application). Not some silly Java sucks argument. If you can live with the above. Go for it.

Re:You have the answer

[Novus]

I interpret your points about speed and size as meaning its not much worse than c, but it is still worse.

Quite so. C does have the edge in speed; stuff like array index bounds checking, garbage collection, et.c. slow Java down a bit, but not nearly as badly when the Java code is compiled instead of interpreted.

Sun will always own the name rights to Java, so i imagine they could easly and swiftly force kaffe to no longer use the Java trademark in relation to their product. They could make it very difficult for anyone to make a java compiler without their blessing, as they have done to MS. (which strikes me as poetic justice)

So they call it something else. The Mesa project has a similar problem with the name OpenGL, but that doesn't seem to diminish their popularity.

Re:You have the answer

[erc]

Yes, but customers can be stupid. They want things written in languages that they saw an article about in their latest management newsletters. [...] Some customers have valid reasons for wanting a specific language or technology. Some are just demanding the latest fad.

Oh ... you mean, like Java?

C/C++ is inherently more portable than Java, runs a *lot* faster, is more mature, and has far less overhead.

The overwhelming problem that I have seen with Java is that developers tend to want the latest releases of stuff every time they change an app, fogetting (or not caring) that when you add features to an app that are in an updated library, every customer has to be upgraded - not with just the individual app, but with every library! Most Java programmers I've known tend to be inexperienced - rather than implement simple functionality their code, they lobby for upgrading. Bad for the customer, and the Java programmers learn nothing.

Re:You have the answer

[sbrown123]

>>Here's a test for you:
>> object can either be enterable (like a room or a bag), and carryable (like a sword)).

Yes, I see a need for enterable rooms that can be carried. Java being incapable of such odd functionality must be a defect! :)

Seriously, multiple inheritence is up there with "Goto" functions and labeled bad programming practice. Stop the evil. Java does have interfaces that are safer.

>>Swing and Java3D (or any other JNI-based
library)

Neither Swing nor Java3D are JNI based libraries.

>>Then, try loading a huge (at least 128 megabyte) dataset

Why in the hell would you want to send a 128 M dataset to a JNI function? Break up your functionality (aka use more than one function). I did not wake up this morning and decide to eat breakfast, lunch, and dinner just to get it all done in one step. Streaming is another common, and very safe way to handle large amounts of data. Streaming is fully supported in Java. I believe, though I have not tried it, use C++ streams to Java streams and vise versa.

Java is not a panacea. But its great for cross platform development. As for Qt, I do not believe there was mention of a need for windowing.

Re:You have the answer

[big_hairy_mama]

I don't mean to be rude, since you are obviously already aware of my point. But who cares if the build system is slow? I could argue that all the milliseconds spent waiting for the slower build would easily be exceeded by the time spent writing and maintaining cryptic Makefiles for each new component that is added to the project. In fact, I could use this same argument for many other aspects of programming, in general, in Java.

Lesson learned: never mention C++ and Java in the same paragraph on Slashdot! :)

A little known library is SFL

[Hougaard]

From www.imatix.com (The makers of the Xitami webserver).

SFL is a great library for doing portable low-level stuff such as network etc..

Re:A little known library is SFL

[Cratylus]

Another great library is Bristol Wind/U which allows you to use the Win32 API and MFC on many flavors of unix. Since you are developing on NT first, this seems like the ideal solution.

GNU Compiler + CommonC++

[lkaos]

The GNU Compiler (gcc/g++) runs on so many platforms so it should solve a lot of portability issues. CommonC++ is a GNU library for threading and I also believe it can handle network IO.

Now, I always heard that NT is supposedly Posix compliant so it might not be terribly difficult...

Re:GNU Compiler + CommonC++

[dyfet]

GNU Common C++ certainly does abstract network I/O (sockets) as well as threads, serial I/O, XML parsing, and logging. There is also a supplimental RTP stack for it (ccRTP). It compiles native under win32 as well as under posix targets. It recently has had a very extensive rewrite, and is still recovering from that.

Re:GNU Compiler + CommonC++

[Anonymous Coward]

the reading that I've done on posix NT points to the problem that the posix implementation isn't complete.

I've done a Macintosh and Windows coding at the same time in the same file. (Hey! this was in the late 80's) Your main code calls an interface API which calls the correct API on the platform that you are currently working on. That's how I've hidden the windowing code from the main program.

YMMV

Re:GNU Compiler + CommonC++

[Anonymous Coward]

Only NT's POSIX subsystem is POSIX compliant, not the Win32 subsystem, which is used in 99.99999999 percent of all cases. AFAIK both the POSIX and the OS/2 subsystem have been abandoned for XP. So NT's POSIX subsystem, being a fig leaf all the time, is probably no choice for the future.

Re:GNU Compiler + CommonC++

[Anonymous Coward]

The "Posix compliance" is stuff that was in the NT3.x & NT4.x Resource Kits, essentially a big chunk of libraries and .exes that provided Posix functionality. Not really standard issue. Not sure if it's even in Win2000, but that's what CygWin and U/Win are for now.

I'd go with QT3 or someother, just to avoid having to write Win32 code and non-Win32 code.
Or leverage Cygwin or U/Win so you can have common code base.

Re:GNU Compiler + CommonC++

[agentk]

I was going to use Common C++ for something, but never got around to it.

here is a link: http://www.gnu.org/software/commonc++/CommonC++.ht ml

here is another: http://sourceforge.net/projects/cplusplus/

I have used wxWindows for simple cross-platform GUI stuff, and it works pretty well. wx is basically an abstract GUI toolkit, which wraps around various native toolkits like GTK, Windows, Mac, (even Motif).

It's pretty cool, though QT might have some more advanced features or be faster.

Re:GNU Compiler + CommonC++

[Anonymous Coward]

The built-in POSIX subsystem has effective been replaced by Microsoft Interix ($99/seat).

Before MS bought this up, it was fully POSIX/Single UNIX certified.

Problem is MS is selling it as a migration tool instead of a compatibility tool, so buyer beware.

Re:GNU Compiler + CommonC++

[faboo]

As some have said, NT does supposedly have a "posix subsystem," but never in any documentation of have I seen an explaination of what that means to the developer. You don't have access to posix functionality (using MS libraries), such as pthreads and standard *nix stuff.
OTOH, it is fairly simple to wrap alot of win32 stuff with a posix looking layer, but in many cases you loose functionality along the way.

faboo

Re:GNU Compiler + CommonC++

[Earlybird]

NT's POSIX subsystem is for running POSIX.1 binaries. Access to this subsystem is not provided to Win32 executables, which run under the Win32 subsystem.

Since the two are completely isolated from each other, POSIX programs cannot make use of common Win32 services like networking, graphics, DCOM etc. All subsystems are implemented on top of the native, undocumented NT APIs (ntdll.dll).

Similarly, NT has an OS/2 subsystem which is capable of running OS/2 console programs. The original idea was that NT could expose different, swappable "personalities", of which Win32 is but one, but of course that potential has never been realized.

For more information, see Understanding Windows NT POSIX Compatibility.

Re:GNU Compiler + CommonC++

[Amerist]

I'm glad to see that someone mentioned this project!

I have been using the GNU CommonC++ Libraries myself in some multithreaded internet apps that use both TCP and UDP for communication. For my first test project I implmented an extremely simple HTTP-like service and it ran beautifully.

The code is broken up into classes, well documented, and they're always developing it and making bug fixes. I was impressed the first time that I found it and would recommend it highly to anyone who wants to do both Networking I/O and Threading with one library.

Better, the CommonC++ Libraries also compile for Windows environments, meaning that they're pretty close to being extremely cross-platform already.

Amerist.

ACE ADAPTIVE Communication Environment

[n-tone]

ACE is an open-source framework that provides many components and patterns for developing high-performance, distributed real-time and embedded systems. ACE provides powerful, yet efficient abstractions for sockets, demultiplexing loops, threads, synchronization primitives.
I've never tested this framework but it seems very good. I know several companies which use it and which are happy with it.

Re:ACE ADAPTIVE Communication Environment

[dkixk]

I'll second the recommendation of ACE. In addition to ACE, The ACE ORB (TAO), Zen, their real-time ORB, and Jaws, An Application Framework for High Performance Web Systems, are all worth a look. This stuff has been around for quite some time and has been ported to nearly every compiler-platform imaginable.

Re:ACE ADAPTIVE Communication Environment

[Anonymous Coward]

Hmm, I see two people recommending ACE, let me just add a vote against it. Before you decide on using it, go to the web page and read the documentation VERY thorougly. If you find it, that is. Seems most of the stuff just ran off some doc-tool that just threw together every other class declaration found. And there is little structure in (some parts of) that lib to begin with! I used ACE in some contract work, let me just say I didn't like it. I'd recommend looking at the ObjectSpace toolkits. These are not exactly cheap but depending on the project it might be worth it.

Re:ACE ADAPTIVE Communication Environment

[Anonymous Coward]

Don't listen to this guy. ACE is one of the best documented libraries around. There are countless white papers about it, dozens of articles, tutorials, and so on. Check it out for yourself: http://www.cs.wustl.edu/~schmidt/ACE-documentation .html

Further, the POSA2 book (http://www.cs.wustl.edu/~schmidt/POSA/) is over 600 pages of excruciating detail of the design patterns implemented in ACE. It's a fantastic book, and studying it will teach ACE.

If that's not enough, Stroustrup's "C++ In Depth" series will soon be publishing a book dedicated to ACE, written by Doug Schmidt schmidt himself. (Doug Schmidt was editor of the C++ Report for several years, and is one of the true C++ Gurus of our generation.)

The generated documentation that this guy was referring to was done with the DOxygen tool, an excellent cross reference and interface documentation generation tool, including graphical relationships between the classes and interfaces.

Whatever the documentation lacks, the answers are still there because the full source code is available. I've never found a library as good as ACE. We use it extremely heavily for all our networking code, and it runs very efficiently and easily ports between Windows NT and Linux (using Borland C++ and g++.)

Re:ACE ADAPTIVE Communication Environment

[Anonymous Coward]

I've used ACE for several years, on patforms including win95, win98, win200, NT4.0, linux 2.2, Solaris 2.6, 2.7, 2.8 and linux 2.4. It is very good, and the product's I've written worked across all those platforms, and more. It is the best C++ library, it and TAO, I think that you get can today; in any market - free or comericial. I would argue that it is more portable than Java, take a look at all the plaforms it runs on.

Re:ACE ADAPTIVE Communication Environment

[Anonymous Coward]

Hmmm, try the book: Pattern-Oriented Software Architecture, vol 2. Also, there are _lots_ of C++ report articles, examples, Usenix papers and two other books that are comming out about how to use ACE/TAO. I would argue the opposite; that there is more documentation and support, via the excellent news group that they have, than anything you can get anywhere! ( Well, almost! :-) The Java website at Sun is excellent!)

Re:ACE ADAPTIVE Communication Environment

[ckaminski]

I will also second this recommendation. I have been using ACE professionally since late 1997. At that time TAO was a bit rough around the edges, so we used OmniORB from ORL instead http://www.uk.research.att.com. Oh yeah, and I had to use Rogue Wave's DBTools.h++ or whatever that Piece 'O Crap is called.

All linked with ACE and it's amazingly simple Socket libraries. Oh, on Windows and Solaris (Linux wasn't a big deal back then).

I've also built POP3 clients, SMTP servers, and dozens of other small utilities. I've altered it, extended it, and converted others to the cause. I contend that it beats Rogue Wave hands down http://www.roguewave.com.

And you can't beat the price or the license.

With the newgroups support, and all the documentation mentioned by others, plus commercial support from http://www.riverace.com, I challenge you to find a more thoroughly tested C++ crossplatform library.

Just my 2bits.
-Chris Kaminski

Re:ACE ADAPTIVE Communication Environment

[irix]

I (and my company) also use this library extensively in a number of C++ projects to do multithreading, socket communications and memory maps, just to name a few things.

It is open source, so it has the advantage that you can fix or patch bugs easily, and extend it if you want to.

Even if you don't use the cross-platform part of ACE a lot, the C++ abstractions for some common UNIX paradigms are great to have - for example you can turn a class into a thread, etc.

Re:ACE ADAPTIVE Communication Environment

[Anonymous Coward]

ACE rules. I recently helped implement a prototype server that did had an abstracted transport layer (it's using pseudo XML/RPC for now). Python test client and server in like 30hrs.

And it's currently being ported to Windows.

ACE is the best pattern implementation I've ever seen, and is one of those tools that actually BOOSTS productivity.

Re:ACE ADAPTIVE Communication Environment

[aminorex]

ACE is great if you don't care about bloat, and
you are willing to conform all of your code to
the set of patterns chosen by the ACE authors.
But it is so rife with interlocking patterns that
it is very difficult to subset ACE in practice.
Don't open that door unless you've got room for
the whole damn elephant.

Re:ACE ADAPTIVE Communication Environment

[Anonymous Coward]

An executable we had that used ACE was 50 Megs. Can you say 'template bloat'?

Re:ACE ADAPTIVE Communication Environment

[Anonymous Coward]

I've used both ACE and ObjectSpace. ObjectSpace C++ Toolkit is not going to be enough on the I/O side, and sometimes the threading aspects of it aren't very robust - ObjectSpace's C++ Toolkit support is limited also; ObjectSpace has basically moved into the Java space. We have the whole code for ObjectSpace's C++ Toolkit, and we have to fix their bugs ourselves.
ACE on the other hand is being supported and it's quite robust - TAO wasn't quite that good, it had some bugs when I used it, but that was a year ago; from my experience, if you're using CORBA find a different implementation. I love coding with patterns and I really like ACE - but if you don't know the patterns, you might not be able to appreciate some of the things ACE offers or is built on: Singletons, Reactors, Observers, etc. The learning curve for ACE is a little steep, and the documentation is not that great, but Doug Schmidt (the creator) was supposed to be coming out with a book though, and that should help. ACE, in my opinion is a better solution than ObjectSpace's C++ Toolkit - going from your description. Oh, and using just plain gcc won't get you anywhere - unless you're writing code to output "Hello, World." So, don't listen to all the college freshmen and high schoolers that suggested that.

Just use the gcc, g++

[mandria]

i think there is a port for windows also of gcc and maybe g++ (not very sure).
you may wanna check this side right here(djgpp)

Re:Just use the gcc, g++

[Anonymous Coward]

Compiler? Library? Duh!

Actually GCC does now have a threading abstraction. But you didn't use capital GCC for 'Collection', "mandria", so you are stupid after all.

You'd want mingw or cygwin instead of djgpp anyway.

And g++ (or any of these ports) cannot develop against native Windows QT. Different C++ ABIs, you see.

Re:Just use the gcc, g++

[statusbar]

Correct, but there is another gotcha.

The current cygwin g++ compiler is not compiled itself with the appropriate flags to generate thread safe RTTI and exception handling code.

threads + cygwin + g++ + ::operator new = memory corruption and crashes

unless you use -fno-rtti -fno-exceptions

Yes, this sucks.

--jeff

Re:Just use the gcc, g++

[Anonymous Coward]

But cygwin is a kludge anyways. It's simulating a faux-Unix environment and isn't going to integrated well. However mingW32 is another gcc port to Windows which works natively from the command prompt (more like DJGPP but I've had MUCH less problems with it). With this you can compile the same C++ code no problem. Also there a GUI toolkits (V for sure, I think QT can be used with mingw32 as well) that allow virtually seamless transfer from Windows *nix. I've a few programs with V + mingw32 where to switch platforms you literally just change a line in the Makefile then recompile.

Re:Just use the gcc, g++

[statusbar]

Yes. One other gotcha with cygwin is that the cygwin DLL is licensed under the GPL - not the LGPL. So you can not distribute any closed source software that uses cygwin.

--jeff

You might consider Delphi and Klyix

[Anonymous Coward]

If it would be possible, this would be a natural for Boarland's Delphi & Kylix. Kylix compile Linux executables which will also run on the *BSDs. Delphi does Windows. With both, you write one code set and compile for the platform.

Question

[SimonK]

Do you have a compelling reason not to use Java in this case ? It would seem to provide everything you require.

Even just writing portable C++ code can be tricky, especially if one of the target platforms is Microsoft.

Re:Question

[lobsterGun]

If you're going to troll the java zealots you need to be a little more... low pressure. Lest they figure out that you're trolling. Instead of saying "tear off our faces with rusty spoons". Try "tear off our faces with clean spoons". Or even better "tear off our faces with spoons". The use of the adjective 'rusty' just pushes to post over the top.

Re:Question

[Anonymous Coward]

The general concensious however, is that Java advocates are so blinded by pure zealotry and blind faith, that they not only fail to notice major shortcomings and complete screw ups of their One True Language ("From elevators to nuclear power plants! JAVA SUITS ALL!"), but they also fail to notice the most blatent of trolls and flamebaits directed at them.

Potential trollers should also note that attempting to get a bite from a Java zealot is not easy. They're usually too busy off telling people that they should use Java instead of the language that they are currently using, and thus usually unavailable for comment.

Re:Question

[Anonymous Coward]

The Java GUI was deemed to be too slow for our needs. Also, the target machines did not have enough memory to run Java applications. Java programs we found required three times as much memory to run.

Re:Question

[SquierStrat]

While I'd agree for portability, Java is probably the best...especially since it technically won't require a recompile (although native code java compilers do exist...thank God) but speed without using a native-code compiler (which they probably won't since it'd kill the whole portability thing...however I do not know that for sure...i'm not to java savvy) will jsut utterly suck!

Re:Question

[lgraba]

After considering the many issues of portability, effeciency and development time

My experience has been that Java wins in terms of portability (MUCH better than C++ for anything that uses a library, as Java libraries are standard across platforms) and development time (big win here), and for efficiency, can probably hit 80% of speed for non-GUI code. It's always possible that there are requirements that you haven't told us about (like footprint, Java likely has a larger footprint), but I wouldn't dismiss Java as easily as you (or, apparently your customers) do.

Re:Question

[Anonymous Coward]

jesus christ you whiny bitches. the question asked for "cross platform libraries" and the original poster said "hey, java has those." it is therefore quite appropriate to investigate whether java would be an appropriate platform.

besides, if the person posting this "ask /." really needs help from slashdot just to find some cross platform i/o and threading libraries, he probably doesn't have the chutzpa to actually proceed to use them well. better he stick to the safe, warm, cozy land of java.

Re:Question

[ashpool7]

NCC's keep Java source code portable. You just have to recomplile; no biggie.

Re:Question

[Anonymous Coward]

The question also said "It will be written in C/C++.", so why the fuck are you lot telling him to change and use Java? Ever considered that neither him nor his brother has any experience with Java? Ever considered that the customer explitly requested a C/C++ solution? Ever consider that Java may not be the solution they want to use? Ever consider that Java is a toy language, and has never been used to write a large scale application? Ever consider your life to be a total waste of time and effort?

Re:Question

[Anonymous Coward]

Ever considered that neither him nor his brother has any experience with Java?

The question also said "I've never made it a point to code for 2 platforms at once in any language other than Java."

Perhaps the customer requested C/C++, it's likely that the customer also requested that the initial deployment is on NT. So, I think we can all draw our own conclusions there.

Besides, since they're still deciding between C and C++ the language issue is obviously still up for debate.

Re:Question

[Anonymous Coward]

Don't forget that Java can be compiled to native binaries. Although I would not assume that normal Java performance would be inadequate, especially with JDK 1.4, its nice to know that in a pinch, you can compile to native -- both on Windows and Unix. See TowerJ and GCJ and Jove among others.

Re:Question

[Anonymous Coward]

You want to investigate using SWT toolkit from IBM's Eclipse project. It is a native widget binding for Java applications. On Unix its Motif (with GTK port in the works) and on Windows it is native code. I haven't tried the Ecipse gui yet, but I'm told it is as fast as native C++ applications.

Re:Question

[ab315]

For total portability and ease of programming use ANSI C and Curses, maybe extended with a very simple interpreted language like scheme. Run the program from dos or the console. It's not like this hasn't been done before. Everybody wants to make life complicated for themselves these days. Humans went to the MOON and back with less technology. Pretty soon people are going to need UML diagrams to blow their nose or something.

Re:Question

[Anonymous Coward]

Ever consider that Java is a toy language, and has never been used to write a large scale application?

You sir are an idiot.

Re:Question

[Anonymous Coward]

Yea, memory is a big problem when 256MB is $14

Re:Question

[PD]

Damned idiot moderators, this was a perfectly good comment, with a good suggestion, AND a truthful statement about Python and Java.

Moderation is not the place to put across your personal opinions.

Re:Question

[apankrat]

> .. especially if one of the target platforms is Microsoft

Would you care to elaborate on this argument ? For every bug in MSVC or Intel or Watcom there is a complimentary bug in g++ and c++. I worked quite a bit with all of these and the bottom line is that they all buggy, and there is no definite sucker amongst them.

Re:Question

[jonabbey]

Only arguably truthful. Python is a far more dynamic language than Java, to be sure, but I've never seen any evidence that it is more portable.

Re:Question

[jfunk]

There's a Java implementation of it, and there are platforms it runs on where Java doesn't, such as PalmOS.

The fact that Python is *much* simpler to implement than Java also contributes to portability.

Re:Question

[sbrown123]

They said they used Java. So that answers your first question.

Second, in over a decade of programming I have never heard of consumers telling the developers what language that will be used to get the job done. If they know what language to use, why not just code it themselves? Consumer's are an easy lot: they just want a product that works and is dependable.

Java is not a toy language and is used in many large projects. Infact, it has through the years gained ground on C and replaced many old Cobol and Assembly designed pieces of software. This may be the reason for your outrage: fear. As a C/C++ programmer, you have a fear of change and natually feel challenged by this powerful language. Dont be mad, it took years for Cobol to be replaced. You will still have a job.

Enjoy.

Err, you told us didn't you?

[mainframe_uk]

QT covers the multi-threading and network stuff so you're down to just serial port stuff aren't you. If you use QT properly then you should be fairly ok.

Re:Err, you told us didn't you?

[Surak]

Right. Serial port stuff is another issue. Most of the serial port stuff that I've seen written was either written years ago, or based off of stuff that was written years ago. What you'd have to do, more than likely is either find a serial port library that wraps around OS functionality, or write one yourself.

'nix and NT handle serial ports very differently, and I doubt that such a library exists. Writing one should not be too difficult because serial port stuff is really basic anyways...you have data going in and data going out, it doesn't get more complicated than that. :)

Re:Err, you told us didn't you?

[larien]

Even if the serial stuff was written years ago, is that such a problem? What difference is there between a serial port 10 years ago and a serial port now? My guess is not a lot, other than perhaps faster baud rates, but I don't think even that has changed in about 5 years (how long have we had UART 16550?).

Worst case scenario, put all the serial code into one file and use functions like open_serial_socket(), read_serial_data which call the underlying OS functions. When you move to Unix, swap out the file for the new version.

Re:Err, you told us didn't you?

[statusbar]

Some libraries compiled for Win98 serial ports will not work with Win2000 serial ports. The API sucks and is overly complex (hey, it is micro$oft!) - also, the API does not deal with 16550 directly. AND-, at 115kbaud, the NT serial driver WILL lose data bytes, even on a dual pentium. So you gotta EXPECT dropped bytes. No one usually notices this because they are usually using PPP which handles the re-send for you.

But it IS easy to write your own anyways on both platforms. No big deal. RTFM

--jeff

--jeff

Re:Err, you told us didn't you?

[SquierStrat]

Luckily we're just dealing with NT and unix hear, no win 9x...err that's what I understand. :-)
Cross-platform for unix, win 9x and nt would be hell on earth! I'd probably shoot myself rather than take the job. :-)

Re:Err, you told us didn't you?

[aminorex]

This is one good argument for Java: It handles
serial I/O portably.

Re:Err, you told us didn't you?

[strobert]

For serial port (and network and threading for that matter. look at: http://www.ysl.org

okay, so I am biased (one of the authors), but the serial code works well on both linux and winNT (haven't tried the serial code on another unix). Has been use for commercial use to communicated with embedded hardware controlling oil drilling equipment.

If you grab it, definently use the cvs access (haven't done a release in a while as all active users go for the revs in CVS)

and it is OpenSource

Usr Open source tools

[Lumpy]

Your choice of Qt is a good start, but be sure to use GCC, all open source libs that exist on both sides, and adhere as closely to the ANSI standard as you can. If you do the footwork now and gather the libs and other files needed now for both sides AND keep cross compiling on both platforms as you go.

Dont think you can make it under NT and then 2 years later that it will compile on *Nix magically, you need to test every step of the way.

Oh and be sure you have the libs that are identical for both platforms and freeze them before you start. nothing kills a cross platform project faster then changing libs and finding later that the libs you built for on platform X are no-longer compatable with platformY's libs.

Re:Usr Open source tools

[anandsr]

Also to add, better would be develop on unix
and cross compile for Windows, using cygwin.

That way you have both things ready, and would
take the same time. If you develop on Windows
you will have to take care not to use something
not available on Unix. I think there are lesser
ways to goof up when developing under Unix.

You may need to get used to the environment,
though. But that you can only postpone a year.

Re:Usr Open source tools

[Anonymous Coward]

Yeah, but then you'd have to pay Cygwin for a licence. Its not free you know.

ACE

[Anonymous Coward]

Lookup ACE on yahoo, adaptive communication environment (or something like that).

Got all sorts of CP junk

NT vs Unix.

[billn]

The question is begging, and I'm surprised a troll hasn't nailed it yet. Why start on NT and port to Unix, especially in light of MS's recent vow to hide security holes instead of fix them?

For an energy management system, security should always be a prime factor in any design. I'm not trying to smash down NT as an insecure system, but given the sheer number of factors you simply may not be able to account for, is this tactic wise?

I'm curious to know how long the security debate was in choosing NT devel first over Unix.

Re:NT vs Unix.

[ZxCv]

My guess (and what my impression was reading the post) is that the submitter has to use NT, presumably because whatever systems it has to run on currently run NT.

Just be glad its not the other way around and they're not migrating from Unix to NT.

Re:NT vs Unix.

[T-Punkt]

Conspiracy theory:

First they write it for NT/2K, fix all bugs ("will be tested an NT for up to 12 months") and when they move over to *NIX after another year in production ("final version will run on NT a year after that") the bunch of small little new problems will show that usually happens if you switch over to another (not or less tested) platform.

Then someone comes along and says: "See? Windows is much better than *NIX, let's keep Windows" and we will read in the papers of the failed conversion of some big electric company from NT/2K to *NIX and how great Windows is and so on...

Or .NET

[Anonymous Coward]

Java sounds like a much better choice given the planned OS switch.

Alternatively .NET should be ported to *nix by then (hasn't the IL part of it already been done?) so I'd seriously consider that too.

Re:Or .NET

[Lussarn]

.NET may never be seen on unix at all, to early to speculate on that. It's also not mature/tested enough to run this kind of software. Give it five years and come back then.

I would have seriously considered java on this one. Altough building around QT (which isn't just a widget set) is also a worth some investigation.

Re:Or .NET

[dda]

Excuse me, but what's the point? I don't understand what .NET has to do here.

Re:Or .NET

[Anonymous Coward]

.NET is a ridiculously-easy-to-develop-on platform for Windows; the querant would find they got things done very quickly. Certainly magnitudes quicker than writing in C++.

And in the not too distant future .NET will come to *nixland.

wxWindows

[Anonymous Coward]

wxWindows (http://www.wxWindows.org) supports quite a few platforms, is open-source, has been developing since 1992, and might be probably exactly what you're looking for.

Re:wxWindows

[joerg]

wxWindows has Networking support (socket I/O, ipc,... whatever you want), thread support, a rich feature set for GUIs and much more (unfortunately there is no support for Serial I/O).

You might even consider to drop QT in favor of wxWindows.

It is availabe for Windows, XWindows (GTK based), Mac and some other platforms. It is released under the LGPL.

Re:wxWindows

[erlando]

And it has the IMO great advantage over Qt in that it uses native widgets where possible. Qt draws its own widgets afaik.

Also the Qt-license is very restrictive. wxWindows has a license explicitly allowing the library to be used for commercial purposes.

wxWindows runs on Windows, MacOS (9 and X), GTK(+). Work is underway to implement a universal version of the library to be run on embedded platforms.

wxWindows is open-source. Patches and contributions are highly encouraged. Also the mailing-lists are very active with several of the main developers taking part in the discussion.

Re:wxWindows

[SerpentMage]

wxWindows is really good. I am using it for a shareware application. IT IS AMAZING!!! It is professional because it has the little things (Internationalization and printing). I also found wxWindows extremely intuitive. It only took me a day to become fluent in wxWindows. Ok I know MFC, GTK and QT (read the full documentation) so I sorta knew what to look for.

wxWindows could be worth your time to look at.

Re:wxWindows

[rs_nuke]

A year back when trying to find out if I should choose QT or wxWindows, I noticed very poor reliablity with QT, I did experience several cores just by compiling the samples that came with QT on all *nix plateforms. (Solaris,HP-UX,IRIX,DUX) I remember my Solaris box often cored after playing with QT widgets... However, QT was _rock_solid_ on Linux, and windows.

wxWindows is far more a complete set GUI and more including I/O, networking, ODBC (database)! The nices part about wxWindows is the native look, of other *nix apps, on the unix world, which come with Motif R1.2 or better, using the Motif build of wxWindows gives a nice native look, and smaller executables! By linking with already found Motif libraries DSOs! I recalled some sample QT examples were like several megabytes! On non-x86 *nix boxes.

For someone that has been working with wxWindows, and tried QT, by far, I think wxWindows wins hands down. I don't know why it isn't as "famous" as QT.

My .02cents...

Re:wxWindows

[Anonymous Coward]

> A year back when trying to find out if I should choose QT or wxWindows, I noticed very poor reliablity with QT, I did experience several cores just by compiling the samples that came with QT on all *nix plateforms. (Solaris,HP-UX,IRIX,DUX) I remember my Solaris box often cored after playing with QT widgets... However, QT was _rock_solid_ on Linux, and windows.

I've tried them both very recently, and while Qt 2.x was somewhat lacking in Solaris and HP-UX, Qt 3 seems to be very good.

>wxWindows is far more a complete set GUI and more including I/O, networking, ODBC (database)!

Qt 2.x has I/O and networking. Qt 3.x has database.

>The nices part about wxWindows is the native look, of other *nix apps, on the unix world, which come with Motif R1.2 or better, using the Motif build of wxWindows gives a nice native look, and smaller executables!

Well, having a native look (which Qt does), and using the native libs (which wxWindows does), is quite different. Just being a wrapper usually causes problems because the underlying platforms support different things. Sun had problems doing this with their original gui toolkit (AWT), so they decided to handle it like Qt does, with Swing.

By linking with already found Motif libraries DSOs! I recalled some sample QT examples were like several megabytes! On non-x86 *nix boxes.

For someone that has been working with wxWindows, and tried QT, by far, I think wxWindows wins hands down. I don't know why it isn't as "famous" as QT.

My .02cents...

Re:wxWindows

[Anonymous Coward]

the qt commercial license is not restrictive at all. it lets you do what you want, and gives support for it.

Re:wxWindows

[Spy Hunter]

And it has the IMO great advantage over Qt in that it uses native widgets where possible. Qt draws its own widgets afaik.

And this is such a great advantage why? QT's themes mean that you can make it look exactly like anything. You can make QT look (and feel) like it's using native widgets, in which case it doesn't matter one tiny bit who is actually doing the drawing. Plus you automatically get themeability if you want it.

Re:wxWindows

[affegott]

It aids in platform consistancy. People expect a windows app to behave and look like a windows app. I was not too pleased with Qt on Windows. The gui seemed very slugish.

The best use is reuse, so MS already spent the time doing the widgets, so you might as well use them.

Overall, I was very impressed with wxWindows. They took on a very complicated task, and it appears to be working out. I used wxWindows 2.2.7(Win 2000 and WinNT) and wxGTK (Solaris 7 and Redhat 7) on a fairly complex GUI... and had NO problems.

-Later.

Re:wxWindows

[Anonymous Coward]

QT is released under the GPL as well as the QPL.
If you decide to use it under the GPL, it's not exactly restrictive, is it?

Re:wxWindows

[Spy Hunter]

I was not too pleased with Qt on Windows. The gui seemed very slugish.

I have not noticed anything like that. I thought the advantage of Opera was that it was supposed to be lightning fast, faster than IE. Also, QT's platform consistency is great.

About reuse, well, TrollTech already spent time doing QT's widgets, so you might as well use them.

Re:wxWindows

[erlando]

And this is such a great advantage why?

Why re-invent the wheel? It just adds to the overhead. And the native widgets will just follow the theme on the OS.

Also it preserves the look and feel of an app on the given OS. A great advantage when coding to Joe User.

Re:wxWindows

[Anonymous Coward]

I like QT but only the Unix version is released under GPL. Windows and Mac versions 3.0 currently have commercial license only.

A step back ...

[Hagmonk]

Perhaps you should take a step back and ask "Why is this needing to be cross platform in the first place?"

There are cross platform libraries around. You may wish to just roll your own, but I would suggest constantly testing against your *nix machines throughout development to ensure compatibility.

One thing you *don't* want to do is start testing against other OSs six months into development. Do it every day, and develop a regression test suite.

Re:A step back ...

[Anonymous Coward]

Perhaps you should take a step back and ask "Why is this needing to be cross platform in the first place?"

Probably because the customer has specified exactly that? Get back to your CS101 classes kid, this here is Real World Stuff the grownups are talking!

Re:A step back ...

[Hagmonk]

Given a clean slate, why develop on NT then migrate to *nix? What is the logic behind that? Or should you blindly be ass-banged by your customer without asking questions? I would start to ask questions if the customer was sending me on a wild goose chase for cross platform libraries.

There is a very real risk that your 'Real World' is populated with morons, and that you may be one of them.

At least use the STL..

[reachinmark]

We have our own API that we used to support on both unix and NT. It was originally developed on IRIX, and we made extensive use of the C++ Standard Template Library which made things a bit easier when porting to NT.

I realise that the STL isn't on the same level of cross-platform libraries that you were referring to, but it does aleviate some problems - and it's damn efficient too. Stream's, the way the STL uses them, can be quite an effective way of abstracting I/O.

The biggest two problems we had was threading, and serial I/O. Threading, thanks to NT's posix libraries, wasn't that much of a pain - but we did need to write our own thread interface classes, one NT specific and one unix specific. Serial I/O was a little more tricky, but both came down to the same basic approach of treating the serial ports as files.

I think the conclusion we came to was that it was a good idea to highlight the major differences first, and create your own wrapper classes around the OS specific methods. This way your main program is platform independant, and porting is kept to the wrapper classes.

And of course, if you use the Cygwin environment, you shouldn't have any problems at all porting to another GCC platform.

Only one warning: watch out for tricky C++ template uses, not all compilers support all features (e.g. Visual C++ lacks partial template specialisation amongst other useful features).

Re:At least use the STL..

[shic]

While I find the STL invaluable, my experiences with it under VC6 leave me less than impressed. I've encountered problems with relation to multiple threads, which proved most unpleasant. While, as anyone who has used the STL for more than "hello world" will know, the STL is not thread safe. The problem arises in determining the acceptable ways in which an STL object can be used in a multithreaded application. At first I assumed that it was acceptable to wrapper access to each object with a critical section, but came to realise after several hours that this was inadequate for MSVC 6 STL in light of certain functions depending upon the use of static internal attributes... hence requiring me to impose a global scope critical section whenever I accessed any of my container objects derived from STL bases. It is also important to realise that the signatures to certain methods are not the same as in other implementations... I particularly recall differences between MS's erase() and the status quo suggested by platform independent STL documentation.

Some "bugs" are reported by Dinkumware, who purport to have written the VC6 STL, but also offer to sell a "better version". I also remember Service pack 4 breaking the STL, which was reverted in service pack 5. I have had less problems with the STLport implementation, but any developer considering a design based on multiple threads and the standard MS VC6 STL should beware!

Re:At least use the STL..

[bigbird]

Threading, thanks to NT's posix libraries, wasn't that much of a pain

Keep in mind that NT's posix libraries used to perform an order of magnitude worse than Win32 calls, e.g. select() vs WaitForMultipleObjects(). It's been a while since I've worked on Win32, but keep it in mind.

Re:At least use the STL..

[reachinmark]

Keep in mind that NT's posix libraries used to perform an order of magnitude worse than Win32 calls, e.g. select() vs WaitForMultipleObjects(). It's been a while since I've worked on Win32, but keep it in mind.

This is still true, actually - and something I forgot when writing the earlier posting. We always use Win32 calls such as CreateThread() and WaitForSingleObject() calls for our "real-time" device drivers because of this fact. But then, we only have two "real-time" objects anyway, so it wasn't a big deal when maintaining dual-platform support. But for the more common "not-quite-so-important-time" threads we stick to posix methods.

Re:At least use the STL..

[smittyoneeach]

(e.g. Visual C++ lacks partial template specialisation amongst other useful features).

IMHO, this points at a global requirment for the market to punish vendors who produce non-standard-compliant products.

It makes perfect sense from the vendor viewpoint to increase lock-in and smoke the competition through extensions and incompatibilities.

Guard your wallet.

Isn't the STL, and the generic programming it introduces, one of the main features lacking in Java? Or will Java catch up in that area?

Re:At least use the STL..

[Anonymous Coward]

Java 1.4 (right around the corner) will have Generics included. Albeit not the implementation most everyone coming from C++ might expect.

Re:At least use the STL..

[KenSeymour]

That's odd. I have used STL with threads under MSVC 6.0.

I didn't have any problems. I did use Windows critical sections for methods of my classes
that added or removed things from collections.
The critical sections were declared as data members of the class, not at global scope.

One of the patches on the dinkumware site fixes a bug that affects the map class when you use it
in a dll.
We applied that fix and it took care of that problem.

So when we were done, it worked great.

Perhaps we were already at service pack 6.

One caveat with STL is this. If you start with
the GNU C++ compiler, then it is possible to
write STL code without specifying namespaces.
This non-standard code, which compiles on g++,
will not compile on MSVC 6.0.
It did compile on MSVC 4.2 though.

NSPR

[machingo]

Check Netscape Portable Runtime, (just one of the many projects that are part of Mozilla. This library provide cross-platform threading, IPC, network/file IO, and dynamic linking, among other things.

Re:NSPR

[Simm0]

imho mozilla.org's NSPR rocks. I've made a few applications based off nspr and I think they're pretty good. It offeres basically everything you need for the project that is ai hand. You could even possibly use XUL instead of Qt if your interested in a nice XML based XP(cross-platform) ui.

No

[corebreech]

Insist on coding to the target platform. The target platform appears to be *nix, so insist on coding to that.

This sounds like a decision made by somebody who doesn't know what they're doing (when they're not looking I like to call them stupid but you don't have to.) It is part of the job description for software engineer, even if it isn't specified in any contract, that you are responsible for advising management whenever they exhibit dimwitted behavior.

Life is too short to be bending over backwards to accommodate another's failings.

Re:No

[NineNine]

It's the engineer's responsibility to advise what to do, nto to insist. Work is work. If it pays well, but it's a bad idea, that's not the engineer's problem.

Re:No

[Anonymous Coward]

If software engineers are responsible for advising "stupid" management whenever they exhibit dimwitted behavior, who will be responsible for advising unrealistic slashdot posters when they exhibit immature behavior?

Re:No

[ckaminski]

I disagree.

With a proper abstraction library, this isn't such a big deal. I had to port an application that was 100% WIN32, but using several abstraction libraries to Solaris. About 14 days before the beta was due to the customer I get the order from my boss to port to Solaris, and get ready to demo the product.

5 days later, when the Ultra 5 arrived, I set to work. 7 days after that, I installed Oracle to test the application for the first time. It failed. I spent the remaining two days fixed bugs, but we demoed the application to the customer on time, and without flaw.

Granted, I lost 2 weekends in the process, but I felt management sufficiently recognized the effort I made (big bonus).

My argument is this, you have to start somewhere, and it's best to start where the developers of the project are more comfortable. What good is software if you have to learn the work infrastructure first. I've always been a fan of incremental development. Write a function, test, release, fix write, test, release. If it takes you a week to get the first line of code out of your developers because they are using UNIX, then you've already doomed the project.

Use abstraction libraries, and you can revisit portability a month down the road, when there's something to actually port.

But I do agree that you shouldn't wait a year to start porting. Do it as soon as you have the first version running on Windows. And test test test test test.

It also would help if you have at least ONE developer doing development primarily on UNIX. Then when the time comes to switch to UNIX, you've already made sure it works.

-Chris

Re:No

[codemonkey0]

I do think a Software Engineer has a fiduciary duty to advise his client on proper systems architecture( hardware, software(language, performance, skill sets, etc), cost associated with entire process ). I also think it a wise business decision to drop projects that a suitable compromise cannot be reached or change the contract to state the concerns and place legal responsibility on the client.

This is the classic example of why licensing of Software Engineers is such a hot topic! Software development is an abstract process even when proper methods are used . I think a cost comparison, assuming C++ development, of using NT + *nix vs. developing for the final target platform *nix would convince the customer to simply develop for *nix.

Apache Portable Runtime

[bob@dB.org]

would be a good place to start for the threading and networking parts. from what i've seen, it looks like a well engeneered package (and you'll have a hard time finding a better tested library :-). http://apr.apache.org/

Re:Apache Portable Runtime

[ttfkam]

Not really... Netscape Portable Runtime is at version 4.1. The APR came about with the development of Apache 2.0 (still not out of beta yet). NSPR had been tested and used since before Mozilla started development. It's been the cross-platform glue that put Netscape Communicator on so many different kinds of computer.

Not to slight the APR, it's a well engineering library. However I still think that the ASF would have been better served by reusing (and improving) the NSPR than making their own.

So much for code reuse in free software... :-/

Re:Apache Portable Runtime

[mccoma]

> I still think that the ASF would have
> been better served by reusing (and
> improving) the NSPR than making their
> own.

I would imagine license was the issue.

From the NSPR website "When you contribute material to NSPR, you agree to allow your contribution to be licensed under the MPL or GPL."

APR uses Apache's own license which is less restrictive.

Mozilla libraries?

[PastaAnta]

NSPR is used in the Mozilla browser for x-platform threads and network/file I/O. It should basically cover all your needs, besides serial port I/O i guess.

You may have a look at their homepage: http://www.mozilla.org/projects/nspr/

qt 3.0 have it all

[eske]

Well if you are using qt for GUI why not use the
qt 3.0 network tools.
se the doc for qt 3.0 http://doc.trolltech.com/3.0/

I know that there is no IO mod but g++ have som you can use!

Re:qt 3.0 have it all

[Anonymous Coward]

Threading in Qt is limited to just posting threadsafe events to the main Qt event queue. Their database layer is not threadsafe, nor is their database communication layer - nost of their library is not. This is the major shortcoming with most C++ libraries in general - they were not designed from the ground up with threads in mind. Something to be aware of.

Re:qt 3.0 have it all

[Anonymous Coward]

(repost correcting stupid typos) Threading in Qt is limited to just posting threadsafe events to the main Qt event queue. Their database layer is not threadsafe, nor is their socket communication layer - most of their library is not threadsafe. This is the major shortcoming with most C++ libraries in general - they were not designed from the ground up with threads in mind. Something to be aware of.

Try NSPR

[Prod]

Mozilla.org uses NSPR (Netscape Portable Runtime)
From the about page
NSPR provides platform independence for non-GUI operating system facilities. These facilities include threads, thread synchronization, normal file and network I/O, interval timing and calendar time, basic memory management (malloc and free) and shared library linking.
You can find more information here http://www.mozilla.org/projects/nspr/index.html

Rogue Wave

[sql*kitten]

You need SourcePro from Rogue Wave, formerly Threads.h++ etc. It provides a high level, easy to use C++ API for cross platform application development. Even if you're not going cross platform, the Rogue Wave stuff is excellent, provides loads of useful classes for threading, database access, network protocol handling and more.

Re:Rogue Wave

[Hagmonk]

Hmm, Rogue Wave's STL classes, which I have used with SUNWspro 5.0, blew dogs. I'd be interested to see if SourcePro was as bad as the STL stuff ...

Re:Rogue Wave

[King Of Chat]

Didn't they get the old zApp class libraries (mostly GUI) as well? They don't seem to be pushing C++ stuff much on their website (traitors!) so I can't tell.

A few years ago I used zApp. I coded up about 250,000 lines of C++ on OS/2 2.1, then ported it to 16 bit Windows. The port took less than a week - IIRC, there was about 50 lines of platform specific stuff. Mind you, OS2 and Windoze aren't that different and I am a genius.

The old Tools/threads/stuff.h++ stuff sounds like what's needed for the non GUI stuff.

Re:Rogue Wave

[Teancom]

We have used .h++ for years around here for our main inhouse app. We decided just yesterday to remove all remaining dependencies and go to straight stl. Why? Because .h++ is not source-code compatabile with SourcePro, they provide no migration path, or even a "porting howto" (all according to our account rep). So we are faced with either spending the time and energy porting from .h++ to SourcePro, or spending the exact same amount of time and energy porting to the stl, with the side benefit of making our app linux compatable.

Which reminds me, their linux port *SUCKS*. The latest and greatest .h++ will run on Redhat6.2, with gcc 2.95.2, the stock kernel, and *thats* *it* (not even perfectly, there are serious bugs). Any other platform (we've tried mandrake 7.2,8.0,8.1;debian2.1,2.2;redhat 7.0,7.2) will segfault/core dump. Their next release, due January, will run on redhat 7.1. I have no doubt that it will fail to run on anything else. So it really falls down wrt cross-platform compatability.

So, to summarize, if you happen to be running one of the "tier-one" plarforms, their libs are pretty decent. Anything else, even if it's listed as "compatable", and you'll be screwed.

(as a quick example of what I'm talking about, our app has different defaults depending on what it was called as, tc vs. frpt vs. etc, and it does a simple check of ARGV[0] to see if it .contains the various names. It doesn't work on linux. Flat-out returns the wrong value. And that's on redhat6.2. Any attempt to use their string class will immediately seg-fault. I'm seriously disappointed, in case you couldn't tell.)

Re:Rogue Wave

[Anonymous Coward]

RogueWave is so-so. The software performs adequately, or a bit on the slow side. Their main emphasis is portability - not speed. They are not open source and there are a few annoying bugs you have to deal with with each new release. Their new price model is confusing - you don't seem to buy their software any longer - you lease it. I could not find a recent price on their web site - I guess they've succumbed to the Oracle-make-up-the-price-as-you-go-along sales model. You've got to wonder in this economic climate if they will survive as a company. The last time I looked they had losses for at least the last year. Their revenue is declining as well. I suspect that their Java strategy (which they abandonned) nearly killed them. They are finally releasing new C++ products for the first time in years - a C++ servlet API. It's about time. They were reasting on their C++ library laurels for too long and not getting any new sales. At least you have the source code so if they go tits up your project will not be a complete disaster.

Re:Rogue Wave

[albrecht]

I've had the same experience as many of the other people who replied to this comment. The RogueWave tools library is more trouble than its worth. The database and threads libraries are okay but you can probably find a better cross platform threads library these days. I'd stick with the C++ standard lib and boost (www.boost.org) as much as possible and then look at RogueWave as a last resort.

Re:Rogue Wave

[Anonymous Coward]

Guys... We are using Rogue Wave libraries here, and it is giving us a pain in the bottom! We are developping for all Unix and Windows platforms, and well we are running into a wall... Well sort of... Given it is legacy code using this labrary (don;t know which version) but IT AIN'T multithread! every single time we try to go multi-thread... we cannot link we the libraries that use RogueWave !!! now don't give me the crap that we are using the wrong libraries... rogue wave is aware of the issue and they having a hard time explaining this to us... (We are in the top 5 Largest Software development firm)

But if you can live with this... it is fun t use... no more strcpy or strcmp !!! just use == or = !!

Re:Rogue Wave

[ShaggyZet]

I had extensive experiance trying to get Tools++, DBTools++ and their STL to work on NT, Solaris and AIX. It was a nightmare. Different compilers supported different things. For example, RW libs wouldn't work with gcc on AIX, so we had to keep using the vendor compiler.

There were problems with shared libs that tech support could not resolve. And, they basically would lie to us about features that would be supported in the future to get us to sign support and upgrade contracts. Then, when the release didn't contain those features, they'd lie again and say they never promised them.

As someone already mentioned, performance was a dog. For database IO we ended up improving the performance for certain select statments by over 100 times on the same hardware when we wrote our own DB abstraction layer.

They're API is easy and it's tempting to use, but my advice is to stay as far away as you can. I know we regretted locking ourselves into their tools.

Re:Rogue Wave

[Canadian Eh]

Gotta disagree here...

I've used RW .h++ from 6.0->7.0->SourcePro, with very little change to my source code. It has been portable Solaris / WinNT with very few problems.

If I was starting out today, I would probably not spend the cash, but it has been pretty good over the years.

Re:Rogue Wave

[Teancom]

Um, so? My post was specifically referencing how bad the linux port is. If the original poster is going to port to linux at all, he should stay away from Roguewave products. If not, have fun. As to the .h++->SourcePro migration, I was simply repeating what my sales rep told me. If they were wrong, well, they were the ones that lost the sale....

But my main problem is the complete lack of real linux support. If they had been willing to even entertain the thought of supporting other platforms than redhat7.1, we might have stayed with them. As is, we don't want to be locked into one specific platform, just to have some nice string libraries (we no longer use them for much else).

Re:Rogue Wave

[LegendLength]

Shatner, I thought told you to stop posting here.

ACE library

[Anonymous Coward]

subj. is very powerful library, we use it for very large projects in our company and I also know that Israely Army is using it very extensively, it gives you totally portable IPC, Networking and a few less important services as well

This is wrong

[Nicolas MONNET]

Writing cross platform GUI applications is hard. Writing cross platform GUI applications with multithreading and network stuff is very hard, but most of all hard to get right.

Hard = difficult = long = costly.

The question is, is the cost worth it? This application, from what you're telling us, is going to run on a few dozen computers at most. It's not a general purpose app, there is no added value in providing cross platform support.

Why switch platforms in the end? It doesn't make any sense.

But to answer your question, if Windows is really a transitional system, I would just develop on *nix, and run it on Windows with Cygwin. Might be even simpler to use XFree/Cygwin.

Re:This is wrong

[SquierStrat]

Except it's not their descision is it? Remember, they were _commissioned_ to do it...they don't have the choice.

Re:This is wrong

[Nicolas MONNET]

Their decision? Well it might be that they underestimated the cost of X-platform support ("let's just use Qt"), and therefore their customer took that decision.

Re:This is wrong

[aozilla]

Writing cross platform GUI applications is hard.

Hmm, I find that quite interesting. I am currently writing a linux program in GTK+. I downloaded the source code into Windows, compiled, ran, and... it crashed...

Then I changed two places where I was calling free(), and changed it to g_free(). Recompiled, and the app runs perfectly on Windows and Linux.

Re:This is wrong

[Anonymous Coward]

Make it really simple on yourself: develop the app for *nix, then use VMWare to run a *nix and your app on the NT boxes.

Ummm... POSIX? BSD Sockets?

[Anonymous Coward]

I was under the -- perhaps misguided -- impression that Win NT offers a POSIX subsystem. Combined with Qt (which does threads, IIRC), the serial port access is covered by POSIX, and network APIs are like UNIX (give or take a WSAStartup()/WSACleanup()).

Kylix?

[Ubi_NL]

Why not write the whole thing in Delphi, which is -apparently- source-code compatible with Kylix. All you need to do then is recompile...

Re:Kylix?

[Surak]

Not necessarily. If you use ONLY Delphi/Kylix libraries, that's probably true. As soon as you make a raw Win32 API call, forget it. Dollars to donuts says the thing won't compile under Kylix. I have no practical experience trying to get Delphi apps to compile on Kylix (yet), but based on what I know about writing other stuff cross-platform, and combining that with my knowledge of Delphi, that's my story and I'm sticking too it. :)

Re:Kylix?

[Anonymous Coward]

Better not use Kylix/Delphi. It will only run on Linux/386. I dont know about Solaris or AIX, but everything that is not Intel ( Sparc/Solaris, RS/6000) will not work. Besides from that, the language is quite inferior to C++.

Re:Kylix?

[tiedemann]

If you read the Kylix FAQ you will notice that as long as you stick to the CLX-libraries there is 100% portability between Kylix and Delphi 6.

I haven't tried Kylix myself and I haven't looked to much into the CLX-libraries but I do know that Borland usually don't lie to you about stuff like this.

Re:Kylix?

[DarkEdgeX]

The thing is, almost all the features desired are already handled in the class framework for Delphi (the exception being Serial communications, which really are quite simple under Win32, which leaves writing your own cross-platform class(es) to handle it, or finding someone elses and porting them or using them). About the only time you'd ever use a Win32 API call is for a feature that wasn't implemented that you needed, and that's what {$IFDEF ...} is for.

Re:Kylix?

[partingshot]

> As soon as you make a raw Win32 API call,
> forget it

No shit. They don't call it a _WIN32_ api call
for nothing.

Re:Kylix?

[uradu]

That's true about Win32 calls, but that's not as big a problem as it might appear. Especially for business-type apps that don't need exotic hardware access, the VLC wrapps the OS quite nicely. And chances are that someone wrote a component to do what you need, and that this component will show up in Kylix sooner or later. I'm pretty sure many of the Delphi serial port components will be available under Kylix, if they're not already. The socket components already are.

The biggest argument against Kylix would be that it compiles only x86 executables. Rumors are that other platforms will be supported in the future (esp. MacOS X), but Borland doesn't comment on rumors. If however x86 Linux is all you need, you should very seriously consider Delphi/Kylix.

-

Re:Kylix?

[DarkEdgeX]

Whichever person with moderator points modded this Off-Topic, please shoot yourself, and spare us more of your idiotic moderation skills. Suggesting Kylix is a completely fair stance.

Re:Kylix?

[nwoolls]

Not to start a flame war or anything (muahaha), but can you please name for me some specific and provable inferiorities when comparing Object Pascal to C++?

Re:Kylix?

[Anonymous Coward]

Never would i engage in a language-flamewar !!!! Never. But:

AutoObjects
Templates
STL -> ( type-safe )
Friends
Local classes
operator overloading
scoped desctruction
Function Objects
Multiple Inheritance

Ok, really dont let this be a flame war. I do programming ( commercial apps in Delphi and C++ ). If you want to see the light, read "Modern C++ Design". I did. I rewrote a Delphi App in C++ with 20% of the code, more flexible structure and better performance and stability. Really, read that book. If you understand it ( its a little hardcore, it was not meant to be an insult ), you will see that all these aspcects i noticed in COMBINATION are a killer package that Delphi simply cant keep up with. Sure, you might find a way round multiple inheritance or for templates. But these techniques combined kick ass in unseen ways. Note, that the resulting code looks a little odd first. But you get used to it and you are way more productive. Maybe im not good enough for Delphi, but in heavy templatized, STLed C++ i almost have no crashes or memleaks. If, then they were easy to fix.

Re:Kylix?

[codepunk]

Right the resulting code looks not maintainable. Every feature you mention is not necessary in any application at any time. As for stability and using less code I do not beleive that poop either. This is a typical response from a person that thinks they can code object pascal.

Re:Kylix?

[Anonymous Coward]

I gave you a list of features. You give me nothing. I dont care if you believe me or not.
Are we talking Object Pascal or Delphi ? Take scoped destrucion for example.

in C++ i write:

{
std::fstream iif( "pascal.sucks" );
iif "look mum, no resource leak";
}

and then i dont even care about it anymore. It is simply a different style of programming. Done right, your code takes care of resources. No messy try..finallys anymore. Btw, none of the features are necessary in any application. You can code your entire crap in assembler and live with it. The thing is, in Object Pascal you CANNOT use it, because its simply not there. In C++ i have the choice to do it when it seems appropriate ( and i find this stuff very appropriate ). But as Stroustroup said, C++ was designed for the serious programmer.

Re:Kylix?

[MrBoring]

Although I use C++ professionally myself, I'm not ready to say it's easy to debug or understand. The C++ templates, while powerfull, are difficult to debug when the projects get large. It can be hard to determine what they expand to. My debugger, in particular, gets confused with them. VSlick gets confused with the preprocessor tags, too.

Second point: I suspect the choice of language might be a Hobson's choice. Either they were told to use it, or must use it for performance considerations.

On Java: You don't fully win here either, because although it may be more portable, it isn't as stable. I don't mean realiable, I mean that Sun keeps on changing it much more frequently. It's also a very vast platform--just look at how many books at Barnes and Noble there are on the subject. Way too much to read.

Compiler: If C++ is going to be used, your choice of compiler could be as important as the library you use. If someone could suggest a good one for Windows that compiles to native windows with native libraries (not cygwin), that's free, I'd be more than interested.

Re:Kylix?

[dctc]

Most of this stuff I can do with interfaces, including multiple inheritance or are not language features that make a *big* deference (like operator overloading, althoug that would be really nice to have).

I would also like to have language constructs for generic programming but not with the text replacment *thingy* c++ uses, I'd rather wait a while longer.

BTW, I still havent read a c++ book with stuff in it I could not implement in OP. I read c++ books often specially concerning patterns.

What do you mean by "hardcore"? Do you mean {}!=, etc... instead of begin end not and etc..., I hope not, this kind of "hardcore" stuff would only impress your little sister.

And what do you mean almost nor crashes or memleaks! LOL! Almost is not good enough:)

Can it be browser based?

[Ami Ganguli]

I'm not sure what you mean by "Energy Management System", but if the interface isn't heavily interactive, I'd go with a browser front-end. If you can, use Mozilla and XUL. It allows you to build really nice interfaces easily.

Browser-based apps aren't going to replace everything. Highly interactive things like word-processors, spreadsheets, etc. aren't suitable for browsers, but if the interface is form-based I think it's the way to go.

The obvious advantage in your case is that the interface code is painlessly cross-platform. You still have to worry about lower level stuff, but that's much easier to do properly if you eliminate the GUI.

Re:Can it be browser based?

[Anonymous Coward]

You still have to worry about lower level stuff, but that's much easier to do properly if you eliminate the GUI.

actually the GUI part is the least of his worries. several toolkits take care of that problem easily (for example, QT, which he settled on). network i/o is cake too. the real hurdle will be serial i/o (very different on the two platforms, but a small, well understood problem space) and threading (hard to get right on one platform, much less two).

Libraries

[Anonymous Coward]

We have a cross-platform multithreaded C++ application, and invested quite a bit of research to get it working on FreeBSD, Unix and WinNT (2K)

Basically, you will need these libraries:

STL - STLPort ( www.stlport.org )
Threads - QPThreads ( http://freshmeat.net/projects/qpthreadlibraryforc+ +/ )

That will give you a cross-platform STL, threading, and synchronisation primitives.

ACE library

[venekamp]

Some people within our project use the ACE library for multi-threading. Personally I have no expericene with the ACS library. They've used it for its portability. At the time some software was being developed it was not clear weather the software had to run on Linux or VxWorks, hence ACE. Quick search on google gave me: http://www.cs.wustl.edu/~schmidt/ACE.html

A more comprehensive approach

[Anonymous Brave Guy]

While cross-platform libraries will help, some things just work differently on different platforms, and you're unlikely to find a library covering everything so that all it takes is a rebuild to port.

As an alternative strategy, and one that's often easier in practice, I suggest you adopt the old programming rule of thumb: isolate anything platform specific in your code. If you're developing using C++, for example, define interfaces (probably via abstract base classes or in terms of templates) that represent the low-level functionality for serial comms, threading or whatever. Write all your higher level code in terms of those interfaces.

Then you just need to write the implementation behind them for each platform. This may be as simple as writing a few inline forwarding functions if your platform provides native APIs to do what you want. (Obviously I'm including any platform-specific or cross-platform libraries you have in the term "APIs", not just OS-provided functionality.) If, for any particular platform or library, there isn't a direct API to do what your interface requires, you can write a more complex routine in your implementation using the APIs that are available. It will still be isolated from the rest of your code, and nothing higher-level should need changing (or, hopefully, even rebuilding).

If you adopt this approach, the vast majority of your code will probably be 100% portable, because all it depends on is your own "middle level" APIs. Those can be implemented in whatever way is most convenient on a given platform, which might still include writing them in terms of a cross-platform library. The key thing is that most of your code isn't tied to anything platform-specific at all this way, and as such is immediately portable anywhere as long as your middle-level interfaces are sensible -- which they will be, of course, since you wrote them. ;-)

Re:A more comprehensive approach

[p3d0]

Absolutely right. Otherwise, you're at the mercy of an unknown factor. This is what software engineering is all about.

Make sure your interface is designed to place the least possible requirements on the underlying library, or else you may find it difficult to substitute another later. It would be wise to look at a few libraries (say, Qt, Gnome, and Windows' own) and concentrate on their differences, just to get an idea of the range of possibilities. Then design your interface in such a way that it doesn't rule any of them out unless it really needs to.

I know it sounds like you're designing your own GUI library from scratch, but that's not the case. You're simply expressing your GUI needs in terms of an interface which can be implemented easily in terms of existing GUI libraries.

Re:A more comprehensive approach

[interiot]

So, write your own cross-platform library since none available is taylored to your own needs. ?

Re:A more comprehensive approach

[BigCigar]

Free - ACE/TAO
Pay - Rogue Waves Tools.h++ dbtools.h++ net.h++

Re:A more comprehensive approach

[Observer]

Spot on.

But frankly, I'd go further. You've got a project that's complicated enough to have an 18-month schedule for design through to initial deployment and real-life testing, but which is then to be migrated to a significantly different system platform after only a furhter 12 months. Now, there may be sound reasons for this which people not familiar with the circumstances can't know, but to me it sounds distinctly odd, and frankly not the sort of project I'd want to get involved in. I don't suppose it would be possible to get back to the client and (tactfully) point out that moving to a different platform is going to cost a significant fraction of the initial implementation? (Off the top of my head I'd reckon at least 50%, because all the validation and quality assurance is going to have to be done all over again, even assuming fullest modularity in the original work.) Perhaps, just perhaps, starting on the intended longterm platform will then look more attractive.

Or, perhaps they can consider staying on the initial platform for longer than currently envisaged (which may be what happens anyway once the work involved in migrating becomes clear). I'm more comfortable myself working under Unix, but NT on good-quality hardware running well within its capacity and performance limits is a viable platform for well-defined application workloads. We have some specialised machines where I work that typically run 3 months or so between precautionary reboots, and have run >6 months when operations forgot on one occasion.

Good luck.

Re:A more comprehensive approach

[Squeamish Ossifrage]

This is actually a pretty straigthforward task, as the ammount of new platform-specifc code should be pretty small:

I'm told that QT code is source-compatible across platforms, so that's taken care of. Sockets libraries (network I/O) are the same under windows and Unix. That just leaves threading and serial I/O. The good thing about threading is that you probably only need to implement wrappers for a small portion of threading libraries (i.e. the portion you actually use). Posix Threads defines about 60 functions, but I honestly only ever use about 6: pthread_create, pthread_join, pthread_mutex_lock, pthread_mutex_unlock, pthread_detach and pthread_exit.

I don't know much about serial I/O under win32, but I doubt that it's too difficult... (heh)

Re:A more comprehensive approach

[Thomas Charron]

No. Abstracting your code provides you many things. Only ONE of which being the ability to cross compile easily. It also allows you to cross compile using DIFFERENT libraries on the SAME OS. Or even provide different networking capabilities. It makes alot of sense, really..

Re:A more comprehensive approach

[Anonymous Brave Guy]

So, write your own cross-platform library since none available is taylored to your own needs?

Not at all. Just isolate any use you make of libraries you don't control and/or may have to change (i.e., pretty much anything your team isn't writing itself and that isn't a standard part of your implementation language). You only need to define the interfaces; the implementations may well be trivial if you've got a good library or two to support you.

The isolation layer is a sound investment. It costs almost nothing in real terms. Where it does cost significantly -- if your implementation isn't trivial on a given platform -- you'll still be very glad you isolated that code later. It would have been much more expensive to implement whatever it is throughout your whole codebase when your "portable" library turned out to be anything but.

Re:A more comprehensive approach

[evocate]

This strategy has worked quite well for us. We put everything we could into servers that are fairly cross-platform: stl & iostreams, pthreads, gcc, etc. Some parts *have* to run on the desktop to show the users what's happening and get their input. All our users have Windows desktops, so we wrote the Windows clients first using Visual C++. It sucked less than we expected.

We have Java clients on the drawing board, but so far all our desktops are Windows. We have our doubts about whether a Java client implementation could make the performance cut. Java performance is ok for most systems, but this system has a *lot* of graphic and network i/o. Can you imagine Quake3 written in Java.

What holds everything together is the middleware from Tibco. We use their Rendezvous system and it kicks a lot of butt. It uses UDP broadcasting or multicasting to send out subject-based Observer pattern updates. It's:

1. fast: 10000 msg/sec
2. mature: developed over 15 years
3. fault-tolerant: process pairs/distributed queues
4. language-independent:C,C++,Java,Perl and Cobol!
5. cross-platform: NT/2K/XP,Solaris,HPUX,Linux

Sorry to sound like a commercial. The downsides are that it's expensive and closed-source.

I also recommend using Cygwin, cvs, gnu emacs, samba, rsync and anything else you can find to make Windows as blissfully unix-like as possible.

Re:A more comprehensive approach

[Anonymous Coward]

Hear hear. I'm getting really sick of these idiots who haven't done a Computer Science or Software Engineering degree at college running around thinking that they know how to make good software.

Re:A more comprehensive approach

[Anonymous Brave Guy]

I'm getting really sick of these idiots who haven't done a Computer Science or Software Engineering degree at college running around thinking that they know how to make good software.

How ironic. I'm getting really sick of those idiots who teach Computer Science or Software Engineering courses running around thinking that they know how to make good software. ;-)

LOL

[jrothlis]

Uh, yeah, this sounds like a *real* question: I want to develop a GUI application for *NIX, but I want to develop it on Win2k.

Re:LOL

[partingshot]

god help that energy company.

And why can't you use Java?

[Anonymous Coward]

You clearly point out that you have prior experience with Java. Java meets all of the requirements you listed:

• Cross Platform
• Portability without changing a line of code (or recompiling for that matter)
• Multi-threading
• Serial I/O
• Network I/O

In addition, you can get security, high availabilty, and scaleability with far less effort and platform-dependence than a C/C++ solution.

Are you being forced to use C/C++ simply because of QT? Have you considered using QT in conjunction with Trolltech's QT AWT?

Re:And why can't you use Java?

[onion2k]

Exactly the same arguements could be used for Perl..

Re:And why can't you use Java?

[OblongPlatypus]

Isn't multithreading still fairly shoddy in Perl 5? They say it'll be great in Perl 6, but at the rate things are going these days, Perl 6 is still a long way off.

Re:And why can't you use Java?

[kin_korn_karn]

oh, come on. this is not an application of Perl.
An "energy management" program probably has to be a lot faster than Perl can muster.

Re:And why can't you use Java?

[mvw]

Java meets all of the requirements you listed:

• Cross Platform

Which means it will run with all promised features only on Win32, with some drawbacks under Solaris, with other drawbacks under Linux (where it has a strange status between supported and unsupported) and is not supported at all under *BSD. The situation for Mac is not known to me, Jave seems to be available lately.

• Portability without changing a line of code (or recompiling for that matter)

Both is not true in general. Only non GUI programs, using only established APIs have a change to run without modification, so much for source compatibility. For byte code it turned out, that while the byte code it self might be stable, other stuff changed so much over time, that you are forced to recompile old classes (I had this experience with many security related APIs).

• Multi-threading

Multi-threading is still a complicated matter under Java, perhaps it is a bit easier because one just deals with one implementation per plattform in general.

But implementation is still different. Under Win32 you get preemptive multitasking, under other implementations (like Solaris up to certain revision) you have only cooperative multitasking. So you are still forced to stray yield() or sleep() into your loops.

I found debugging multithreaded apps under Java complicated as well, not too much help from the JBuilder IDE I used, and I was not able to detect certain stall conditions with JProbe's threadalizer. (Blame it on me or the tool :) I had to work things out with classic printf style debugging that gave me a hint, what thread was doing what.

• Network I/O

Berkley sockets are quite standard, be it UNIX or Win32 (WinSocks) that is not that hard.

• In addition, you can get security, high availabilty, and scaleability with far less effort and platform-dependence than a C/C++ solution.

I think that statement is bullshit. It largely depends on the experience of your programmer what is easier to use.

In my experience Java is still unforgiving. Good code runs well, but you will feel it if you run sloppy or bad code, be it speed or memory wise. Under C/C++ there is a certain margin of tolerance in that area. Alas you have to grok pointers, which seems to be seen as a problem todays.

On the good side Java has some large standardized libraries and nice development tools. I also believe that the average Java code is more modern, because it uses these modern libs.

Both approaches C++/QT/NSPR whatever or Java might lead to a working solution. Each has its strongnesses and weaknesses. (And there is other stuff, like functional languages :)

Again I would take the experience of the crew as the deciding factor.

Regards,
Marc

Re:And why can't you use Java?

[Curt Cox]

Do you have any pricing and availability links for QT AWT?

Re:And why can't you use Java?

[Anonymous Coward]

Check out SWT a new offering recently Open Source'd by IBM. It offers access to the native windowing. Windows controls, and Motif in Linux's case. A GTK port is in the works -- and best of all it's free. Eclipse

Re:And why can't you use Java?

[xemacs]

because Java I/O libs are a nightmare, and the network support [what they call socket] is, at best, a poor joke.

the stunts one have to make to work with async sockets.

Re:And why can't you use Java?

[AndersDahlberg]

Sure, java have not YET got all the small unix nicities with socket - but asynchronous is there now anyway (chechout jdk1.4beta3 + swt - www.eclipse.org, and you got a choice that is a LOT faster than c/c++ - native gui, interface in java, implementation in c with jni (windows/linux + java portability)

Re:And why can't you use Java?

[Teferi]

Eh, a JDK exists for FreeBSD, and if that isn't good enough, the Linux one'll run just fine. There's even a port for it.

Re:And why can't you use Java?

[Ivan Raikov]

And Python... And Common Lisp... And...

Re:And why can't you use Java?

[charstar]

nice commercial.
I believe I read those exact words in the Java alpha White Paper.

There ARE C++ toolkits out there that offer many of the components of the Java SDK. I've personally gone away from Java because, in reality, it's not all that Sun claims it to be.

Re:And why can't you use Java?

[Fnkmaster]

Sorry, dude, Linux is fully supported and the Linux JDK is distributed by Sun. You must be thinking of 2 or 3 years ago when the Blackdown JDK was originally built with support from Sun but by outside developers. Who still work on the JDK as far as I know, but there is an in-house team at Sun as well (and I haven't seen any of the parallel track Blackdown-Sun releases since JDK 1.2.2).

Re:And why can't you use Java?

[Anonymous Coward]

Except no one can read Perl code once it is written (Perl programmers don't have Tab key on their keyboards).

Re:And why can't you use Java?

[duffbeer703]

I think you are exaggerating the faults of Java more than a bit.

I use a Java GUI (swing) program and a several java server applications on AIX, Solaris and Windows NT every day, they perform pretty well.

Re:And why can't you use Java?

[Hard_Code]

Which means it will run with all promised features only on Win32, with some drawbacks under Solaris, with other drawbacks under Linux (where it has a strange status between supported and unsupported) and is not supported at all under *BSD. The situation for Mac is not known to me, Jave seems to be available lately.

What "promised features"? Are you aware of how many companies actually rely on Java for really critical stuff, and use it accross platforms? We have production systems that run a whole slew of Java software on AIX (yes, IBM AIX!), Windows, and Solaris (client applications, servlet engines w/ servlets/jsp, backended by Java CORBA objects and JDBC database connections). Mac OS has finally caught up with the rest of the world and produced a Java 2 VM. Microsoft is "dropping" Java support, but that doesn't mean a damn thing because we run Sun's reference VM anyway. Is using QT really that less difficult than a Java GUI in the first place?

Both is not true in general. Only non GUI programs, using only established APIs have a change to run without modification, so much for source compatibility. For byte code it turned out, that while the byte code it self might be stable, other stuff changed so much over time, that you are forced to recompile old classes (I had this experience with many security related APIs).

Where's your evidence? The only time I've seen incompatibilities is when Mac OS added an extra Help menu (oh horrors). Seriously, have you looked at Java since the mid nineties? APIs changing is a *version* issue, not a *platform* issue, and is an identical problem encountered by C and C++ programs (what version of libc, what version of GCC, etc. etc.).

Multi-threading is still a complicated matter under Java, perhaps it is a bit easier because one just deals with one implementation per plattform in general.
But implementation is still different. Under Win32 you get preemptive multitasking, under other implementations (like Solaris up to certain revision) you have only cooperative multitasking. So you are still forced to stray yield() or sleep() into your loops.

I found debugging multithreaded apps under Java complicated as well, not too much help from the JBuilder IDE I used, and I was not able to detect certain stall conditions with JProbe's threadalizer. (Blame it on me or the tool :) I had to work things out with classic printf style debugging that gave me a hint, what thread was doing what.

Multithreading is "complicated" period. A native language would painfully expose you to all those incompatibilities *anyway*, so I don't see how the case is any different. Do you have any arguments to lodge that aren't moreso applicable to native languages (yeah, writing conditional code for different native threading models for Windows, Linux, BSD, Solaris, etc. on top of the complexity of multithreading in the first place is *exactly* what I want *choke*).

Berkley sockets are quite standard, be it UNIX or Win32 (WinSocks) that is not that hard.

And they are just as "not that hard" in Java. Your point?

I think that statement is bullshit. It largely depends on the experience of your programmer what is easier to use.

Java security policy files. You set it, you forget it. Your code WILL NOT access resources you have not given it permission to. One the other hand, native code is notorious for security holes, accidental or otherwise. High availability is partly dependent on robustness of security. "Scaleability" is probably a lark, but as the poster says, you probably will get it with less effort given that you're not hardware bound.

So, in conclusion Java *does* meet all the requirements he posted. Perhaps C or C++ meets some more and some less than others but that wasn't the argument. C/C++ wins in performance, and integration with other native libraries. I can't think of anything else though.

Re:And why can't you use Java?

[aozilla]

Forget java, use wine.

• Cross Platform
• Portability without changing a line of code (or recompiling for that matter)
• Muti-threading
• Serial I/O
• Network I/O

Plus, unlike java, you're not running an emulator.

Re:And why can't you use Java?

[rmathew]

*sigh*

Being someone who's been coding for almost five years on Java for a living, I can tell that you haven't really gone beyond the white-papers and small programs.

Coding in Java *does* help a lot in porting to various platforms, but it does not guarantee it - as always, you will still have to build and test your programs on all of your target platforms. This is true especially of applications with a GUI.

And don't even get me started on the supposed "security, high-availability and scaleability" of Java.

Re:And why can't you use Java?

[Wraithlyn]

"C/C++ wins in performance"

I'm not contesting this, but I would like to add something. Modern HotSpot VMs are getting REALLY good. For those who don't know, HotSpot starts executing Java in interpreted mode immediately, to eliminate the costly startup time of a full blown pre-compiler like JIT. Then HotSpot dynamically analyzes the runtime characteristics of the program, and determines what sections of code are run most frequently. These sections ("hot spots") are then compiled (with advanced optimizations) to native code. They have also made major inroads with incremental garbage collection, short-lived object efficiency, thread synchronization, and a host of other goodies. Sun has been dedicating major resources to this type of research for years. Java has really hit its stride with 1.3, I can't wait for 1.4. (Primary focus in 1.4 is on stability and scalibility, as opposed to new features)

Don't get me wrong... I'm not saying the next Quake engine will be written in Java. I believe low level real time stuff will always be the domain of native C/++, ASM, etc.. but the performance difference between high level C and high level Java is FAR less that most of you would probably believe. I think the biggest caveat to Java is the huge runtime footprint, but that's the tradeoff of having such a feature rich, OS independant platform.

Here is Sun's white paper on HotSpot, it's very well written.

Re:And why can't you use Java?

[mvw]

Eh, a JDK exists for FreeBSD, and if that isn't good enough, the Linux one'll run just fine.

Yes, all exist. But the native 1.2 and 1.3.1 ports are still of beta quality.

And last time I checked it, the linux port too had problems running the Hot Spot VM. Part of this was due to the different thread implementations between Linux and FreeBSD. I'm not sure, if this has been fixed in the meantime. Could be, could be not.

For production use, one needs a rock solid implementation and the speed one gets. Thus having resort to the classic VM is a major drawback.

The situation under Linux regarding stability is better than under BSD. However the various JDK releases each have their own bugs and drawbacks and strangenesses. My personal experience is that while Linux got some support here from Sun, it typically lacks behind the Windows version in quality. This gets more obvious if you look at the situation for extensions, like Java3D, which lack behind in version often too.

Not that it is technically impossible to come up with similiar nice Unix versions, but it has not happened yet. And it is clear why. The present dominant client system is Win32 and Sun concentrates its efforts here.

Some experimental stuff I did (e.g. Java3D distribution via Java Web Start) did not work out under Linux while it did under Win32 due to fundamental problems with shared library loading and Linux glibc madness.

A lesser evil is the appearance of the GUI/Swing applications under X11 in general. It simply looks uglier than under Windows. I'm not sure why exactly, it could be the fonts.

All this adds up to my opinion that the only real nice Java implementation for building clients at present is the Win32 one. I don't like this, but such it is.

Regards,
Marc

Re:And why can't you use Java?

[mvw]

You are right that Sun features the JDK/JRE for Linux as well on its download page.

But if you look closer you will notice differences in the effort Sun puts in for the various plattforms. It is more obvious if you look at availibilty of the additional packages, like this one.

First comes Windows, be it 95,98,ME,NT,2000 or XP. You noticed the special XP 1.3.1 release? And it makes pretty much sense for them - enterprises typically use Unix for the server side and Win32 for client boxes, so the Java clients there need attention.

Next one seems to me Solaris. At least in the Java parts I work with, I see more activity for Solaris than for Linux. However I can't speak of the quality here, as I rarely use the Solaris box we have.

Last comes Linux, x86 Linux. And it is not clear to me what Linux they use as reference, as Linux distributions differ. Had some strange problems here.

I would like to hear other Slashdotter's opionion on this.

Regards,
Marc

Re:And why can't you use Java?

[mvw]

But you noted that I did not only criticize some of the hype arguments ("write once, run everywhere", or "Java is better than C++"), but that I said some nice things as well? (modern libs, nice tools). :)

And I didn't say that Java programs are not able to do their job - what I said was that programming a non trivial Java app is not as easy as some Java advocates tell.

There are some very nice examples of good Java apps. The clients I like most are JBuilder and Together, both IDEs.

But take JBuilder as example, this program is crafted very well and even if it is said to be a pure Java app you will find three seperate distributions one the installation CD (one Win32, one Solaris, one Linux :)

Regarding server programming: one of the interesting uses of Java here is to enable to get applications written at all. :) How many programmers for example have experience in C on a S/390 mainframe or have access to such a box to learn? In that case developing the app e.g. under NT first and then moving it over to the mainframe and tweaking it there is considerably easier.

Regards,
Marc

Re:And why can't you use Java?

[mvw]

What "promised features"?

The ones I need are:

• smooth and stable execution under Win32 and Linux, perhaps Solaris one day
• flawless access to the OODB we use and
• some goodies like Java3D and web deployment, (right now Java Web Start)
• If the development environment (Editor, Debugger, Profiler, Testing, Architecture, Configuration Management) would work under Win32 and Linux equally well, it would be a plus

The experience so far with all points (except security related stuff) was, that it either was less hassle under Win32 to achieve than under Linux, or it didn't work under Linux for various reasons. There is definitly a difference in maturity of both plattforms at this time. I would love to see it the other way, but I have to acknowledge reality.

Are you aware of how many companies actually rely on Java for really critical stuff, and use it accross platforms?

Sure. Java has its strong sides and its weak sides. J2EE reputation eg is excellent.

We have production systems that run a whole slew of Java software on AIX (yes, IBM AIX!), Windows, and Solaris (client applications, servlet engines w/ servlets/jsp, backended by Java CORBA objects and JDBC database connections)

Again, I don't said, Java is worthless junk. I however wrote down my opinion on some of its hyped ascpects.

Is using QT really that less difficult than a Java GUI in the first place?

I believe QT will give more trouble programming it (less mature development tools for example, smaller development community) but it will save some gray hairs if the application is demanding regarding performance and memory.

Where's your evidence? The only time I've seen incompatibilities is when Mac OS added an extra Help menu (oh horrors).

I wrote some not too complicated data visualization applets which at some time stopped to compile cleanly (ok, apis get deprecated at some point), did behave differently under different VMs and plattforms in some unexpected areas (eg like scrollbar behaviour) and at some time didn't work correctly anymore because the changed security model prevented correct access to the applet's data resources.

Seriously, have you looked at Java since the mid nineties?

I only paused between mid 1998 and mid 2000, otherwise I developped fulltime under Java as well.

APIs changing is a *version* issue, not a *platform* issue, and is an identical problem encountered by C and C++ programs (what version of libc, what version of GCC, etc. etc.).

True, but Java is always not only "Java the language" but also had a "Java the platform" aspect. And it turned out that is not as downward compatible as initially promised. A change 1.3.x to a 1.4 VM for example should not require recompilation or even recoding of a once running application. Guess what will happen once 1.4 final shows up? :)

And Java multiplattform is certainly not "write once, run everywhere".

Multithreading is "complicated" period. A native language would painfully expose you to all those incompatibilities *anyway*, so I don't see how the case is any different.

My point was that using Java here makes things a bit easier (you don't have to choose some lib like QT, NSPR or whatever, you know you do it with your Java implementation) but not really easier, because MT is complicated. Sounds simliliar to your statement.

Java security policy files. You set it, you forget it. Your code WILL NOT access resources you have not given it permission to.

That's theory. The Java interpreter and its byte code verifier are prone to implementation errors like any other product. There exist exploits as well. Not to speak of native libs who work in the background. (eg 1.4 on Win32 will improve Swing performance by resorting to Direct X use)

So, in conclusion Java *does* meet all the requirements he posted. Perhaps C or C++ meets some more and some less than others but that wasn't the argument.

Fine, but that is what i said as well. Java is an option. However it is not automatically the better option. If you have a bunch of fairly experienced Java hackers go for it.

Regards,
Marc

Re:And why can't you use Java?

[mvw]

The difference in performance between the early VMs and todays Hot Spot VMs is impressive, yes.

Those code optimizations at run time are however not a Hot Spot only domain, I have heard recent Intel C++ compilers offer similiar optimizations.

I agree as well that Hot Spot + Moore's law have made some Java apps possible, that were unthinkable a few years ago. I have seen some very nice "demos" (demos in the sense of stunning/teasing graphics + sound bits) written in Java lately.

You were commissioned this...

[Anonymous Coward]

... yet you don't know how to deal with this problem. Impressive.

Re:You were commissioned this...

[tshoppa]

.. yet you don't know how to deal with this problem. Impressive.

You gotta give him credit for realizing that this is an issue. The amount of non-portable crap out there in the world of commercial software is amazing. In my rankings, any vendor who supports *two* platforms from the same code base ranks in the top 1% of portability.

Stingray OT

[hoggy]

I don't have a great deal of personal experience with this, but at the last place I worked they had used Rogue Wave's Stingray Objective Toolkit as a cross-platform library for NT and Solaris.

I've heard bad things about it; I've heard good things about it. I couldn't comment either way.

I can't find it on their site now that I look, but I did find this: SourcePro, which looks similar. They change the names of the products on a regular basis.

Cross-Platform Tools

[tom581]

It seems to me that you're looking to prototype on the NT platform, and construct the production environment on Unix. Tcl/TK is a wonderful tool that promotes rapid application development, and multi-platform (nt,unix, mac, etc). Whether you're aware of it or not, all of the major industry players have been using Tcl/tk in their products, Oracle with oratclsh, IBM with wscp (their tcl/tk interface to websphere), Vignette with the tcl/tk interface. Also, considering that Ajuba has placed TclPro in the open-source community, you can DL the Unix & NT version's for free. The really nice features of TclPro, is that it contains the tclcompiler (to byte-compile your tcl/tk code), and the tclwrapper (to wrap your code into a binary executable). Most of Tcl/Tk's libraries are cross-platform, though there are specific's to both arena's, (i.e. IPC on Unix & Registry calls on NT).
I'd suggest you start with modeling the product in Tcl/TK on the NT platform, ensuring you don't reference any NT specifics. Once you're happy with the model. Copy the code to your Unix system, confirm it still runs, then compile it up into a binary executable for distribution. BTW, there's some nice GUI IDE tools available for Tcl/Tk, I'm rather fond of SpecTcl, a GUI for building graphical user interfaces, that will also produce java & html output.
Good Luck!

Re:Cross-Platform Tools

[Anonymous Coward]

I wonder if this project has look-and-feel requirements. I say this because Tcl/Tk is great, I've used it myself. Hell, Nortel/Bay Networks uses it for some of their graphical config tools (Device Manager for Accelar comes to mind).

This is just my opinion, but it seems to me that by-and-large Tk apps on win32 still tend to have a Motif-like look-and-feel. They still work just fine, but they don't always match the rest of the Windows environment. I've heard good things about QT, and I know there are several cross-platform GUI toolkits. That part of it shouldn't be too hard to find with a Google search.

Glenn

Win32 Pthread Library

[Tristessa]

I came across this win32 pthread library the other day. I haven't used it, or really read anything about it, but it's from Cygnus, so I imagine it is at least semi-decent. Good luck.

http://sources.redhat.com/pthreads-win32/

Re:Win32 Pthread Library

[Anonymous Coward]

Yeah, it works, however, pthread_condition_* is not implemented in it. (Which makes it a bitch to use).

Re:Win32 Pthread Library

[Anonymous Coward]

It states on their web page that the pthread_cond* functions are all implemented. I checked the ditribution - the code is in place as well. Does it not work? Or are you using an old version?

Java?

[Anonymous Coward]

Aside from not being C, Java is the best choice for the following reasons -
1. Superior Portability
2. Stability
3. Easiest way to multi-thread.
4. Good database connectivity.
Some people said that Java is slow. But it is actually not if you are programming with good design and skills.

ACE

[JanS]

Have a look at ACE. It provides all you'll need - and probably a lot more!

For a simple, free, portable threading library, also have a look at OmniThread.

Heed This Warning! Your sexuality is at stake!

[Electric Troll]

This article is another attempt to subversively convert more straight Slashdot readers into slashbots - homo toyboys, kept around for CmdrTaco's sexual forfillment. Let's examine the article and see why this insidious Open Sauce movement must be stopped at all costs: "My brother and I were just commissioned to develop a large energy management system" In other words, Cowboikneel and CmdrTaco get tired after too little anal sex and need a more effective system to manage their energy. This is no doubt due to them both being fat homosexual geeks. The only cure is to go outside, breathe the fresh air, excercise regularly, and stop taking men up the ass. "Aside from the GUI, which we've already agreed to use QT 3.0 for" Ever since qt was released under the GPL (Gay Penetration License), CmdrTaco's toy boys have been using qt more and more. qt, or Queer Technology as it is now known, was strictly forbidden before, as it did not allow RMS to have Gay Penetration with his Free Software ("Software" is a term for underwear designed for easy removal). It is a major loss for the straight community that qt has now 'come out' under the GPL. We must strive to find a straight replacement. "we specifically are looking for cross-platform libraries for multi-threading, serial port I/O, and network I/O." cross-platform, as I've already documented elsewhere is a term used to describe any object which will fit in CmdrTaco's, Cowboikneel's, and Homos's ass. It is truly a disgusting phrase. multi-threading refers to the homosexual practice of inserting more than one object up a gay lover's anus. The anus has to support multithreading for this to be possible. Cowboikneel has always supported this, due to the enhanced size of his O-ring. CmdrTaco has not always supported multithreading, but after being impaled on Homos's huge cock multiple times, he has now managed to support it. 'serial port I/O' refers to the sick practice of in-line Gay Penetration. Because of the nature of this task, each lover must hold a Gay Penetration License. in-line Gay Penetration means Homos taking CmdrTaco who in turn takes Cowboikneel, who continues the line of homosexuality. Many homos will join the line. The record line length is two hundread and fifty seven lovers! RMS and ESR were involved, of course, as well as many other prominent Open Sauce leaders. The nature of 'network I/O' is not known to me at this time. Although the intelligence gathering methods used to undermine the homopocalipse revolution are very advanced, no one has dared to enter a orgy in which 'network I/O' is going on and thus cannot give us more information as to the nature of this dark and sinister threat to our sexuality. Anyone who holds information on this matter is encouraged to let us know, even if it means putting their anal virginity at stake. This threat is of the highest importance and we must learn more about it. In conclusion, The homopocalipse, which was once thought to be merely a figment of RMS's imagination, is now very very real. We must work persistently and diligently if we are to destroy this threat once and for all. Until such a time as a straight man may once again walk with pride, and not fear being taken up the arse by rabid slashbots, armed with cross-platform dildos, we must excercise caution. Do not trust anyone. Do not believe what you read on slashdot. Treat everything and everyone with suspicion. I must go now, I fear the slashbots have discovered the hiding place from which I am transmitting this warning. If I do not make it out of here and to safety, please continue my work. Do not rest until slashdot is free of RMS and his homosexual minions. I will go now.

libSDL

[otsoni]

You may know about libSDL on Linux, which has been used in many Linux games. Loki has also succesfully ported across several Windows games to it. Don't be fooled by the name "Simple DirectMedia Library": Simple doesn't imply 'restricted', and 'DirectMedia' doesn't mean that only abstracts multimedia capabilities.

libSDL is a cross-platform library which supports not only video and audio, but also threads and timers. There are also plenty of support libraries for it -- including a cross-platform networking library that works on Linux, Windows, MacOS and BeOS. There's plenty of example programs for you to work with, it's open-source, and perhaps most importantly, it is mature and tested. The only downfall of it is that you'll have to track down the documentation for it, but there are plenty of SDL gurus around if you know where to look (the SDL mailing list is a great start). The SDL homepage itself also has links to other similar ambitious libraries, such as clanlib, if you don't like it. I definitely recommend that you check it out.

Start cross-platform from day 1

[bigbird]

Apart from the useful advice offered re portable libraries, gcc etc, make sure you do *daily* builds on each target platform from day 1 of implementation. Don't rely on a big bang port in 12 months time.

Re:Start cross-platform from day 1

[utoddl]

make sure you do *daily* builds on each target platform from day 1 of implementation.

I can't agree with this more. The one big source project I've been involved with was a year and a half long migration of a live MVS system to a mass storage archive on a ConvexOS UNIX system while both systems stayed up and in production. I was coding day and night, and the "at night" part included making the ConvexOS side work on my Amiga. (Picture for a moment putting 800,000+ files in 800Gb on an Amiga 3000. We obviously didn't do it, but not because the code wasn't willing!)

The ConvexOS and Amiga systems were different enough to make clear the distinction between those things that were part of the problem vs. those that were implementation issues on a given platform. By forcing me to keep the issues separate, we ended up with a much better product.

As our migration project was winding down, we took it to another university to help them with their MVS to UNIX migration. Their target UNIX platform was much more "normal" than ours, but the platform eccentricities were already abstracted out, and the port went very smoothly, largely because I developed the non-MVS side of the software on multiple platforms from day one. (Actually from about day 85, but day one would have been better.)

(Info about our MVS to UNIX migration is available at here.)

Commercial but good....

[Anonymous Coward]

Have a look at nutcracker. It's changed it's name recently but the product's been around forever. It will give you a consistant API for Windows/*IX development in C/C++/Fortran/Ada/COBOL

YOU MUST READ THIS!

[Electric Troll]

This article is another attempt to subversively convert more straight Slashdot readers into slashbots - homo toyboys, kept around for CmdrTaco's sexual forfillment. Let's examine the article and see why this insidious Open Sauce movement must be stopped at all costs:

"My brother and I were just commissioned to develop a large energy management system"

In other words, Cowboikneel and CmdrTaco get tired after too little anal sex and need a more effective system to manage their energy. This is no doubt due to them both being fat homosexual geeks. The only cure is to go outside, breathe the fresh air, excercise regularly, and stop taking men up the ass.

"Aside from the GUI, which we've already agreed to use QT 3.0 for"

Ever since qt was released under the GPL (Gay Penetration License), CmdrTaco's toy boys have been using qt more and more. qt, or Queer Technology as it is now known, was strictly forbidden before, as it did not allow RMS to have Gay Penetration with his Free Software ("Software" is a term for underwear designed for easy removal). It is a major loss for the straight community that qt has now 'come out' under the GPL. We must strive to find a straight replacement.

"we specifically are looking for cross-platform libraries for multi-threading, serial port I/O, and network I/O."

cross-platform, as I've already documented elsewhere is a term used to describe any object which will fit in CmdrTaco's, Cowboikneel's, and Homos's ass. It is truly a disgusting phrase.

multi-threading refers to the homosexual practice of inserting more than one object up a gay lover's anus. The anus has to support multithreading for this to be possible. Cowboikneel has always supported this, due to the enhanced size of his O-ring. CmdrTaco has not always supported multithreading, but after being impaled on Homos's huge cock multiple times, he has now managed to support it.

'serial port I/O' refers to the sick practice of in-line Gay Penetration. Because of the nature of this task, each lover must hold a Gay Penetration License. in-line Gay Penetration means Homos taking CmdrTaco who in turn takes Cowboikneel, who continues the line of homosexuality. Many homos will join the line. The record line length is two hundread and fifty seven lovers! RMS and ESR were involved, of course, as well as many other prominent Open Sauce leaders.

The nature of 'network I/O' is not known to me at this time. Although the intelligence gathering methods used to undermine the homopocalipse revolution are very advanced, no one has dared to enter a orgy in which 'network I/O' is going on and thus cannot give us more information as to the nature of this dark and sinister threat to our sexuality. Anyone who holds information on this matter is encouraged to let us know, even if it means putting their anal virginity at stake. This threat is of the highest importance and we must learn more about it.

In conclusion, The homopocalipse, which was once thought to be merely a figment of RMS's imagination, is now very very real. We must work persistently and diligently if we are to destroy this threat once and for all. Until such a time as a straight man may once again walk with pride, and not fear being taken up the arse by rabid slashbots, armed with cross-platform dildos, we must excercise caution. Do not trust anyone. Do not believe what you read on slashdot. Treat everything and everyone with suspicion. I must go now, I fear the slashbots have discovered the hiding place from which I am transmitting this warning. If I do not make it out of here and to safety, please continue my work. Do not rest until slashdot is free of RMS and his homosexual minions. I will go now.

Re:YOU MUST READ THIS!

[Anonymous Coward]

Cool. Free Speech. Did you have to waste it?

Threading/Serial/Network

[NitsujTPU]

Threading - It has been my experience that since various operating systems handle threads differently, your thread behavior will be slightly different on each OS, however, the threading code will remain the same. This code should be portable with no problems as long as you do it in a standard (ANSI, ISO that is) kind of way. The only problems that may come up are timing issues, but these are easily solvable (like a day of labor for a real brain stinger), and rarely come up as long as you didn't do anything unorthodox.

Network - Again, as long as you don't do anything funky, and just use portable ansi/iso code, socket programming shouldn't pose a problem. Dont' go below port 1024 if your program won't run with root permissions, as many *nix's will only let root access those ports.

Serial - Ok, this could be a nightmare, find a good library.

How amusing.

[Anonymous Coward]

Dude, you bill according to labor.

Life is too short to attempt to convert teenage geek idealism into calories and cocaine. Hello - it's only a program; no one is awarding medals for pedestrian custom apps.

Re:How amusing.

[Anonymous Coward]

I happen to agree with the corebreech's statement. You do have a responsibility to inform your customer of their poor design decisions. After showing the original post to two other software engineers at the company I code for, we all agreed that "...here comes another failed software project... i.e. train wrecking waiting to happen."

At the very least, I would suggest doing a cost benefit analysis to compare development cost on the target platform vs. the cost of developing a cross-platform version on NT & Unix. Include cost of libraries, testing, hardware and increased skill sets and I bet you will find it much cheaper to develop for your final target *nix. Most managers in my experience are brain-dead when it comes to software development, but money talks.

Good Luck

Re:How amusing.

[SEWilco]

Well, I suppose an app which is controlling the lights in hallways full of people who are walking around can be called a pedestrian app.

The homopocalipse will soon be upon us!

[Electric Troll]

This article is another attempt to subversively convert more straight Slashdot readers into slashbots - homo toyboys, kept around for CmdrTaco's sexual forfillment. Let's examine the article and see why this insidious Open Sauce movement must be stopped at all costs:

"My brother and I were just commissioned to develop a large energy management system"

In other words, Cowboikneel and CmdrTaco get tired after too little anal sex and need a more effective system to manage their energy. This is no doubt due to them both being fat homosexual geeks. The only cure is to go outside, breathe the fresh air, excercise regularly, and stop taking men up the ass.

"Aside from the GUI, which we've already agreed to use QT 3.0 for"

Ever since qt was released under the GPL (Gay Penetration License), CmdrTaco's toy boys have been using qt more and more. qt, or Queer Technology as it is now known, was strictly forbidden before, as it did not allow RMS to have Gay Penetration with his Free Software ("Software" is a term for underwear designed for easy removal). It is a major loss for the straight community that qt has now 'come out' under the GPL. We must strive to find a straight replacement.

"we specifically are looking for cross-platform libraries for multi-threading, serial port I/O, and network I/O."

cross-platform, as I've already documented elsewhere is a term used to describe any object which will fit in CmdrTaco's, Cowboikneel's, and Homos's ass. It is truly a disgusting phrase.

multi-threading refers to the homosexual practice of inserting more than one object up a gay lover's anus. The anus has to support multithreading for this to be possible. Cowboikneel has always supported this, due to the enhanced size of his O-ring. CmdrTaco has not always supported multithreading, but after being impaled on Homos's huge cock multiple times, he has now managed to support it.

'serial port I/O' refers to the sick practice of in-line Gay Penetration. Because of the nature of this task, each lover must hold a Gay Penetration License. in-line Gay Penetration means Homos taking CmdrTaco who in turn takes Cowboikneel, who continues the line of homosexuality. Many homos will join the line. The record line length is two hundread and fifty seven lovers! RMS and ESR were involved, of course, as well as many other prominent Open Sauce leaders.

The nature of 'network I/O' is not known to me at this time. Although the intelligence gathering methods used to undermine the homopocalipse revolution are very advanced, no one has dared to enter a orgy in which 'network I/O' is going on and thus cannot give us more information as to the nature of this dark and sinister threat to our sexuality. Anyone who holds information on this matter is encouraged to let us know, even if it means putting their anal virginity at stake. This threat is of the highest importance and we must learn more about it.

In conclusion, The homopocalipse, which was once thought to be merely a figment of RMS's imagination, is now very very real. We must work persistently and diligently if we are to destroy this threat once and for all. Until such a time as a straight man may once again walk with pride, and not fear being taken up the arse by rabid slashbots, armed with cross-platform dildos, we must excercise caution. Do not trust anyone. Do not believe what you read on slashdot. Treat everything and everyone with suspicion. I must go now, I fear the slashbots have discovered the hiding place from which I am transmitting this warning. If I do not make it out of here and to safety, please continue my work. Do not rest until slashdot is free of RMS and his homosexual minions. I will go now.

From someone who has used ACE professionally

[Christopher Bibbs]

It is quirky, a pain in the rear, time consuming, but less so than other cross-platform libraries.

I've used it in projects that required common threading, interprocess communication, and a few other things across NT, Solaris, HP-UX, AIX, and Linux. I point out all of the UNIX-like platforms as seperate entities because they all have enough quirks that you can't expect any given library to work across the board.

Oh, and to everyone that has been promoting ideas like "just use gcc" or "just use straight c++", maybe you've never worked on a large scale, long term project, but gcc is not the best option for an app that needs to be highly optimized and writting everything in c++ from scratch is a waste of time (that's why we have libraries in the first place). I'm not flaming here, just pointing out that you need to look at the bigger picture.

Re:From someone who has used ACE professionally

[RalphTWaP]

Absolutely,

As someone using ACE at the moment (well, in another screen). I can say that I've never found a more well-constructed cross-platform middleware package. You can find it here. In addition, the DOC group's TAO package provides a CORBA implementation on top of ACE that works really well for... well, those CORBA things *grins*.

One drawback when using any middleware package that I've seen is that you have to buy in pretty heavily to the package, somewhat adopting the development philosophy of the package's designers. With ACE that hasn't been as much of a problem (For instance, it provides a method of dispatching QT events) mostly because the underlying design is heavily pattern based.

On other fronts, I also continually find the Boost libraries to be very useful. They can be found here.

Probably the last thing to consider is that if you vary your development platform, you are likely going to be changing your C/C++ implementation--and they are not all created equal. Personally, I've found that the cross-platform availability and easy integration of the Dinkumware C/C++ libraries are pretty much worth the middle-of-the-road costs involved. Dinkum's located here.

Re:From someone who has used ACE professionally

[ciberbear]

but gcc is not the best option for an app that needs to be highly optimized
Hmmm, how about a kernel OS, or a bunch of other things.
Well for the libraries I agree, besides STL, there is realy nothing that is readily available.
And it is not enough. Oh wait, that was the original question (and also why I am reading this
thread)

Re:From someone who has used ACE professionally

[Anonymous Coward]

Hi,

I am currently using ACE as well (on Solaris) and I can agree that it's quirky, however it's also easy to use, and I find I don't have to adapt to ACE's programming filosophy too much.

What's more important, however is that it's thin (more on that below), fast and the support is absolutely excellent! (No I don't work for 'em).

I have little experience with the Windows version of ACE, but I would look into compatibility as I know ACE on *nix has a few classes that wrap some OS call you can use, but when the call fails you have to get the OS error yourself. This would likely be a porting worry as you cannot even be certain you'll get the same errno back on different flavours of unix, not even considering the Windows error retrieval methods (which do I use here? GetLastError or WSAGetLastError or...).

One more thing. I was involved in an effort to develop a library that would allow exactly what you want here: operating system independent application code, just using this library, allowing to build an application on Windows NT 4.0, Solaris and Tandem NonStop unix (a port to, say, AIX would require an estimated 4 hours :). And a bit thicker than ACE. This took years and years for lots of people, and it works pretty well, but I would advise you not to do this yourself. You'll likely miss your deadline if you try.

Oh yes, before you ask, this library is not available outside the company that built it, Ericsson. They do have all their telephone exchanges running on it though :o).

Bart

Re:From someone who has used ACE professionally

[Anonymous Coward]

Instead of using Dinkumware's libraries, try STLport. Using VC++, Comeau C++ & gcc 3.0 with STLport is less of a pain then Dinkumware.

Kylix ?

[Gallo Nero]

I would implement a web-based solution if possible. But if you're into client-side code why not use Kylix, I know it's based on Object Pascal but that's not neccessarily a bad thing!(Version 2 is out now I believe.)

"Combine Kylix with Borland Delphi 6,(TM) to develop cross-platform Linux/Windows applications." - Borland.

"Shoot some fish!" - Happyworm.

Use G++ and Common C++ and use #ifdefs liberally!

[Anonymous Coward]

Use Common C++ for the cross-platform serial I/O, network I/O and threading support. I strongly suggest you use G++/cygwin rather than MS VC++ as the latter has all sorts of minor incompatibilities. G++ does too, but at least it's cross-platform. If you do decide to go with VC++, there's a few tricks you can use to make it closer to standard C++, such as #defining for="if (0) {} else for" (do it in the project pre-processor definitions if you don't want to #include it everywhere) which fixes the for-loop control variable scope problem in VC++. Any point where you do anything remotely Windows-centric when you're coding, at the very least put a comment, or put a #ifdef LINUX (or whatever) and flag an error when you try to compile on the other system, or better, figure out how to do it on the Linux system and write that in the #ifdef.

It's very important to keep in mind that the system will be ported, and soon, otherwise it'll be a huge project to convert it when the time comes. It is probably worth doing things slightly less efficiently from the win32 perspective (use G++) so that the system can be easily ported later.

Good luck!

SWIG

[SimHacker]

Check out SWIG, the Simplified Wrapper and Interface Generator.

"SWIG is a software development tool that connects programs written in C, C++, and Objective-C with a variety of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, Python, Tcl/Tk, Ruby, Guile and MzScheme."

You can write your code as portable C++ classes, and then use SWIG to automatically read in the header file, and write out all the glue code to plug your C++ classes (or C libraries) into the scripting language of your choice.

-Don

Use XPCOM + XUL

[rfmobile]

Good morning! Write your program as a XUL application! Say what? Yeah, that's XUL (pronounced zool) ... The folks that earlier suggested NSPR are on the right track but they stopped short of taking advantage of the cross-platform GUI aspects of mozilla. Design you UI using XML - that's XUL. Write modular components in C++ using XPCOM - a cross platform variant of COM. Compile and deploy to just about any platform that mozilla runs on - and *that* my friend is a lot! The bulk of your app can be defined using a few text files (XUL compatible XML tags with some Javascript). You might not even need to write *any* C++ code. Besides the docs available directly on mozilla.org, here's a link to some stuff I wrote: http://www-106.ibm.com/developerworks/webservices/ library/co-xpcom/ Enjoy.

ACE Framework for all networked operations; boost?

[ivec]

If you find you need more than Qt offers for network i/o, treading and stuff like that, consider the ACE libraries:
http://www.cs.wustl.edu/~schmidt/ACE.html
They are free, proven to be extremely portable, and can come with a full-featured Corba implementation.
See also POSA2 book for background info:
http://www.cs.wustl.edu/~schmidt/POSA/

Of course, check out boost for another well-tested + well-maintained cross-platform C++ library:
http://www.boost.org/
This is better/more modern C++, but there may not be much space for it between Qt and ACE.

Now for the serial port... dunno, but shouldn't be too difficult to encapsulate that. You may find useful info at:
http://www.lvr.com/

Good Luck - Ivan

NT and POSIX

[Anonymous Coward]

One good thing is that NT is in the loosest sense POSIX compliant. That means, all the stuff like sockets, etc, work almost as you'd expect from Unix.

Use something like QT for GUI, or glut if it's a predominantly 3D interface, and you'll have something that starts of being fairly platform independant.

Use STL instead of MFC for storage. You may have to roll your own file loading/saving stuff, but don't try and reverse engineer the MFC stuff afterwards - it's not worth the hassle.

I started off writing a network-based game targetted for Windows as while back. Pretty much everything was standard POSIX with OpenGL as the user interface. Before I started in earnest on the UI, everything ran under Unix - in fact, I wrote plug-in UI modules, as I eventually planned to back-port to Linux. That never happened, but I did have a text console UI. This made debugging very easy, as you can run lots of clients at once.

If you're after socket stuff, check out the source for Xpilot. Not C++ style code, but it uses a library that you can look at to see some implementation differences between Unix and Windows.

Definitely do daily builds on both platforms, gcc is good for cross platform use. You can even set up your Unix box to cross-compile your Windows binaries. If you target POSIX, you shold be able to isolate all the Windows/Unix stuff behind an abstraction layer early on and forget about it.

Good luck!

kylix and delphi?

[gecko19scl]

I am no programmer but dont delphi and kylix have an interchangable code base?
Couldnt you write on delphi then recompile in kylix with little change to the source code?
Just a thought!

Gecko19scl
I havent lost my mind i know exactly where i left it!

Multi Compiler Multi Platform

[Anonymous Coward]

Use the MPMC ( Multi Platform / Multi Compiler )Rule from day 1 on. It will save you pain later. Even if you cant develop the whole thing on two platforms at once, write a small command-line app that does some test cases and includes all of your back-end sourcees and make sure it compiles on more than one platform and make sure you start using more than one compiler from the beginning. Especially for command-line apps its not much pain in the beginning, but it saves you plenty later. It also forces you to clearly divide between back- and frontend( Which has saved precious programmers lives more than once :-))

For libraries check ACE and BOOST.

serial io

[Psychopax]

Other people already said that QT offers multi platform network and threading support.
And this seems to be a multi plattform (linux/win32) library for serial port io.
HTH,
j.

Some ideas

[Charley's Angel]

For threading:
use the boost library, Boost.Threads

For network:
Use ACE

Port io is trickier; i am aware of a couple of free libraries for NT, which are rumoured to make things more like unix, butI have never really used them. look on google for dlportio and giveio.

Re:Some ideas

[mark_lybarger]

from what i've seen there are many reasons to avoid a broswer type platform. first, the widgets available on a browser are WAY too limited. a simple database maintenance application via a browser becomes painfull. can i get a grid control? a list control, etc without using applets? second, the interface lacks extensive interactiveness.

Compiler issues

[Anonymous Coward]

The most important thing is that you use the GNU tools on the windows side, as there are quite a few differences between Visual C and GCC dialects

Check out CYGWIN. I don't know about the network, but it attempts to implement a POSIX-layoer on top of windows....

Qt

[Lomby]

The Qt library offers cross-platform facilities not only for the GUI, but also for the network and threading code. The only thing missing is the serial port: this could be a bit difficult to do. To have an idea of the problems involved you may look at the Wine page: they have a lot of trouble emulating the Windows serial ports behaviour under Linux.

...

[Rakefighter]

I'm sorry...I really hate to be negative, but these requirements are really stupid.

I mean, really stupid.

Let me get this straight, here...You want to develop this app on NT, test it on NT, and migrate it to Unix after all this is complete? I certainly hope this isn't doing anything important, `cause that baby's gonna crash-and-burn like a mofo. when you bring up your Unix boxes for the first time.

First...get a clue. Cross platform development for the GUI is going to fucking suck. No, I take that back...Cross platform development alone is going to fucking suck. The GUI won't help, either. You can use third-party libraries, but that's code that you haven't written (which means you know very little about it). Not good.

Second...you're a fool if you think that you can build and test this on NT, and just port it to Unix a year later. If this is going to end up on Unix boxes, then that's what it needs to be built and tested on, from the ground up.

Third...grow some balls, and tell the people that want phases 1 & 2 on NT to fuck off. The right way (and the smart way) to do this is develop the app for Unix, test on Unix, and roll out on Unix. Testing on NT, and then porting to Unix 6 months later will do two things...Make you look staggeringly stupid when it doesn't work, and help you to understand that it's a terrible idea (TM) to build and test Unix apps on NT(!).

I know I'm repeating myself, here...but the nature of the question really leads me to believe that this needs to be rammed down your throat. If it's for Unix, build it on Unix, and test it on Unix. If it's for NT, build it on NT, and test it on NT. Build two separate apps, if you have to. I guarantee that it'll be smaller, better, faster, and cheaper than the spaghetti mess that you'll end up with at the end of your proposed project.

But hey...it'll be portable spaghetti.

Re:...

[Anonymous Coward]

...unless they use Cygwin on NT/2000. Works pretty well. Could save them considerable time.

Glenn

Re:...

[|DeN|niS]

First...get a clue. Cross platform development for the GUI is going to fucking suck. No, I take that back...Cross platform development alone is going to fucking suck. The GUI won't help, either. You can use third-party libraries, but that's code that you haven't written (which means you know very little about it). Not good.

Have you ever tried it? Have you seen QT? Yes, the same toolkit as used in the KDE project.

Try it on for size. Browse through the excellent documentation. Do everything from GUI to XML to file and network I/O to all kinds of data containers, cross-platform. QT is probably one of the best examples of GOOD, CLEAN C++. KDE knew what they were doing when they picked it.

I do recommend testing on all environments while developing, but you should end up with one code base (maybe a few ifdef's) by using QT well, barring only serial port routines (not in QT AFAIK) for which you can code the interface into your app and create different implementations for different OS's.

Really, it doesn't have to be this hard. QT is excellent stuff, develop cleanly and you should be just fine.

Re:...

[Anonymous Coward]

Right on brother

Just tel them that doing two versions wil cost them 4x the price for doing it on unix!

Re:...

[spitzak]

Damn right. Management is lying to you, pretending to obey your request that this be done on Unix.

Insist that there be at least one production machine running Unix right now so that you can test the cross-platform capability. Do all your development on that machine.

If you start out this way doing it cross platform is not too much difficulty. You have to write every bit for both platforms at once. Otherwise you will have a porting nightmare later (this can also happen if you write for Unix and try to port to NT). Try to encapsulate the differences to as small a part as possible. Put the differences in header files, try to use macros or anything there so no ifdefs are needed in any of your source files.

I recommend using Qt and the cygwin header files (like libstd) on NT. Use the Unix versions of all calls. Try to avoid needing the cygwin libraries, though, they are slow.

Things like threads are not too much difficultly if you limit yourself to the common abilities of both systems. You don't want the weird features of pthreads (or Win32 threads) anyways. You can put a lot of macros in the header files so there is no time wasted. Linux supports recursive locks even though pthreads does not, it is a good idea to use these to match how Win32 works. Look in the linux pthread.h header file.

Absolutely do not release anything unless you have a working executable with identical behavior on both platforms.

why not java?

[theridersofrohan]

And why did you discount java? Unless you're forced to use C/C++, you can code it in java, which provides well tested libraries... You can even compile it to native code if speed is such an issue...

makes sense

[Anonymous Coward]

This is really wort considering, I've been experimenting with XUL a little and i have only good things to say about it so far!

wxWindows

[Anonymous Coward]

Check wxWindows out http://www.wxwindows.org/, cross platform gui, i/o. Works under *nix, win32, os/2, macos etc

ACE

[sverdlichenko]

I'm using ACE for this purpose, and it really works.

STL, BOOST, AND GOOD DESIGN

[patazathoth]

Use STL whereever you can.

Use Boost, www.boost.org, for platform independant threading. BTW, this threading platform code will probably make it in the next version of C++ since boost is run by member of the c++ comitee.

Use a good design. Code the logic in a platform independant way and abstract what is platform dependant.

Pat

ZooLib

[bartman]

ZooLib allows one to write a single set of C++ sources which can be compiled into native executables for Mac OS, Windows, BeOS, or POSIX-compliant systems that use the X Window system (such as Linux).
- freshmeat.net/projects/zoolib

exactly

[joss]

You are so right. I've been programming java on and off for 6 years (on again at the moment, server side, marketing decision...)

My main problem with java is not the speed of execution (although that's still a problem). It's the ton's of superfluous shitty code that seems to get generated in any java project.

The flaws you mention aren't even the main ones IMHO - lack of MI (no, interfaces are *not* as good, eg EJB programming wouldn't be quite so cumbersome if the methods one needed to overload had default implementations) and templates is even more irritating. Then there is the stupid overuse of try/catch blocks because the style encourages this, leads to local error handling code all over the place and defeats the whole purpose of exception. The lack of enums is unforgivable too, aargh... And then Swing - good god, what a piece of shit. Try FLTK instead, to reduce code size by factor of 4 and increase speed by factor of 100.

Glad I'm not the only one who feels this way..

Re:exactly

[tjansen]

Then there is the stupid overuse of try/catch blocks because the style encourages this, leads to local error handling code all over the place and defeats the whole purpose of exception.

Even worse IMHO is the lack of stack-allocated objects. The garbage collection does a good job for memory management, but it does not help for other resources (like database connections that must be closed). So you clutter the whole code with try/finallys, and it is soo easy to forget one of them and get errors that are REALLY hard to find because they only happen very infrequently.

Re:exactly

[big_hairy_mama]

Forgetting a try-catch is not a problem -- worse case is your program crashes and you get a *nice* stack trace telling you all the state you need to do some debugging triage before pulling out a real debugger. More often than not, the error is a simple NullPointerException and you can trace down the offending variable simply by looking at the line number provided in the stack trace.

The bigger problem is *overuse* of try-catches, in which errors are caught and not rethrown or at least .printStackTrace()ed. Then errors become almost impossible to track down. But this is much simpler to avoid than if the problem was *forgetting* the try-catches, since all you have to do is not do that.

Re:exactly

[tjansen]

Forgetting a try-catch is not a problem -- worse case is your program crashes and you get a *nice* stack trace telling you all the state you need to do some debugging triage before pulling out a real debugger.

No, I had such a problem last week: in certain situations the app did not close the Database connection. There was only a limited number of sessions available in the pool, and after the situation occurred n times (where n is the size of the session pool) opening a new connection caused the app to freeze - because it would wait for a new connection. As it happened in a small application it was relatively easy to find out at which place the close wasn't called, but in a large app I could have searched for days...

Re:exactly

[big_hairy_mama]

You're right, I shouldn't have said "worst case". But difficult problems like yours are much less common than in a situation where there are no checked exceptions at all -- you could write a large section of code without realizing that an IOException could be thrown inside, and then you'd have to go back and update each affected method call. Yes you would get a nice little stack trace, but, as you pointed out, even still it can be hard to debug.

wxwindows

[Anonymous Coward]

i'd recommend wxwindows (http://www.wxwindows.org)

it's a cross-platform c++ gui toolkit (other language bindings exist), which acts as a wrapper around the native toolkits (mfc on windows, gtk/motif on unices, platinum on mac, etc.).

it also provides a couple of other nice, platform-independent classes for string-handling (yet again?!), networking, odbc, etc...

if you use it, be sure to check out the cvs version. it's reliable enough and has a lot of features that can't be found in the tarball.

Now, for something different

[Anonymous Coward]

I m just starting to discover a little perl called rebol, now that stuff support tons of network protocol natively and run on dozens of platforms, i don t know about serial i/o but the rest look absolutely astonishing. maybe it's worth a look.

Learned Lessons (and ACE)

[awol]

Back in the early nineties when no such thing existed (or at least that was findable), the company I work for wrote such a beast as the library of which you speak. It provided; sockets, threads, forks, mutexes, shared memory, config file handling, to name a few. The reason for the library at the time was that the client was dos and the server was *nix but we wanted the layer on top of this library to be source code identical.

We still use it today. It is good (and better than it was then) and very helpful. However we have started using ACE (as mentioned by some other posters) and it is also good. Much more extensive than our system and if we were starting now we would certainly not write our lib but use ACE from the get go.

So there you go. I reckon go with ACE.

Stick to POSIX and ANSI C as much as you can

[forged]

Virtually all UNIX platforms out there are compliant to some POSIX standards to some degree. Linux is, and Windows NT and derivatives are.

With POSIX and ANSI C, you should get 95% of the portability issues out of the way. Keep the 5% remaining in architecture-specific files through a common API, and you're done.

The Linux Kernel is a prime example of ANSI C code which works on a multitude of very different hardware platfoms.

Thank you Linus.

Squeak

[Anonymous Coward]

Use Smalltalk! THE most ported language!! :) Just kidding ;)

Reverse portability

[Anonymous Coward]

Perhaps a better idea is to develop on Unix and port to NT. NuTCracker provides a porting environment that supplies the proper POSIX environment on NT, complete with sh, make, etc. This works very nicely with C (we've done it) but I have no exp. with C++.

For Network IO, try CORBA. omniORB from AT&T is a nice implementation, and Mico is reasonable as well. It'll be standard, the IDL's are nice, and it'll work cross-platform and between platform (i.e. NT client, *nix server, etc.)

Re:Reverse portability

[Anonymous Coward]

NuTCracker provides a porting environment that supplies the proper POSIX environment on NT, complete with sh, make, etc.

As does cygwin (free) or interix ($100, proper kernel-level integration with NT).

On What?!?

[mrfiddlehead]

An energy management system, for serval colleges, running on NT? I'd recommend sweaters in the winter and bathing suits in the summer.

Forget the NT portability requirements and write it for Unix. If you absolutely must run it under NT then perhaps Cygwin would be an alternative.

One thing you don't mention is whether you're writing a GUI or not, in which case I'd write a wrapper gui rather than an integrated GUI with IPC to deal with I/O. As others have mentionned serial I/O is a pain in da arse under Windows (it's a security issue, doncha know) but I'm not sure how cygwin deals with this issue.

Recommendation number one. Convince them to install Unix/Linux/Gnu/RMSIAI.

Embed Python!

[reachinmark]

Why not embed python in your application? Python has already addressed the majority of platform differences for serial I/O, network I/O, threading, etc. That way you can use your own C code and Python C functions for all of the time-critical operations, and parsed Python for the less time-critical ones.

Python can also speed up application development, letting you prototype stuff without recompiling. You can compile fragments of Python code straight into your C code when you have got it working. You can make use of Python's httpd module, xml parsing module, etc, etc, etc. There is a lot on offer there.

And.. best of all, Python doesn't suffer from any form of restrictive licensing either! We use Python extensively in our commercial applications and it does make a difference to development time.

wxWindows

[Anonymous Coward]

hi!

i'd recommend wxWindows (http://www.wxwindows.org). that's a free (GPL, i think) cross-platform toolkit, or rather, a set of wrapper and supplementary classes.

meaning, it'll use mfc on windows for displaying your application, gtk or motif on unices, etc, etc...

the supplementary classes contain some network stuff, odbc client classes, yet another string class, config classes (using files or the windows registry), etc, etc.

the documentation isn't that terrific, though, so there's a lot of guessing. and i'd download the cvs version, as that is pretty stable and contains a lot of features you'll be missing in the stable tarball.

If you haven't tried to port it, it's not portable

[Dr. Manhattan]

I wrote a non-GUI background app for my company that runs on about six flavors of Unix and VMS as well. I ported about 60% of it to Windows as a knock-off project to help solve a customer problem. Writing portable code is possible, but difficult.

The key thing is that you must develop for at least three platforms from the start. My initial work was on Solaris, Linux, and VMS. This allows you to find (most of) the inconsistencies early and design around them before they get too embedded in the project to ever change.

You also need to identify what things are very likely to change across platforms (in my case it was threads, networking, and file I/O) and abstract those out from the start. Write wrapper functions and use them. Actually, I wish I had wrappered more of the output functions; as it is, the app's a little too dependent on ASCII. Given a few wrapper functions I could easily have supported EBCDIC and Unicode; now it'd be a bear to add that.

Stick with anything ANSI, and POSIX is good. C++ still hasn't finalized everywhere, not like ANSI C. If you write in ANSI C it works darn near everywhere. Windows doesn't do POSIX threads natively, but if you aren't doing anything really weird, wrapper functions can handle that. (All I needed was threads with default stack sizes, and mutexes.)

Not that all the Unixes are the same. AIX in particular has some non-standard silliness in its implementation of pthreads. A comment from my code:

/* AIX documentation is incorrect and its threads don't follow the standard, we have to explicitly declare that the threads aren't detached and can be joined. Worse, they use the nonstandard "PTHREAD_CREATE_UNDETACHED" constant instead of the standard "PTHREAD_CREATE_JOINABLE". */

A few #ifdefs can take care of things like that. But really, really, really: Port from the start!

For the GUI part of it, make a separate front-end app. Use something portable for that; a library or Java or whatever. Speed is hardly ever a problem for GUI front-ends. Just make it simple and reuse as much code as you can between platforms.

Use the NSPR - Netscape Portable Runtime

[DrXym]

This is a cross-platform C lib and networking runtime. It's production quality and free. See mozilla.org for more info.

try POSIX, which is what most real Xplat is now

[Anonymous Coward]

Try POSIX

I'd recomend ACE too

[hugui]

At work we've been using for a couple of years ACE with excellent results. It's prepared from the ground up to deal with networking, multithreading, concurrency, etc, it's extensively cross-platform, open-source, cost-free, there's QT support ( although I've never used that part ), etc.
I don't agree with some of the comments that say that it's cumbersome and difficult. It's extremely simple to use, and because of the massive use of patternas, you can concentrate in what is your application supposed to do instead of "How can I spawn three thread that communicates with each other, one services a FIFO queue, the other connects t a server and the last one serves a TCP socket?". ACE handles all of that for you.
We work with Solaris, pSOS, Win32 and vxWorks, and our code compiles in each one of these platforms without a glitch.

http://www.cs.wustl.edu/~schmidt/ACE.html

STL? Yeah, right...

[Dr. Manhattan]

Our group inherited some code that used the STL throughout. The authors thought they were doing things portably, but they just wrote a Solaris version and never tried any other platforms.

Porting it to HP-UX was a headache; the STL's on the platforms differed in a multitude of subtle ways. AIX has been even harder (there may be something good about AIX, but I haven't run into it yet).

The STL seems to be about where C was when the ANSI spec first came out. It took several years before code was really portable...

Re:STL? Yeah, right...

[alyandon]

One way to get around the various vendor differences in STL implementations is to use somethings like SGI's STL port on multiple platforms.

http://www.stlport.org

POSIX, baby

[Anonymous Coward]

How do the software mongers in telco
industry do crossplatform communications?

The put a very thin #define wrapper around
POSIX calls.

You pay them for their interface which
you could have done yourself in very short
order.

And then you keep paying them subscription
and they keep doing as little as just wrapping
POSIX in thin #define macros.

And the 'interface' that you buy from them
is mostly deprecated and worthless.

But your managers don't know this and they buy
it anyway.

POSIX is what it is despite what the
software mongering telco stack people tell you.

They have no stack, they use whatever is
there and wrap it in #defines.

And you pay them the 1/2 million dollar
license hoping to be bought out before
anyone else figures out the fraud.

I've seen it over and over and over.

Java can interface with C using the JNI

[Anonymous Coward]

The obvious solution to these weird requirements is Java. Often, Java apps are developed on NT and deployed on Unix. If it is necessary to interface with C libraries, just use the JNI. Since it takes so much longer to program in C/C++, there would have to be a compelling reason not to use Java.

C/C++??

[graybeard]

I see this all the time. What does it mean? It's either one or the other.

That's like saying "awk/perl" or "vi/emacs".

Re:C/C++??

[Anonymous Coward]

C is completely compatable with C++.
That means that all C code is valid
C++ code. No, it doesn't use
objects and STL and all the stuff that C++
is all about. However, it will be
much more deterministic then C++ would be.
For boot code and for real-time C is a better
choice than C++

C really is a subset of C++. Thus it is
correct to say C/C++

Re:C/C++??

[Archanagor]

Yes, but, not quite ...

Not all C code is valid in C++.

In C, for example, this code is perfectly valid:


void main()
{

int *pi;
void *pv;

int i = 31337;

pv =
pi = pv;

}


You must cast pv to an int in C++

C++ is really just a superset of C. Not the other way around.

Use Generic Programming Techniques

[fizban]

Since you're coding this thing in C++, then you have a prime opportunity to use generic programming techniques like abstraction, encapsulation and template program to hide all platform specific code.

For instance, rather than coding using the native windowing system, wrap and generalize the window functionality in such a way that you can code your client code using a generic object. You might have objects such as:

class generic_window
contains class generic_window_impl pointer
class win32_window : public generic_window_impl
class xwin_window : public generic_window_impl

The client would create an instance of generic_window, which would set it's member implementation object to the correct native window manager based on what platform you were on. Then you can generalize the callback functions, by providing a callback_register() function in the generic_window class that takes a generic_callback class as it's parameter. The generic callback would be a "functor" object that gets called by the native window object when it receives a native window message.

Basically, just create your own generic libraries! But if you're a good c++ programmer, then you already know this.

Otherwise, definitely use STL for all your data containers and searching algorithms. Use the Boost library (www.boost.org) for other useful generic classes and algorithms.

I don't think 6 months is enough to make a completely generic product, but if you constantly remind yourself to program generically, even if you're only providing windows functionality at first, your porting efforts will be MUCH easier a year from now. Encapsulate ALL platform specific code.

Mainsoft, WxWindows

[cheeni]

There is MainSoft, which has worked in the past with Microsoft to port the Win32 API to various *nix platforms.
<p>IIRC, IE for Solaris was created using this.
<p>Have a look at this <a href="http://www.mainsoft.com/flashdemo/mainsoft.s wf" target="_blank">flash intro</a>, hmm.. reminds me of those teleshopping ads...., funny but informative. For best effect open it to full screen.
<p>Also look at <a href="http://www.wxwindows.org/">WxWindows</a>. They say it supports network programming, well atleast it's free.
<p><b>Caveat: </b>Mainsoft is $$$_expensive_.

Target Unix

[Anonymous Coward]

So, by the sounds of it the customer is going to be throwing out your NT version in 12 months or so.

To me, makes sense to write it as Unix-like and ignore NT as much as possible. I would suggest using Cygwin on top of NT/2000 (a unix compatibility layer, more or less), which includes standard GNU tools. There are some licensing issues with proprietary apps and linking against libcygwin.a (ie, you have to buy a licence), but it may be worth your while to pursue it. Or, try convincing the company to install Interix on their NT/2000 machines - it's basically Microsoft's own version of a Unix subsystem, and it's not horribly expensive (MSRP is US$100).

portable CORBA and threading: omniORB

[matthew_gream]

For portable CORBA and threading support, try omniORB (http://www.uk.research.att.com/omniORB/omniORB.ht ml). We use it for seamless portability between NT4.0 & Solaris components and its very effective.

Take a look at ObjectSpace

[Tomster]

We have a set of C++ toolkits which should do a lot of what you need, and support a variety of platforms, OSs, and compilers. They've been around for a long time, are very stable (they have been used in mission-critical software) and are a lot cheaper than Rogue Wave's tools. Go to ObjectSpace for more.

Re:Ummm... POSIX? BSD Sockets?

[Sir Runcible Spoon]

It does. However, things that run in the POSIX subsystem are unable to use those nice POSIX calls to access anything that is outside the POSIX subsystem. This typically includes everything, even bog standard features of the OS. When I was trying to port a UNIX app to NT some years ago, POSIX did not include some basic things like signals and common socket stuff, it certainly didn't give you any graphics. Consequently the POSIX subsystem at that time didn't provide them or even the WIN32 equivalent.

There was a rumour that MS didn't want anyone to use the POSIX subsystem. It seemed to be there simply to get a tick against the "Does it comply with the POSIX standard?" checkbox on corporate/governmental buyers requirements list. Once the sale is made, the POSIX subsystem is of no further use.

We eventually ported to the WIN32 subsystem using a toolkit called NuTCracker. It sort-of worked, but we eventually ended up doing a native port by abstracting out all the OS sprecific stuff.

There are other options to be considered. There is UWIN - http://www.research.att.com/sw/tools/uwin/. There is also the CYGWIN stuff (which seems to include OpenGL) which you can get at http://sources.redhat.com/cygwin/ (you might also need the extra CYGIPC at http://www.neuro.gatech.edu/users/cwilson/cygutils /V1.1/cygipc/ to do ipc).

Do a Cost Benefit Analysis

[Anonymous Coward]

I happen to agree with the corebreech's statement. You do have a responsibility to inform your customer of their poor design decisions. After showing the original post to two other software engineers at the company I code for, we all agreed that "...here comes another failed software project... i.e. train wrecking waiting to happen."

At the very least, I would suggest doing a cost benefit analysis to compare development cost on the target platform vs. the cost of developing a cross-platform version on NT & Unix. Include cost of libraries, testing, hardware and increased skill sets and I bet you will find it much cheaper to develop for your final target *nix. Most managers in my experience are brain-dead when it comes to software development, but money talks.

Good Luck

Black Windows Of Death

[SEWilco]

NT servers seem to crash often. Can you tell us what colleges, so I can avoid having my children wandering around halls whose lights are controlled by NT? I'd also like to donate some candles to those colleges.

Re:Black Windows Of Death

[Anonymous Coward]

Your NT servers chash often? Maybe you need to read a bit, or perhaps hire someone that knows what they're doing.

Re:Black Windows Of Death

[Anonymous Coward]

Your NT servers crash often?

Not mine. I don't have any, mine are all Linux. But everyone else's NT servers crash all the time.

Re:Black Windows Of Death

[Anonymous Coward]

for some reason my school is moving from solaris machines as a mail server to an exchange server. I'm still trying to figure out why. Oh well, I guess now I'll just have to set up my own mail server.

Re:Hey! Don't confuse Java with Lisp.

[Anonymous Coward]

This may have been a troll, but its the funniest goddamn troll I've seen in a long time. I nearly wept. It was better than Cats.

Use a Cross Compiler and 2 Targets

[Canyon Rat]

When I need to code cross platform I start with a cross compiler and two targets. That way I know with every build whether I'm getting platform specific and it's easy to isolate the platform specific stuff.

Check out Metrowerks compilers for cross platform stuff.

Some ideas

[f00zbll]

Obviously you can't go into details about the application you're building, but from what your post tells us there are a few questions you might want to ask yourself.

Alot of people have already mentioned some great points and specifics about threads, I/O and other platform specific issues to consider.

If I was in the position to build such an application I would ask myself the following questions. I'm assuming the application is hitting an existing server which has proprietary API.

1. can the UI be a browser? If not why? If so, what limitations exist and would those limitations ever become an issue?
2. Assuming browser could work, how can I create a generalized middle layer that will allow me to use either browsers or custom GUI?
3. Assuming browsers wouldn't work. Is the scope of the project too ambitious and not modular enough?
4. Are the limitations/requirement of the UI a result of design flaw?
5. Have I totally mis-understood the problem and approaching this the wrong way?
6. Should I limit the user interface to just windows and unix?
7. are there too many platform specific items in the requirement?

Since there's very little details about what kinds of system the application will hit, it's all guess work at this point. But, if I had to come up with a flexible architecture for an energy/utility grid for a couple universities, I would consider doing the following.

1. reguardless of what ever API the systems have, I would build a middle layer that uses MVC style architecture heavily. The middle layer would normalize all the communication between the different systems. Say you have 4 different types of system to interface with and they all have different API, normalizing all the API into say RDF or another XML format will save you a lot of headaches. Create a solid set of interfaces, factories and managers.
2. use a markup language to communicate between the middle layer and the GUI. this will allow you to use browsers in the early phases of the development and move to a custom GUI later on. This will also save you headaches when some one tries to view from AIX, IRIX or VMS.
3. assuming there are some realtime aspects to this application, using an asynchronis design like publish/subscribe is a good way to go.

Of course this is all hypothetical and could just be garbage.

Prototype in Python - Real System

[Anonymous Coward]

My suggestion: Prototype in python if at all
possible. Say "This is just a prototype so we
can check out the screens with the users". Get
as much going as possible. Make sure performance
is ok. Then say "Suprise, We're done. And so
is the port."

Two very good libraries

[SerpentMage]

I have gone through this myself very often and there are two REALLY good libraries. Ok they are not C++ based, but I really like them.

The first is NSPR (Netscape Portable Runtime). I used this in a few projects and NSPR worked wonders. The other one is APR (Apache Runtime). I am working on an Open Source C++ Apache server framework and have to say I love it. I am so interested in the APR solution because it uses resource pools, which mean that I do not have to worry about every pointer being freed. The resource pools handle this automatically.

If you want more information about APR stuff feel free to email me. Just take the obfuscated email address apart.

C Builder

[rhost89]

is your best bet, that is if you can wait. And even know it will be a 1.0 on the *nix side, by the time you are done developing it their should be a update or a upgrade. You should be able just to copy the src over and build on the win32 system without any problems.

Test, test, test!

[Anonymous Coward]

You need to test everything, all the time. Unit testing is going to be SO critical for you. You need to set up a test center with a set of machines running each OS you will be porting to. You might even want to hire a good tester, I'm sure you could find an out of work one around somewhere.

Try....

[dorker]

Object Pascal. It's what my company uses for cross platform development.

Visual MainWin from Mainsoft

[jalilv]

Try Visual MainWin from Mainsoft . This tool claims to make porting from Win32 to Unix (including Linux) very easy with little or no code change. It is said that M$ provided Windows code to Mainsoft to develop this tool. This tool is not open source though. Also, I haven't personally used this tool but will like to hear experiences of those who have.

- J

Re:Visual MainWin from Mainsoft

[rootmonkey]

I'm currently using MainWin to port to AIX. I have had many problems with MainWin, including legit bugs that I uncovered for Mainsoft. They won't accept it as their problem till you prove it for them, this is very difficult and time consuming. Not everything of the system you are porting to is imlemented and you'll have to pay a hefty price for them to add support for it. Also bugs in their libraries vary between the nix's. On top of all that throw GUI and threads and your app will regularly lock up. IMO MainWin is fine for small projects but its not worth the headache.

Re:Visual MainWin from Mainsoft

[MeerCat]

I'd agree, but take issue with your last line.

If you have a large GUI app written primarily for Windows that you need a relatively quick port to *nix (but be warned - it will take time) - then MainWin (and the old Wind/U) are reasonable stop-gaps, but if you have a new project where cross-platform is your aim, or you want to move the entire project away from Windows to *nix, then choose another route.

My comments on "other routes" will appear at the relevant spots in the other threads ;^)

T

Try the Apache Portable Runtme

[James Youngman]

The Apache Portable Runtime has good cross-platform I/O, threading and networking support. Plus you know it will have been tested in a demanding environment (Apache!)

Why make it cross-platform?

[BillyGoatThree]

Why not just start out on Unix? I mean, think about what you are saying. Develop on NT, test on NT for 12 months, run on NT for 12 months...then switch to Unix. Why not drop the superfluous OS and go straight to Unix? If UI is an issue, build a portable UI (in Java or whatever) they can run wherever they want.

Re:Why make it cross-platform?

[ameoba]

Here's one.. write the original app for Linux (or BSD or whatever) and then use VMWare or something when it needs to be deployed on NT/2k. You get the benefits of being able to run on multiple platforms and only writing the code once, while only slightly extending the testing cycle.

I guess you could work the other way, and start writing for NT, and making sure it runs under WINE, but since this is slashdot, I fig'd targeting Linux would work best (IE get modded up to a point where anybody will read it).

Re:Why make it cross-platform?

[Anonymous Coward]

VMWare ends up costing you $300/seat at runtime. (Not to mention the serialport and other low-level stuff the app needs to do.)

does the customer understand the issues?

[guitarrista]

Your question doesn't explain why the system has to run on NT first, and then later switch to *nix. Also, you said you'd already agreed to use some specific package for the GUI. Why?

I'd guess that, like many on many projects, the technical questions won't be as hard to answer as the questions about the exact requirements.

But, whatever technical strategy you adopt, be sure to test, on both platforms, early and often. Some sort of automated test suites would be ideal.

Use Qt

[MrDog]

I am developing a cross-platform OpenGL scientific vis application in linux, and using the Qt library, I can cvs checkout my code on my WindowsXP laptop under Cygwin and create an executable without changing a line of code. You do have to buy the Qt license, but I have found the cross-platform ease to be worth it. My app uses networking, but no threading or serial communications. You don't really have to use Cygwin --- Qt's make system can generate msvc project files, but I am just more at home with the command-line.

Beware SWIG

[slim]

SWIG looks like it'll be great when it's done.

However I recently downloaded the SWIG based OpenSSL Python bindings (mtcrypto) and on my first attempt the build failed because the SWIG syntax had changed between releases. I would advocate not using SWIG for anything important until it stabilises.

The SWIG homepage appears to back me up here: "
SWIG is currently in a state of redevelopment in which substantial parts of the system are being reimplemented. This work can be found in the SWIG1.3 series of releases. If you are concerned about stability or are a first-time user, you may want to download some variant of SWIG1.1 instead. Caveat--SWIG1.1 may not be compatible with recent releases of certain scripting languages such as Perl 5.6 and Guile."

If you're asking such questions...

[jamieo]

If you're asking such questions, and you've made such commitments, you're fu*ked.

Do you really need to do this in C/C++? How much UI does it have? Does it run as some kind of server process? Unless people know all these kind of things about your project (and you didn't say much at all), you can pretty much discount what they say as it will just be speculation.

The quickest UI's to develop are web based ones (they're often the most simple).

For back end stuff, look at something like perl.

Complicated UI's, Java/Swing - at this stage I'd say you're committing to doing something too complex.

My guess is, you'll put a lot of work in on this (more than you think), you may get something written that does the job, you won't be happy with what you've done, but you will learn a lot (mostly non-technical about how you approach such a project).

Try to have fun though.

Java is great for disposable transaction systems

[Anonymous Coward]

Anything that involves stateless transaction processing where it does not matter if a process crashes - Java is fine. If you need a long-lived scientific application doing quantitative analysis - Java simply is not good enough (too much memory, too slow).

GTK+ rocks :-)

[Anonymous Coward]

why not GTK/GLIB? 1.3.x is coming along quiet nicely... native windows/*nix ports... developed by the community, for the community ..not by a single company sure redhat support GTK+/Gnome, but hey dont own it.Its always been under LGPL/GPL, none of this QPL-hybrid shit.

Trolltech still fully control QT on non-linux platforms...why cant QT be open on every platform?

I'll never trust trolltech.

Re:GTK+ rocks :-)

[Anonymous Coward]

Troll.

I'll never trust a company that wants to use "Community Good" for its own personal gain (same as GNOME) ..also known as fuck thy neighbor.

I guess that's the beauty of Open Source(TM). I can take a big shit on you, and so what right? Go back to working long hours now so I can exploit your hard work for my gain.

From someone who also has used ACE professionally

[Svartalf]

Indeed.

And TAO that sits atop ACE, providing a real-time capable CORBA ORB atop it can't be beat either. Its use is less quirky than ACE and made possible a massively distributable financial and access control system that is in use at DFW International Airport and other locations. This system runs on both NT and Linux, with exception handling, etc. across both platforms working well.

exactly wrong

[Anonymous Coward]

You are so right. I've been programming java on and off for 6 years (on again at the moment, server side, marketing decision...)

hmm... let's see, Java was first shown at a trade show in 1995 by Bill Joy and James Gosling. It was at least another year till applets started appearing on the net.
Since its only 2001, you mean to tell me you worked for Sun's Java development team?
Bullshit - just like your opinion that Mutilple inheritance is a good thing.

Look, MI might be good if you're some 31337 haX0r who's code will never have to be looked at, but if you get paid to code(God help us) then you would realize that the clusterfuck of MI eponentially decreases the maintainability of a project.
Do me a favor, try charting out some of the objects through a UML diagram on a project that uses diamond shaped.. excuse multiple inheritance. Unless you wrote it, you'd be rotating the printout in all directions and scratching your head trying to make sense of it.

Re:exactly wrong

[tjansen]

Depends on how you use MI. There are certainly bad uses of MI, like you can misuse almost every feature. But there are also good ones, and he mentioned one of them: "interfaces with default implementations". They won't be more difficult to read than a UML diagram with regular interfaces, only with less duplicated code.

Re:exactly wrong

[UnknownSoldier]

> Bullshit - just like your opinion that Mutilple inheritance is a good thing.

> Look, MI might be good if you're some 31337 haX0r who's code will never have to be looked at,
> but if you get paid to code(God help us) then you would realize that the clusterfuck of MI exponentially decreases the maintainability of a project.

I think you're missing the point of MI: MI should be used to inherit interfaces.

Don't throw the baby out with the bathwater, just because you can't see the usefullness of a language feature.

Re:exactly wrong

[joss]

Yeah, well, fuck you.. I have been using java since 0.9 was available for download. I was using it before any books on the language were available. Also, I did have aquaintances who were in the early java implementation team. No, I didn't work for Sun, I co-founded my own company instead.

Just because you're too stupid to be trusted with MI doesn't mean everybody is. Yes, MI as implemented in C++ makes it easy to get your nickers in a twist, but the argument that things shouldn't be allowed because morons might abuse them is one of my pet hates. It's fine for school kids just starting out, this is what pascal
was designed for. Java is like an OO pascal.

Re:exactly wrong

[Anonymous Coward]

In a previous post you admonished Java for lacking enums, yet in this post you bash Pascal. I just find that humorous, given that the modern C++ implementation of enums is pretty lame compared to Pascal's from 15+ years ago.

Re:exactly wrong

[flux]

Yes, they are used for interfaces.

But what happens, when you want to create a 'smart' interface? Say I want a class Nameable, that can carry a name. But as it is a pain in the ass to recreate the trivial naming code in every class that wants to have a name, you decide: "Hm, wouldn't it be handy, if the constructor could take the name as an argument, and the getName-method just serves that?"

Well, guess what (which I guess you already knew but just somehow avoided to mention): you can't do that. Interface cannot have code. Of course, you can inherit from the interface the common implementation, but then you can't MI anymore.

You can see this 'feature' in action in some Java runtime library classes too.

There is one (but only one IMO) nice feat in Java interfaces: they provide better documentation for the reader. You read the file, and see 'ha, interface!', but with C++ you just have a class that might not even have abstract methods. This you must then combat with commenting.

Commenting in itself is not bad, of course, and is encouragable, but I see programming languages not only as a way to tell the computer what you want to do, but also tell other programmers. Commenting is not as good as (clean) code, as the comments and the code tends to go out of sync some time. Of course, if you only have an interface, how good it ever might be, there'd better be some comments :). Not much code there..

Re:exactly wrong

[Anonymous Coward]

The problem you illustrate with your "Nameable" example is legitimate but the proper way to solve it should not require the ugly complexity of MI. Perhaps "Aspect" programming will be a good solution.

QT, Java and Kylix

[free2create]

I definately agree. Use Kylix I programmed with Delphi for 4+ years full time. I was a wonderful system. I have been programming with Java/JSP/jakarta-struts for about 14 months now and it is by far the most primative environment I have developed in for years. Developing GUI's and Database applications take about 10x longer. Also if you are familar with Java then Kylix would be a snap, if you used Object Pascal. It is a very beautiful language. There is also the C++ version of Kylix. It's gui system also uses QT at its base ! Why did I stop programming in Delphi ? It was more a decision to leave my old job, than to switch languages. I wanted to expand my experience. I could produce pretty complex database applications,20 + tables, reports, help files, with a good look and feel in just 3 to 4 months of development.

Bollocks

[Anonymous Coward]

(while (= lisp stupid_language)(No Java/VB faggot is going to be able to do even the simplest arithmetic (+ (they'll get confused))))

(Lost In Stupid Parentheses)

Db connections

[rootmonkey]

Get wrox's book on Java Servers. They have a good implementation of socket pools for databases. I've used a similiar pool and pool manager in production and it worked great. It will take care of bad connections. Also wrap the result set too, catch all the exceptions in that wrapper so you don't have to constantly be typing try..catch everywhere. Great for websites IMO especially if you use them with servlets. You can typically only keep 3-8 sockets around for hundreds of users.

wrong question.

[ethereal]

The correct question: "why are our requirements so f***ed up?"

Seriously - there is absolutely no reason to develop on NT, test on NT, and deploy on Unix, and there are a number of good reasons not to follow that path. If you're going to deploy on Unix, you can develop the system on Unix using cheap hardware and more-or-less free Linux or *BSD development systems. You are setting yourself up for about twice as much work as you need to be - just develop the thing on Linux or *BSD to begin with, stick with standard Unix portability guidelines (there are a couple of good *nix portability guides out there from O'Reilly, although at the moment I can't remember the associated cover animals), and call it good. Don't add extra portability into the plan that doesn't really buy you anything.

I could understand if you foresee a future need to port back to Windows, but absent such a requirement at the present, I really think you want to plan the easiest development plan that's consistent with your current deployment requirements. Just ditch the whole NT thing entirely, or if it's a matter of "well, we already bought you these NT boxes to use", then reformat them and install Linux or *BSD on them. Even in the worst case, moving *nix code to Windows will be less painful than moving Windows code to *nix - Unix is designed for portability somewhat, Windows is specifically designed to make it harder to port applications to other platforms. That is not where you want to start out from.

Also, if you do have to do the Windows thing, don't test on NT, test on 2000. In the 2-year timeframe that you're aiming for, nobody's going to want to actually run on NT. So if Windows must be in the picture, then develop on 2000, test on 2000, and deploy on 2000. Again, save yourself from some headaches that aren't necessary.

Re:wrong question.

[tjgrant]

Generally good points, however, doing cross platform development does not have to be difficult. A couple of years ago I wrote an app to manage a recycling brokerage using Python/Tkinter/ODBC/PostgreSQL. I wrote it entirely on my notebook running RH62. moved the apps to the Windows machines and they ran exactly as expected (actually, there were a couple of very minor gotchas that were easily handled in about fifteen minutes).

With that level of cross-platform support, writing apps to deploy on a couple of different architectures is not too bad.

Re:wrong question.

[ethereal]

I agree that it isn't too hard to do if you pick the right tools up front, and I think many other posters on this story have adequately corroborated that point. I just don't see why to aim for such portability if it is not a real requirement - you can get things done more cheaply and complete your testing cycle much faster if there is not a multiplatform requirement. All I'm saying is to not create more work for yourself than you need.

Also, I think that starting on *nix and porting to Windows may be a much easier port than Windows->Unix - if you're not careful, Microsoft's development tools will not allow you an easy port away from Windows. So in my thinking the worst case is starting with NT and going to *nix, a slightly better case is starting with *nix and going to NT, and the best case is write it all on the targetted platform, and if you have to provide a GUI on other platforms make it web- or Java-based.

Common Lisp and Smalltalk - actually portable...

[RevAaron]

A lot of people have been suggesting Java, and just as many have been debunking it.

I know this is a C/C++/Perl/Java bigot crowd, so I'll keep this short.

What about Common Lisp or Smalltalk? Both are quite portable, and reasonably fast. Common Lisp can even be fully compiled to machine code. They both fill all of the other requirements.

Two notable implementations of CL are CMUCL (Free) and Allegro CL (free trial, commercial- but solid).

As far as Smalltalk, the notable implementations for your project are VisualWorks and IBM's VisualAge for Smalltalk. Couple summers ago I worked at a shop which was heavily into VA/ST, and it was a pretty awesome system. Core of their business, and we're talking about a pretty big insurance company.

Java, baby

[twdorris]

Seriously. Most folks on here think Java sucks, but that's typically because they haven't actually *used* it. I think perl sucks, simply because I haven't used it and don't know it well enough to be efficient at it. That's all too common. But take a closer look at Java... It's cross platform, multithreaded, scaleable ('cept that pesky GC thing, which can be handled reasonably enough with intelligent coding), and does all the stuff you're looking to do.

I used to code exclusively in assembly, then C, then C++, and now Java. Trust me, Java is a stable alternative that will solve MANY of these cross platform issues for you, if not all.

As an example, I have written a datalogger for my car. I coded everything under Linux using vi. It's a Swing based app that's multithreaded and uses the serial port to communicate with the car's computer. I never gave a second thought to cross platform support. I just coded to the Java APIs.

One day, a friend of mine wanted to run the thing on his laptop...which had Windows 98 on it. Sure enough, I put the files onto his laptop and it ran perfectly. This was not modified in any way and didn't even get recompiled! I just put the jar files from my Linux box onto this Windows laptop and away it went. I told him this "should" work, and sure enough, it did.

As for scaleability, I have also helped design a VERY large scale middleware Java RMI server architecture for a VERY large shipping company (it's a public company...you know them...I'm positive you've used them). This handles all user-based load from their VERY large website. We're talking millions of transactions a day here, not thousands. With proper attention to garbage collection, multithreading, and a distributed architecture, this system runs without flaw, 24/7.

So Java works in real world examples, it really does. Plus, it promotes code reuse so well, that I can't imagine suggesting any other solution for your problem.

Re:Java, baby

[cheeni]

Java is a four letter word! ;-)

Java may have come of age on the server, but as a desktop user experience it still has a long way to go.

The GUI toolkit (AWT / Swing) is fairly slow and prone to problems, especially if you try anything too fancy. Your own words "VERY large scale middleware Java RMI server architecture" and "VERY large website" indicate that almost all of your excellent experience has been on the server.

After those mega projects on Java, obviously Java would be occupying something like 98% of your brain ;-), and C / C++ could have been a distant memory. No surprise then that you chose Java.

Speaking to a serial port is speaking to a serial port irrespective of whether it was to a RISC computer on a car or a PC. A C / C++ / Kylix / app would have worked just fine.

I understand the merits of Java lie inherently in its maintainability. As far as portability goes, often one is forced to add a liitle C code via JNI to help out slower portions of Java code. This sort of thing as you should know was standard practice even in the C world where certain things like serial I/O would be done in ASM. There begins your problem of portability.

According to Bjarne Stroustroup his single biggest failing was to create a comprehensive set of packages for C++ as Java has. A platform with a standard set of packages is no doubt enticing.

I don't condemn Java outright, but in the end, you must do a hallway test. Write a nice fat GUI Java app, grab a person (non-techie) walking down the hallway, don't tell her what fantastic things it does over the network, just ask her to play around with it. In a few minutes you'll hear groans like "Why isn't this scroll bar responding? Maybe you should buy a newer machine!". Don't bother explaining to them that you have 128MB of RAM on that machine. Thank them for their time and pick up that old "C++ - Motif" book ! :-)

Need I bother with the trivial fact that developer machines are significantly better endowed than a 486 in a college lab?

Also dependancy problems like needing a Java runtime. Most machines on a college network won't have a JRE and that's a significant 9MB or more. Bloatware anyone?

Re:Java, baby

[Anonymous Coward]

This is +5 informative, but its obviously incorrect. You can't do serial IO in stock Java, you have to download and add the Java Comm API.

see: http://java.sun.com/products/javacomm/index.html

Also note that the download is only available for Win32 and Solaris.

Re:Java, baby

[Anonymous Coward]

so you rewrite the question for him, then give him an answer to the newly written question?
what are you, managment?
there could be a number of reasons for choosing C/C++ over JAVA.
This isn't anti-Java, its just common sence. Clearly he was unable to post a complete spec of the requirements.
If you can't answer the question, then go about your business. OTOH you probably need to prove your selfworth by pointing out how clever you think you are.
I hope your not talking about a company that has brown trucks, because my team was called in after the facts, to make many tweaks. The Java code was el'sucko.

Re:Java, baby

[evocate]

Why didn't you just log the car data in vi?

Re:Java is great for disposable transaction system

[rootmonkey]

You're right don't use java for heavy computations. But Java is great for the middle tier. One solution is to join them via sockets. Dump the computional code into C and pass params and results back via sockets. IMO it works great.

GNUStep

[Anonymous Coward]

Code in Objective-C and use GNUStep over linux and win32.

either Java or .net

[pvera]

The way I see it you are going to be using either Java or a .net language. Microsoft's roadmap for .net includes a CLR that runs on Unix.

Cross-platform?

[rkhalloran]

If it has to run on both platforms, I'd follow the recommendations of others and work to Java, and compile to native code if needed for performance.

If the issue is that they don't want to tie up "expensive Unix servers" for development, then for Ghu's sake slap a copy of Linux onto 1+ of the Intel boxen and develop on that using existing Unix tools; it would at least be closer to the target than Windows... If they think that GUI development can't be done "properly" on Unix (entirely possible mindset given the description), this would be an opportunity to show them otherwise with a start-to-finish *ix development cycle.

Depends...

[Svartalf]

If they're doing a lot of I/O device control directly with the app (Uh, this is an energy management system- which, by definition is going to be tickling things like Opto-22 panels, reading from sensors, etc...) then Java's only truely useful as a UI choice as they're going to have to come up with native interface code to drive the Opto-22 stuff.

They not only have to do network programming and serial comms, they have to deal with industrial I/O that may/may not have a serial interface. If it does all have serial interfaces, they're going to have to come up with APIs for those devices- which isn't always easy.

Java meets only part of the criteria- the ones they needed help with answers on. It doesn't magically meet the other criteria- what are they working with and what does the customer want. I suspect that Java doesn't make the grade here for some reason. I code in Java as well as C, C++, and Forth. I'd be using Forth or C/C++ for this sort of thing with maybe a CORBA driven UI coded in Java unless the customer requirements insisted on C/C++ for everything. Then I'd be using C/C++ because it's close enough to cross-platform to matter little if you pay close attention to your code. I know, I've been doing this sort of thing professionally for 7 years now.

Re:Depends...

[JumboMessiah]

Mod this guy up. Most folk in the application programming enviroment have never done industrial control programming before. When these guys are talking I/O, they're talking interfaces to Omron or Allen Bradley PLC controllers, Radio telemetry links, MODBUS acquired devices, and maybe some proprietary data acquisition stuff. Heh, and throw in the Opto-22 devices as well (probably over a 485 multi-drop link :).

Re:Depends...

[Spoke]

If they're doing a lot of I/O device control directly with the app, they're going to have to code different versions for Unix and NT with C/C++, too. Your argument doesn't help here unless there's a cross-platform I/O device control library, in which case you can still use JNI to interface with that.

Why not use Java JNI to help give a clean interface between the code which needs to be platform dependant?

Re:Depends...

[Camel Pilot]

FWIW I have a firewire interface written in Perl that talks to Opto22 Brains.

A while back we delivered a submersible safety system to the Navy based on Opto22 hardware. The system used a central Linux server querying 5 remotely mounted Opto22 Brain boards over ethernet. The nice thing about Opto is that they have modules to interface to just about any instrument/controller/device.

The Perl firewire module is based on the C++ code available from the company.

Python

[darrell.py]

I've used Python for this kind of thing. We are using Zope as the GUI to control test fixtures. This has been tremendously successful. Python handles little things like "\" verses "/" as well as socket issues.

ACE is what you want

[jnhtx]

ACE is what you want. It meets your requirements exactly, and is a proven industrial grade C++ libaray.

http://www.cs.wustl.edu/~schmidt/ACE.html

Jim

This community needs to embrace Java

[Anonymous Coward]

Stop the Java bashing. After reading through most of the comments here, I'm convinced that the problems are not with Java, but with the skill / experience of those commenting. Most of the complaints are just bad practices that real Java developers know how to avoid. As is the case in most languages.

Java performance is an argument of the past. The improvements made in the VM, hotspot, and good coding pactices have alleviated the performance issues.

The company I work at is a pure Java IT shop in the utilities industry. We must handle millions of transaction and run on multiple platforms. Java has performed great! And, we have been able to leverage tons of work done by others (Apache's Jakarta to mention one).

Also, Java allows developers to release programs that can be used in the massive Windows market and not exclude all others. I have seen some amazing UIs done with Swing. The complaints that I have seen here, I attribute to lack of experience.

Don't forget that Java is also a thorn in Microsoft's side also. It is the best (the only?) potential competitor to this .Net crap that Microsoft is pushing.

There was a time in the recent past when most development jobs I could get would only consider Microsoft platform and C++. Now the choices are Java and open standards (XML, Http, Ftp, etc.). Java played a large part in bringing about this shift.

Re:This community needs to embrace Java

[mvw]

Java performance is an argument of the past. The improvements made in the VM, hotspot, and good coding pactices have alleviated the performance issues.

Java has not much margin compared to C++. You have to code quite good Java.

Yes, the VM got faster. It is not the VM that is to blame all the time, expect for those occasions when native libs want to shovel data into the VM and back.
Trust on the garbage collection leads to memory bloat. The high level leads to the construction of deep nested objects that cost much time and memory to construct.
Not that it is different under C++, but people stick closer to the metal there.

Like you wrote, it depends largely if the developer is able to handle the tool.

Regards,
Marc

Navtive Win32

[rootmonkey]

Keep in mind that NT's posix libraries used to perform an order of magnitude worse than Win32 calls. Thats still the case. $M does that on purpose so developers choose speed over portablility.

ACE_Get_used_to_long_class_names

[Anonymous Coward]

ACE_loves_to_use_long_class_names. These guys don't just take a shit like everyone else - they have an ACE_excrement_reactor_sphinter_contractor pattern.

Doesn't have to be...

[Svartalf]

Just don't use VC++'s "features" such as many of the wizards. Don't use MFC for UI development- use something like Fltk, WX, etc. And, don't use COM/DCOM if at all possible, using CORBA or XPCOM when you need something like that.

Re:Doesn't have to be...

[rreyelts]

I don't think he was referring to the fact that it's easy to get stuck using Win32 APIs, but rather that VC++ is known to be one of the worst compilers on the market when it comes to standards conformance. Don't believe me? Spend some time on comp.lang.c++.moderated and get the opinions of some of the most respected C++ developers in the world.

Portable GUIs do not preserve UI

[suitti]

Cross platform GUIs have several problems. First, they generally do not support the native human interface guidelines of each platform. Even if they do, your application tends to behave like only one platform. So, if your intended "final" platform is *nix, then find a GUI that allows you to create a *nix interface.

Secondly, cross platform GUIs are usually a layer between some native GUI library and you. This involves overhead in speed and size. If you are considering C or C++, it is possible that speed and size are important to you.

Re:Portable GUIs do not preserve UI

[|DeN|niS]

Re: Yes they do.

Try QT, it uses native widgets on every platform. And if you want you can always swap the OK/Cancel buttons between the Windows and Mac compiles.

POSIX

[sneakerfish]

You have agreed on QT for the GUI stuff, so why not use POSIX for the threading and I/O? It is available on NT and UNIX certainly. I don't know if there is a POSIX API for serial ports.

POSIX support can be buggy (surprise) on NT and many function calls have "undefined" behavior according to the spec, but it IS the most ubiquitus API out there.

The Adaptive Communications Environment

[srealm]

aka. ACE. I use it personally to handle just that, multi-threading, locking, I/O, memory management, and alot more like timers, events, etc. Its got a HELL OF ALOT of stuff built into it, all of it cross platform, and most of the time, if one platform doesnt have it, they write an equivalent, or at the least, handle the fact.

You can grab it from here. Its got a non-standard compilation method, but for anyone with half a brain, it shouldnt be too hard. And it supports all unicies and win32. They've also chosen to expose a unix style API for their OS abstraction layer, which is perfect.

Hope it helps.

I would select WxWindows + ACE

[CRaMM]

The first for the GUI part and the second for the
serial (not very robust in Win32 until a couple
of months AFAIK), network, IPC stuff

I made my own research time ago and I wish I could have a work like the one you are comissioned to test them and to switch job :-/

I algo found interesting the Apache Portable
runtime (pure C) and some libraries used by
Apple in their open source Quick time streaming server.

C/C++ Server Java GUI

[Anonymous Coward]

This has worked very well for projects which I have worked on. We used ACE and RogueWave (don't ever use RogueWave) to provide platform independant server/backend code in C/C++. Then we used Java to provide a front end. This allows for User interfaces to run on either NT or Unix fairly easily while letting you stay away from GUI constructs in your backend code. This allows for using C/C++ closer to the ansi standards.

C/C++ cross platform libraries

[thor183]

Try the ACE package. It is a cross platform library for C/C++. It works pretty well but there are some issues. Some of the threading sync objects have inconsistent behavior on different platforms. But you can work around these difficulties.

http://ace.cs.wustl.edu/~schmidt/ACE-papers.html

ACE Toolkit

[Anonymous Coward]

Look at the ACE tookit at http://www.cs.wustl.edu/~schmidt/ACE.html.

It has cross platform support for: networking, threading, IPC, file API, etc.

Re:ACE Toolkit

[GooberToo]

I agree...mod this one up. ACE is awesome. It works well. It's stable. Has tons of documentation. Books are available. ACE!

C/C++???

[Stiletto]

It will be written in C/C++.

What is this "C/C++" language I keep hearing about? I've never worked with it. Is it similar to C or is it like C++? Where is the specification for "C/C++"? Where can I find more information about this unknown language?

Use a different language

[YoJ]

Of course it may not be up to you which language to write the software in, but if it is, then seriously consider using another language. C++ is a fun language, but isn't particularly suited for threaded programming nor for high portability. And for most programming tasks, correctness is much more important than raw execution speed. With this in mind, I would suggest using a language other than C++.

I find it amazing that programmers spend so much time looking for good libraries, but don't stop to think about their choice of language and spend the same amount of time looking for a good language to use.

Another vote for ACE

[avdi]

Others have said it already, but I'd like to add my vote for ACE. I work on air-traffic control equipment at a major defense contractor, and ACE is used extensively and successfully here. It is stable, reliable, mature, and comprehensive. It is very well designed, IMHO. It is widely used by the government and the aerospace industry. It is also open-source, and has excellent support from it's creators.

One of the standout features of ACE is that is not only a set of OS-neutral wrappers; although it can be used successfully for that purpose alone. The creator of ACE, Doug Schmidt, is a respected member of the Software Patterns community (he has helped write and/or edited several of the seminal patterns books). ACE is designed to implement many of the patterns that recur in networked programs, saving the programmer from reimplementing and debugging those patterns for the nth time. For example, if your application is an event-driven server that must demultiplex input and output on multiple files and ports, it's a prime candidate for the Reactor pattern. Rather than write and debug a reactor on your own, you can just use an ACE Reactor and save yourself the trouble.

The patterns discovered and/or used in ACE are thoroughly documented in Schmidt's book, Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects.

No, I'm not associated with ACE or Schmidt in any way. I'm just a contented user.

Cygwin?

[Dr. Evil]

Since it is going to a native UNIX environment, what about using Cygwin? Has anybody used this in a production environment which demands high-reliability?

For a GUI you could always use a web browser. I expect remote administration is probably a plus if it is going to eventually be running on a UNIX box... not that X doesn't provide similar functionality.

Of course the usual caution must apply that what the customer plans 1.5 years from now (i.e. going to UNIX) is not necessarily what they'll do... you could very well be stuck with Cygwin forever.

PACE/ACE are production-worthy

[madmaxx]

I've been using PACE/ACE for a number of years now for manufacturing control systems. The libraries are solid, and well tested ... and provide good portability to a dozen platforms. Ace provides some great high-level C++ abstractions, and PACE is a solid set of C interfaces to common OS stuff. I have a few systems based on Ace/Pace that have uptimes > 1 year ... and ramp up to the library was short. I would stay away from their container classes, and use STLPort instead.

Commercial solution?

[Anonymous Coward]

Far be it for me to mention something that you have to pay for, but ILOG (www.ilog.com) sells C++ (and Java) libraries that allow cross platform GUI applications with optimisation, scheduling, networking and database access. It may cost money but its shit hot!

Portable Libraries

[Anonymous Coward]

If you want a cross platform set of libraries, then your application code must never use a system call. Anywhere that you would use a system call, you must instead call your library function. Then you port your library from OS to OS. One problem is getting the function signature correct. What if all of the sudden you need another variable passed? You want to minimize changes to your application code. There are techniques for this, but I'll let others discuss them if they want.

Energy management system

[the real hedgehog]

I am not sure exactly what kind of energy management system you are developing but you had better take a long hard look at reliability.

Another thing to consider is how you are going to plug it into the local hydro grids system which is probably using fairly standard protocols.

Finally, from what I have seen, an energy management system is going to be doing alot of number crunching.

For these reasons alone I would forget the cross platform development and go with *nix right off the bat. Whoever came up with the NT idea in the first place?

ACE

[bstroustrup]

Consider ACE: http://siesta.cs.wustl.edu/~schmidt/ACE.html

It's open source, more portable than just about anything else, and used in industry.

Yup, only way to code for the future.

[Medievalist]

ABG is right, and you should isolate core functionality from data access and user interface - this is critical to portability and leads to evolution of strong, mature systems.
You will note that many business systems written in COBOL as "code monoliths" now require extremely expensive support in the form of CICS compatibility and cumbersome, user-unfriendly security layers. And their interfaces are still "green-screen" or, in many cases, have actually lost function and ease of use through poor GUI integration.
Meanwhile, many scientific systems written in a modular fashion live on despite having their underlying hardware replaced and their user interfaces re-written repeatedly. I'm sure there are systems that started on PDP-11s, are now running on Alpha VAXen, and are planning ports to linux clusters. Some will have been fitted with very pretty web interfaces.
Write your core modules, where the work is done, in ANSI C. Write your data access routines in the most portable language available on your preferred platform, and keep the code entirely distinct from the core functionality and user interface. If you're already invested in something like Rdb, Oracle, MySQL, whatever, then leverage the expertise and investment you already have but make sure your API is callable from C. Don't be afraid to use a fast, simple data store like Berkeley DB or plain old flat files - cheaper is better. But be sure to define a data access API in any case (such as Replace_Leaf_Record() and Create_New_Root(), for example) and keep the code cleanly separated into modules.
Provide a "raw text" interface, written in C, and keep that as the base functionality canon. Use it to test the GUI, which you can write in Java or C++ or Eiffel or whatever (I'd say use your favorite, since you'll get prettier results if you enjoy using the language). Make sure the API for the GUI is entirely documented in the core code itself so that it can be seamlessly replaced when the fabled post-GUI interface finally appears.
--Charlie

ObjectSpace C++ Toolkits

[staplin]

ObjectSpace provides a good, cross platform STL implementation, with toolkits that build upon it. ObjectSpace's C++ Toolkits cover multithreading with mutexes, semaphores, reference counting, communication with streams, pipes, sockets and files. They also provide some useful tools in terms of time and regexp.

It's been a few years since I've used them, but I used them on solaris and hpux with both the proprietary compilers and gcc, and I know their headers had provisions for the MS compiler.

Re:ObjectSpace C++ Toolkits

[elflord]

But why use STL if you're already using Qt ? Qt already includes several container classes, and their cost per instance is considerably smaller than that of STL

Re:ObjectSpace C++ Toolkits

[staplin]

My main point was that ObjectSpace provides the toolkits for doing multithreading and communications I/O.

For example (IIRC), you can instantiate threads like this:

Thread t1 = new Thread("WorkerThread", &MyWorkerClass::run);

And things like sockets also have a nice OO abstraction that hides the platform (or posix) details.

I haven't used Qt, so I didn't know about the container classes, however, the other uses of ObjectSpace seem to fit the needs of this project quite nicely. Though, if no STL was going to be used anywhere else, this would add quite a bit of overhead.

ENDIAN

[Anonymous Coward]

Euh... I hope you know about this, but if you are planing to use c/c++ I take you might play with strucures and the what not... well I sure hope you know that Windows runs on CISC processors and they are small ENDIAN, and the UNIX, such as Solaris, runs on RISC processors (unless they use it on a pc) and Risc machines are BIG ENDIAN ...

Well this means that they don;t understand each other, and that all the ordering bits are reversed from one to another... I am saying this because us UNIX guys have a problem with the NT guys (other team at work) that they do not know about i and send us structures that have not been putted in network order!! so we have to make hack workarounds!!!

cheers,

You need to know what the possibl *nix boxes will

[Assmasher]

be...

I have spent a few years cross developing on IRIX, Solaris, HP-Unix, and NT/2000.

We used Ansi C/C++ (I know, C++ and Ansi don't mix) and except for machine specific sections (such as serial communications) it worked great. But we didn't do much GUI.

There are cross platform GUI's like MainWin's if you can determine your target *nix machine. That is important. Else, you can simply abstract your GUI from everything else and create a facade/proxy pattern. Good luck!

Actually Windows has this problem regardless

[Myrv]

Actually it sounds like he was running on a win9x machine. Unfortunately the way win9x is implemented, the OS will not release memory for a thread until the owning process is finished/killed. Since the JAVA spec requires the VM to use the native OS threads if they exist, all JVM implemented under win98 have the thread memory problem. The only way around it is to do what the original poster did. Keep thread references around and keep reusing them.

Whoever says JAVA is platform independent is sadly mistaken.

Re:Actually Windows has this problem regardless

[big_hairy_mama]

I think that this shows a far bigger problem in Win98 than with the JLS.

Re:SWIG ... or sip

[elflord]

Sip has NO documentation, but it has the advantage that it's used for the Python Qt bindings. It's reasonably easy to use, though it really could do with some documentation.

STL and boost

[yamla]

Assuming you are writing in C++, which seems likely given that you are using Qt.

First, make sure you are using the STL. Others have pointed this out already and they are right. Second, Qt provides much of what you want. It is pretty good that way. Third, check out http://www.boost.org/ which has several other very useful libraries.

how about the build environment?

[Anonymous Coward]

what build tool do you use? do you have
nightly builds on all the target platforms? how is this
set up and arranged? what tools do you use?

Good idea

[Anonymous Coward]

I like anything that forces/allows you to fix things as you go rather than wait for the end.

Qt 3.0

[Anonymous Coward]

You're already using Qt3.0 for the GUI. Qt3.0 also has perfectly good cross-platform network and threading classes, so why not use those?

I've just completed a complex multi-threaded client-server application, using Qt for both the client and the (non-GUI) servers. 'Porting' the client from Linux to Windows consisted of adding one #include to one file and compiling under Visual C++.

The only thing stock Qt3 is missing is serial port access, and writing a cross-platform shim around that would be no more than a days work.

Qt is based around a central select loop. Trying to borg in another app framework will get painful.

STL and segmented coding

[janolder]

I've written some platform indepented code for both Mac/Win and Win/Linux apps. I've found it very helpful to write the central guts of the apps based only on the STL and to write wrapper classes that hide the complexity of platform indepenent things, like threading. This has recently been very successful in a 30000 line app that had to run both on Win2000 and MacOS.

If you haven't already done so, get a good book on the STL and acquire a basic understanding of all the amazing stuff that's in there. I find the syntax of using list, map and the iterators a bit perplexing at times, but it is definitely worth the trouble.

Common C++

[Anonymous Coward]

I also highly recommend the Common C++ libraries.

I won't go near Windows stuff, so I developed
my code under Linux (using that library), and
then handed my source (along with the Windows
version of CommonC++ to a guy who is forced to
use Windows, and basically a recompile was all
that was neccessary.

(Actually, since I was working with an _early_
version of Common C++, there were a few things to
fix, but the project was successful.)

Re:Common C++

[Anonymous Coward]

now better known as GNU Common C++

http://www.gnu.org/software/commonc++/CommonC++. ht ml

has classes for serial- and TCP-based iostreams as
well as somewhat more thinly-veiled abstractions of
the underlying I/O mechanisms. also gives you
service threads managing pooled ports, derivable
thread objects a la Java, mutex, semaphore, event,
and condition variable objects, or some
approximation thereof, depending on platform,
serialization, and much more

Separate interface and engine thread models

[aminorex]

If you don't care about bloat, use ACE. I don't think it does serial port I/O however. If you do
care about bloat, use win32-pthreads for threading.
The socket API is pretty much portable. Write a
couple of tiny wrapper functions to smooth over
serial port I/O.

But you really don't want your GUI and application
logic to use the same thread model. Put the
application in another process, and communicate
over sockets. (Not performance sensistive, so
there's no good reason not to make it network-
transparent.) Don't let QT dictate the threading
of your application.

Please mod the parent down

[aminorex]

This is so utterly wrong, in factual terms that
the mind boggles to consider a soul so reckless
in it's disregard for truth.

True - DBTools++ is very Slow++

[Anonymous Coward]

We had to resort to writing our own database access drivers because of the piss poor performance of RW's DBTools. The RWDBTools stuff seems to perform millions of object copies behind the scenes for no good reason. Our homegrown DB API, although crude, is 5 times faster.

An idea...

[Fnkmaster]

If you (or the client) are determined to go pure C/C++, Qt already provides almost everything you are asking about, except serial port support. So you have two choices: Go with Qt all the way and find a third party library or isolate dependencies to make your own mini-library to handle serial port access. Or go with one of the other perhaps more comprehensive toolkits mentioned here (ACE, etc.) which I know little about.

Incidentally, I really like Qt, and it's great for commercial projects but as a Free library apps you really want to be cross-platform but can't afford to pay their Windows licensing fees for, I have become increasingly fond of wxWindows.

It has it's quirks, yes, but its greatest stregth IMHO is a very nice, well supported Python API. I swear it's at least 3-4 times faster to build a GUI in wxPython than in anything I've seen in C++, even using GUI RAD tools (which only get you so far before you start having to hack at source). Just my opinion, anyway.

Qt already does everything you need...

[cduffy]

...except maybe the serial IO. It certainly handles threading and network IO correctly, and serial IO isn't a hard thing to encapsulate and not much code to write twice (I don't know what the Win32 network interface looks like, so I can't comment much more about it).

Before looking into additional tools, look closer at what you're already using.

(On a personal note, btw, I don't use C++/Qt -- I prefer to use Python, which provides a sufficiently uniform interface for my needs, with its Gtk bindings, which are available on both the platforms you mention. Since these decisions are already made for your project, however, I'm not going to try to push them here).

Why not Ada/GNAT?

[Catamount]

IMHO, one of the best choices. Core Ada is fully portable, GUI can be written using Qt, GTK bindings or even JGNAT (the compiler creating Java classes from Ada source).
At lest it guarantees reliability and good built- in multithreading support.

bwahhahahahaha

[aminorex]

And their roadmap for COM included COM on Solaris
and AIX. Hehehehehe. There's one born every minute.

Why C++?

[Anonymous Coward]

Why does it have to be done in C++?
How about Ruby?
http://www.ruby-lang.org

(or even Python)

Re:Ummm... POSIX? BSD Sockets?

[Anonymous Coward]

NT's Built-in POSIX has essentially been replaced by Microsoft Interix -- it lets you access Win32 and was in the past Single Unix Spec certified, so the API should be pretty complete.

(Also, unlike Cygwin and UWin, it runs as subsystem rather than a library.)

the libs I use

[Anonymous Coward]

OpenGL, OpenAL, Boost++, and sometimes PLib

Julien.

Boost threads API design annoyances

[Anonymous Coward]

Boost starts the thread when a thread object is _constructed_. This is a design problem in my opinion because sometimes you wish to instantiate an object but not activate it immediately (or not at all). Another beef with Boost threads - they do not have a timeout on their join() operation. It blocks forever. It's hard to control thread pools without such timeouts.

Why?

[Svartalf]

You claim that the poster's claimns are utterly wrong. PROVE IT.

My own personal experience indicates that he's much, much closer to the truth than you'd like to admit.

Qt 3.0 for Win32?

[gtada]

Uhhh, Qt is still at version 2.3.0 for Windows. I don't know if the changes will affect you. It's still mostly source compatible, but not 100%. Be sure to read the changes.

Re:Qt 3.0 for Win32?

[Dr. Sp0ng]

Uhhh, Qt is still at version 2.3.0 for Windows.

That's funny, because I get paid to develop an app for Linux and Windows which uses Qt 3.0. AFAIK Trolltech hasn't released a free version of 3.0 for Windows yet (although they should soon), but the commercial Windows version was released at the same time the X11 version was.

Don't know about serial ports...

[JohnZed]

But Qt 3.0 has fairly good cross-platform threading and networking libraries, in addition to its GUI stuff. See http://doc.trolltech.com/3.0/network.html for networking docs and http://doc.trolltech.com/3.0/threads.html for threading docs. Since you're already learning the "Qt way," you might as well use it for these features too.
--JRZ

Kylix?

[dctc]

Native Win32-PE/x86Linux-ELF , GUI, Networking, data base, OOP (build your "buisness" logic framework and access native api's on each OS)?, fast compiler, fast executables, *great* IDE, copy and compile on the other platform.

I mean, your requierments read like Borland's marketting stuff on Kylix/Delphi

Use ACE+TAO

[rnosewor]

ACE+TAO should meet all of your requirements (and more!) Check it out: http://www.cs.wustl.edu/~schmidt It is *WIDELY* used and well supported. jrn

Could be a _customer_ requirement...

[Svartalf]

Ever thought about that one, hm?

How about Perl

[reedw]

Of course, you would have to do major re-thinking, and make compromises in some places; but how about perl?

It is fully portable, fast enough for most apps, bug free; and, you will complete the job 3 times as fast if reasonably fluent in perl.

Omnis Studio

[BuckBanzai]

You might want to try Omnis Studio. It's a little different, but it's been working cross-platform since the mid-1980's.

learn QT as it does most of that

[josepha48]

QT has a socket code, I think it has thread code, and much else. If you have already decidede to use QT as the GUI, I'd suggest using them for everything else. It should be cross platform compile okay.

Re:ACE Hints / Tips

[PureFiction]

I have used ACE and TAO (the ACE CORBA ORB) for a number of projects.

It works great and is incredibly portable. My only advice is to be sure to get familiar with the configuration of the entire package, like features and options and components before you settle on a given configuration for use in your project.

ACE+TAO are designed to run on a large number of platforms, and support C++ without exceptions, explicit STL template definition, and a number of other features which are really handy for some environments, but dont serve a default installation well.

Some of these options affect the way your code interacts with the library, and require you to write and/or compile your code accordingly. Obviously you do not want to get half way into a project and realize you need to change some configuration options, and then go back into your code and make the requisite changes to support these modified configurations. (This isnt a big deal, as everything is pretty well encapsulated, but it can cause headaches)

I'll give you a few examples of things that I ran across.

1. CORBA. I had used the TAO orb to compile IDL without native exceptions, producing stubs and skeletons that used a CORBA::Environment arguments in all methods to provide the hooks necessary to handle exceptions without using c++ exceptions. Later I switched to native c++ exceptions, and had to modify the function declarations and definitions to remove this now unnecessary CORBA::Environment argument.

2. I had built ACE with the 'no implicit templates' option, which required that all member templates be explicitly defined in the sources files where they were used for linking correctly. Later I switched to gcc 3.0.2 and started using implicit templates. I had to recompile ACE with this new configuration, and also modify my code to remove all of the explicit template definitions that I had added.

3. I had initially been building ACE + TAO with all components and features enabled. This led to very, very long compile times (I am talking 8+ hours on a dual PIII 550 w/ 512M of RAM!) It turns out a vast majority of the stuff being built I didnt need, like a number of the CoS services, the realtime CORBA stuff, and some of the ATM and other networking features. I was able to tweak a few settings in the configuration / build files and this cut my build times down to about an hour. This is a BIG time saver.

Use CVS for cross platform source control

[Lumpish Scholar]

I work on a medium-sized (~50-100K LOC) cross platform commercial application.

The original developer (1.0 was Windows-only) wanted to use SourceSafe; it's a Windows-based source control system, but he'd heard there was also Unix support. I'd tried to use it on my previous project; true for small values of "support".

We use CVS, checking out onto Windows or onto Unix, hosted on Unix. It just plain works.

FYI, we could not find any way to check out one copy of the source on one platform and build on the other. Visual C++ :-( was very unhappy about Unix-like end-of-line sequences. We check out on each platform, and keep them in sync more or less "by hand" (carrying files or patches from one to the other).

P.S.: I have no personal experience with ACE but have also heard good things about it. Commercial support is available from Riverace, if that's an issue.

Re:Use CVS for cross platform source control

[lambermo]

Your CVS problems sound strange to me. I use CVS to checkout on a NFS/SAMBA exported drive to BeOS, Darwin (OSX on ppc), FreeBSD, Linux (alpha, i386, ppc), Irix, Solaris (i386, sparc) and Windows. I do not have the problems you describe.

Blah!

[mduckworth]

You could just ditch the C/C++ effort and pick up something like Kylix. Yes, it is pascal but you can seriously do pretty much anything in it that you could do in C without much difficulty. That and hte professional version would have most of the networking and gui libraries you need, already cross platform. Want it to work in linux? Load up the project and compile. Just my $.02.

I'm not Java bashing, but Java may be a bad choice

[Svartalf]

Java, as it currently is used, is likely to be a poor choice of a tool for this task.

An energy management system more often than not has to deal with industrial I/O systems such as an Opto-22 interface or a ModBus interface. This often requires system level coding resources Java doesn't provide in any way, shape, or form (because it's not part of it's model of how things should be). To claim that you can code those portions in C or C++ and interface them is silly- it's inserting needless complexity (in the form of having to support two differing languages and having to maintain interfaces suitable for JNI.) for no good reason. If you have to resort to using C or C++ for something, it's more often than not better to code the whole thing in one of those languages.

Coding the UI in Java is an arguable task. On the one hand, you've got the nice API designed for doing UI coding. On the other hand, you're back to adding needless complexities into the system in the form of multiple languages and RPC interfaces unless you're using CORBA between the UI and the energy management system engine. Again, you may be better off, based on my personal experience as a software engineer of 12+ years of experience in the industry as a whole, to code the thing entirely in the base language- it'd be simpler for the whole source tree.

And this doesn't even get into what the customer wants. If they want C/C++, then they get it.

For Loops

[sankeld]

The biggest problem with working with c++ and visualc++ is the for loop. The solution is to put the following at the beginning of all your programs.

#define for if( true ) for

I happen to have done extensive projects w/VC++

[Svartalf]

And the code's collecting some 10-30K per day at a major international airport in parking and ground trans fees. Part of the system runs on NT (Not MY choice) and part of it runs on an embedded platform running Linux. Same codebase, some 200-500kloc of complext client-server code that compiles cleanly w/no warnings or errors on either GCC or VC++.

Its all in what you do/don't do coding-wise. And, I'd probably have a few horror stories to swap w/the people on comp.lang.c++.moderated over VC++ because I DO this sort of thing for a living and have done so for 6-7 years now.

Cross platform coding guidelines

[preed-man]

This really doensn't answer your cross platform library question, as there have already been a number of good answers to that (I'd suggest checking out NSPR; it's open source, free, heavily tested/stable (Mozilla/Netscape/Netscape's server products/etc. use it), and does all of the cross platform stuff you need, and does it on 30-some odd platforms.

As for cross platform programming practices, check out Mozilla's C++ Portability Guide. Porting the browser to 28 different operating systems, each with their own compilers and each of those compilers with their own quirks has given the Mozilla build engineering team some insight into what to do and what not to do when writing portable code.

This document tells you what those do's and don'ts are, and (more importantly) why.

Don't bet on it.

[Svartalf]

I'll bet the customer knows about/knows C/C++ and understands that they can get systems (key word there...) programmers using that language.

Java isn't a great systems language- it's a great applications language and doesn't pretend to be anything more. You can do systems programming in an applications language, but the results are often less than stellar and a rough beast to maintain.

This is systems level programming and you need more than an applications tool to do the work right.

ACE/TAO for massively cross platform applications

[Ricdude]

We use the same C++ foundation classes in ACE on WinNT, Win2k, Solaris, IRIX, HP-UX, and Linux. ACE is also supported on VxWorks, AIX, and a dozen other weird variants of *nix. It's a comprehensive real-time, networking, threading, and platform abstraction library. The stuff works great. Makes all platforms act the same. Takes a little work to get it compiled at first, though.

Expect to spend some time getting used to the toolkit, which ever one that winds up being. Every minute you spend initially studying example code, and learning the toolkit's way of approaching problems, is one less minute you will spend trying to beat their classes into doing something they weren't necessarily intended to do.

Unless you know what you're getting into up front, keep separate make strategies for Win and Unix. If you're feeling perky after a while, you may be able to migrate your windows build to the same makefiles as unix, but it'll take some work (and probably the cygwin toolset)

Mozilla's Article is Old and Wrong

[ChaoticCoyote]

The Mozilla "C++ portability guide" is long out-od-date, having been written in early 1998 before the C++ Standard was even official. The Mozilla document makes many uneducated assertions that would lead to poor programming practices.

Any article that suggest the use of macros over templates is clearly no written by anyone who has worked with C++ in the last couple of years.

I've been writing, publishing and preaching portable C++ for more than a decade, and I have substantial code bases that compile and run, with MINIMAL conditional compilation, on multiple platforms (hardware and software). What the Mozilla document advocates isn't portable C++, because they threw out almost everything that *is* C++.

Not so for some things...

[Svartalf]

Some definitions:

Systems programming: Driving hardware with software and/or providing interfaces to system resource (i.e. Your OS itself). This includes industrial I/O stuff like you'd see with an energy management system. It's often timing critical with delays causing no end to problems with things working let alone working right.

Applications programming: Just about everything else.

Just because Java does a bang-up job of doing one, doesn't mean it works well for the other. For an energy management system, down to even the UI, the results must always be predictable and consistent for it to be of any use. For the UI, there's some slack for things like GC causing a second or so delay- and at seemingly random intervals. Java's a decent candidate for that. The flipside is that the controls underneath the UI don't want, don't need, can ill afford random delays like that because you could get into oscillations of operation that burn up any advantage you had by the management system in the first place.

Java is the question

[Anonymous Coward]

NO is the answer.

But to be serious - it depends on what you're doing. If you don't plan on getting too close to any actual devices or hardware, you'll do OK.

But you'll experience excruciating pain, if you try to do any serious network i/o (Java currently DOESN'T HAVE NONBLOCKING SOCKETS) or do anything that requires special access to hardware (JNI is about as much fun to debug as a kick in the crotch).

Remember kiddies, Java is NOT the One True Language.

Re:Java is the question

[Strawberry Pie]

Bullshit. Java has non-blocking sockets, at least in 1.3.

If you're going to slam a language or technology or what have you, you ought to be better informed; otherwise, you come off sounding like an ignorant moron.

Java is not the right solution for everything, but it is the solution for some cases.

I agree - this is wrong because...

[DrPepper]

1. This is engineering; the solution should be developed as a whole - ie. the hardware and software should be selected from the best available to solve the problem. The solution should then be developed, tested and deployed without changing the game halfway through.

2. Too often developers and their companies see themselves as subservient to their clients. This is the wrong attitude - development should be done as a partnership between client and supplier with both equal. Both client and supplier are much better for it if the supplier is honest with the client. The client is employing you for your skills and knowledge - if they don't at least consider your recommendations, then they are wasting their money.

The client may have good reasons for choosing Windows - but testing on Windows and then changing to Unix is quite clearly a recipe for disaster.

Sorry, but I can see right now that this is very likely to be a project that is going to go wrong. The system has to be tested as a whole - that means using the same users, hardware and software throughout development, testing, deployment and into maintenance.

Re:I agree - this is wrong because...

[SquierStrat]

I agree...a switch half-way through is just STUPID! But assuming they test on both platforms each step of the way it isn't necesarilly going to go ka-blooey...the problem is testing...it's got to be thoroughly tested on a dummy system during it's 12 months with NT.

anything other than java... Why?

[llamalicious]

Are you being simlpy forced to write code outside of Java because your employer/underwriter believes Java will be too slow for implementation, please remind them that the speed of Java applications with a good JVM and JITC can be as fast as C++ with well written code.
If that's their major concern, I would recommend building it in Java from the start.

Python = Portable

[studboy]

Use Python. My bro wrote an Othello game for the SGI/Python, ported it to Windows with a single color change. Damn near wet myself seeing the same thing on two *radically* different systems.

Write your app in python, but extend it with C/C++ libraries. Extending with C is easy, use SWIG, which rocks, ignore previous poster. From download to running application in 5 languages was literally fifteen minutes (gd library, Python and Java).

Likewise, embedding is easy: write your application in C/C++ *which calls Python*, then replace Python on an as-needed basis. Develop quickly using an interactive language, then replace them once the algorithms get solid and boring.

This technique gives you a substantial, clean library system; interactivity; portability; etc. It's also easy to replace sections or the whole thing if the PHBs get on your case.

Python rocks!

Crowded market of existing software!

[Anonymous Coward]

There are *sooo* many commercial providers of precisely this kind of software, why re-invent it from scratch?!?

Mod this parent up

[Anonymous Coward]

One of the few people here on slashdot who isn't stupid.

And the answer is...

[Anonymous Coward]

...out there and here.

They're slashdolts, that's why!

[Anonymous Coward]

Stupid is as stupid likes and uses.

You could argue that perhaps ml is the last advanced language, but few use it.

The last advanced language that people widely adopted would be C++. Java is a kindergarten caricature of C++, designed for kindergarten programmers.

Unfortunately, it's what I'm paid to write in. I wonder how much damage my brain is taking, though. I really would like to get back to C++ and civilization.

Re:They're slashdolts, that's why!

[Anonymous Coward]

Amen, brother. Java is the Grade 2 of programming, while C++ is third year university. Try numerical analysis in Java - forget about it. Try writing a GUI app - forget about it. Try writing anything but a servlet - forget about it. C++ is the dope!

TCL C Library

[techentin]

The Tcl C library has rock-solid support for serial and network I/O for both Unix and Windows. You language buffs may recall that John Ousterhout first created the Tool Command Language (TCL) as a C library supporting electronic CAD applications. You can check out the interface for I/O channels in the online man pages.

Tcl's thread support is a little more limited. There is a thread extension which is supposed to be pretty good. (I haven't personally used it.) But unless your application is running on multiprocessors, you probably don't need threads and should consider an event-based model. (see "Why Threads Are A Bad Idea" PowerPoint only, sorry.) Events are just plain easier to program and support than threads. And Tcl's event support is excellent.

As a side benefit, you'd get a free scripting environment to prototype your application's communications subsystem.

Try wxwindows

[Beached]

Wxwindows is a set of cross platform GUI, DB, Networking, IO classes and sound. It runs under windows, Unix, Linux and many others. Look at http://www.wxwindows.org. I have used it in many different applications.

Here's an example of a slashdolt, right here

[Anonymous Coward]

Yes, you can compile Java into machine code, but guess what, laserbrain? None of the AWT stuff has been adapted to be used natively. And I doubt you have the skill to help them out either. You're probably one of those people who will drool and whine until someone else with some talent does it for you.

Yes you can use JNI, but JNI is about as much fun as a kick in the crotch. I've seen C code run perfectly fine, when used in other C code, but act completely squirrelly when loaded into a JVM.

Hardware is cheap, and if you don't really need to access anything other than a windowing toolkit and main memory, go ahead and use Java. You might have to screw with the gc, if it starts collecting at odd times. If you need to get down to the bare metal, well, see the JNI piece above.

Java is no more or less well organized than C or C++. If anything, it's less consistent than C. Why were arrays made 1st class objects, and not other primitive data types, for instance?

You gotta give Gosling credit for duping people like you. The Force has a strong effect on the weak mind. These aren't the droids you're looking for...

Re:Here's an example of a slashdolt, right here

[FatherOfONe]

I use to do some serious development with SWING and would love to see some real comparisons of a SWING designed application v.s. one done with C or C++. My experience is that on ANY modern hardware SWING performs well. Does this mean that I expect to see Quake IV in JAVA and using SWING? No. Does it mean that this guys application would probably run just fine with SWING and JAVA ... HELL YES! I am willing to bet just about anything that the application that these two guys will code would perform just fine under JAVA and SWING.

As for you comments about arrays being made 1st class objects. My first thought is who the hell cares... you just use the array. Does the array work? Is it fast enough?

Who needs speed of C in age of PHP?

[brlewis]

In the 1980s, the speed and compactness you could get out of C was worth the extra coding time. But with today's hardware, languages are coming out of the woodwork that are much less efficient, but still successful. For example, a number of successful web sites have been written in PHP. Not as slow as ASP, but still a horribly slow language. Yet those sites are still successful, because the hardware can handle it. FWIW, my JVM-based implementation of BRL was 3-4x faster than PHP in a simple benchmark. (Incidentally, developers don't need to know C or Java to learn BRL. See the learnbrl.war demo/tutorial.)

Re:Who needs speed of C in age of PHP?

[MrBoring]

I really hate this mentallity. Though it is true that hardware is getting faster, that's no excuse for slow code. Doesn't anyone want to have "instantaneous" response times when they click on something? I, for one, don't want to see a spreadsheet on a website, where in I type something in, and have to click some button somewhere, and watch the comet circle around. Please don't make everything run in a browser! (Not that you explicitly suggested that, though).

People commonly say Linux is smaller than Windows, and can run on older hardware. The MS Windows way is to say, go ahead. Make the software slower, the computers will get faster!

Also, just think how much more efficient, and pleasant, computing would be if people did care about speed and footprint size.

Lastly, I've almost given up hope on the above. People continuously will want to make a program in 5 minutes that many people will use for a short time instead of spending more time developing quality, robust software that will be used for years.

Common C++ not ready for prime time

[Earlybird]

At least when I tried it a few months ago, CommonC++ did not compile correctly under Windows. Its configure script did not even work out of the box, failing to detect Cygwin and Visual C++. It compiles fine on Linux, but the Win32 support seems to have been neglected for a while.

As a whole, the CommonC++ design is pretty messy, relying on massive amounts of kludgy ifdefs and macros in the header files. I believe they are working on cleaning it up.

Other libraries I would consider:

• ACE: threads, synchronization, sockets. ACE's design is not very object-oriented, but its probably the most extensively portability layer you will find.

• IOLib, portable I/O (also includes identical ports for C and Objective-C).

• ZThread for threads.

• Nescape Portable Runtime (NSPR), a C library: sockets/IPC, threads, synchronization primitives, layered I/O, ADTs/algorithms, portable shared libraries, logging, etc.

www.imatix.com

[50bmg]

there is a cross-platform C library there, or two, SFL and SMT, that they use to create a reference Web Server, Xitami. Bulletproof stuff, tried and tested in many commercial deployments.

JDK 1.4 is beta

[Anonymous Coward]

Which means I'm not about to touch it with a 10' pole, until someone else has banged on it and driven most of the squirrells away.

Which begs the question, why didn't Java have this in the first place? And it took them *this* long to figure out they needed async I/O? I'm not impressed with the level of sophistication of the Java community.

D00D!!!

[Anonymous Coward]

Congratulations! You "get" it!!!!
The browser is the user interface solution !!!
If we could just get the browser makers to
implement a standard (and robust!!!) javascript,
everything would be even easier.

you da man!!!

Use STLPort

[Anonymous Coward]

Not the nobbled Dinkumware version. Oddly, it's neither PJ Plaugers fault nor Microsoft's fault that they had to use an old version.

So do I :-)

[Anonymous Brave Guy]

And, I'd probably have a few horror stories to swap w/the people on comp.lang.c++.moderated over VC++ because I DO this sort of thing for a living and have done so for 6-7 years now.

Speaking as an occasional participant in that group, I very much doubt anyone there would disagree with you. Those guys are well aware of both cross-platform issues and the deficiencies in VC++ 6.

He's right - I used Java alpha in 1994

[Anonymous Coward]

He's also right in telling you to fuck yourself.

Dinkumware STL / VC++ 6

[Anonymous Brave Guy]

Dinkumware did write the standard library implementation (including the STL stuff) supplied with VC++ 6. However, the version supplied was actually written before the C++ standard was finalised, and is considerably older than the compiler itself. This results in a number of annoying warnings during builds, and some equally annoying omissions (the auto_ptr implementation is seriously crippled, for example, because they don't have the templated constructor, since that wasn't in the spec pre-standard).

Dinkumware have, of course, revised and updated their library a lot since then. While they do advertise bug fixes (e.g., PJ Plauger himself is a regular on the C++ newsgroups and has posted the fix for getline), they are not just going to give away a whole new version of their library for free -- they've got to make their money somewhere! IMHO, Microsoft should have done the decent thing and shipped the bug fixes and major updates in one of the VC++ service packs, but that would have cost them money, so instead we have to wait for VS.NET, which includes a much improved C++ standard library implementation.

DJGPP may be your answer.

[Codifex Maximus]

I know that DJGPP is a mighty fine way of getting GNU stuff onto Windows systems and back for portability. Just avoid using any of the MS API's and the MSFC code.

I *think* that most of the programs developed for GNU environments will compile correctly with DJGPP.

They even include a Borland style IDE with DJGPP.

serial abstraction isn't hard

[yugami]

write a "meta" ABC(abstract base class) and base your different serial classes off of those, that way you are forced to keep your interfaces in sink.

Win32 serial is done w/ CreateFile, ReadFile, WriteFile.

linux is done using open and other posix style api's

We're building something like this right now

[Anonymous Coward]

Hi there,

My company is building a system with basically the same requirements as yours, but for a different market.

We do a LOT of heavy IO (both on the network and on disk) and need to handle tons of threads simultaneously.

Our solution is 100% Java (on the GUI side we use the Java Swing classes, which unlike the old AWT trully is WYSIWYG on all platforms).

Our system has been tested on these platforms without absolutely any modifications whatsoever:

- Windows 95, 98, Me, 2000 Pro, 2000 Server

- Solaris

- Linux

We soon plan to test it on the new Macs as well, as well as some other platforms (HP/UX, AIX, etc).

Most amazing, we re-wrote from scratch the critical loops of our code in highly optimized C routines just for benchmarking, and the Java solution was on average between 4% and 7% slower, which is great, considering we're running debug code.

On the whole, our experience with Java has been great, both on the server and the client side (although sometimes we wish the JTable component was easier to deal with).

Hope this helps.

p.s.: Sorry about not providing more details, but we're under a NDA...

POSIX is it all (cygwin)

[anshil]

The platform indendant standard does it. Altough windows is one of the few systems that doesn't complain it, you can get by using cygwin:

http://sources.redhat.com/cygwin/

(I know Windows NT got the POSIX Certifacte, but only because they implemented just enough to pass the preknown tests, that does by far not mean that it will function)

If you programm in the cygwin environment using exclusivly the cygwin library interface your code should run pretty well on all other POSIX platforms. (including linux, solaris, *bsd, etc.)

The C++ STL, generics and Java

[Anonymous Brave Guy]

Isn't the STL, and the generic programming it introduces, one of the main features lacking in Java? Or will Java catch up in that area?

Yes and yes. However, some caution is in order here.

It is a common misconception that the STL, templates and generic programming are synonymous, that one is only good with the others. This is not true. Generic programming is the concept, the programming style. C++ supports generic programming through its template facilities, but other languages (e.g., functional languages) manage perfectly well without a formal template mechanism. The STL is a very clever library based on generic programming principles, and the C++ standard library contains a large amount of material based on it, and unfortunately also commonly known as the "STL", though it is not entirely Stepanov's original idea. Also unfortunately, C++'s language facilities aren't quite up to making the most of it yet -- templates are a good start, but a couple of major omissions are still crippling for now. Hopefully the next revision of the C++ standard will incorporate things like in-place definition of anonymous functions, to fulfil the currently wasted potential of the standard algorithms.

Sadly, Sun's Java team seem to be amongst the uninformed here. The Java Generics proposal, which you can download via this link if you're interested, basically describes a heavily cut-down version of C++ templates. The usual Java approach has been adopted: take what is commonly used, quietly ignore anything else, add a little here and there but not much of substance. If memory serves, the more glaring omissions include numeric template parameters. Useful techniques from the C++ world such as traits and template metaprogramming appear to be hard or impossible to implement with the current Java generics proposals. As a result, Java's "generics" will probably be good for writing template containers -- itself a great improvement over the status quo -- but not very useful for much else.

It's a step in the right direction, certainly, but in spite of the hype, Java is still way behind the field on this one. The major functional programming languages are probably in the lead, and C++ is still the next most serious contender I know of by quite some distance.

Re:The C++ STL, generics and Java

[smittyoneeach]

It's a step in the right direction, certainly, but in spite of the hype, Java is still way behind the field on this one. The major functional programming languages are probably in the lead, and C++ is still the next most serious contender I know of by quite some distance.


Not sure I'd fault the Sun folks for taking their time and doing it correctly...we certainly have enough examples of the opposite approach in the industry...

By "major functional languages" I presume you're referring to LISP? What else? Are these languages employed much beyond academic settings and Emacs macros? This is a straight question: I simply haven't encountered them to speak of.

Notwithstanding the brutal learning curve and arcane compiler messages, C++ has the least-worst set of usability/performance/feature tradeoffs I've encountered. It really only loses outright to Java in discussions of portability. The ultimate question is, in what tool have you invested your time?

Re:The C++ STL, generics and Java

[Anonymous Brave Guy]

By "major functional languages" I presume you're referring to LISP?

I was actually thinking of things like ML. Where the standard algorithms in C++ take a predicate, which is currently awkward at best since C++ cannot define simple functions anonymously and in-place, you can just pass a (comparison/equality/whatever) function in to an algorithm written in ML, quite naturally. C++ would do well to learn from this.

boost

[Fat Cow]

boost has a cross-platform threading library. also, at least some of the boost libraries will probably make it into the next C++ standard so they're a good wagon to hang your hat on, so to speak :)

NSPR is excellent!

[dagnathan]

I'm a professional developer who has been involved with high availability server architectures for the last two years. The group I was a part of was considering the exact same question, finding a cross platform library that supports a variety of sys call abstractions, when a friend who worked on Sun's Streaming Media server told us that they had used Netscape Portable Runtime (NSPR). Since then I've used NSPR extensively for my work, as well as my hobbies. During the last two years it has grown into a very mature library.

NSPR has a simple unix-like API which supports a large number of system calls, including threads, process initialization, locks, conditional variables, monitors, file and network I/O, pipes, timers and time functions, memory management, string operations, floating point routines, long long integers, dynamic linking, IPC, Multi-wait I/O, environmental variables, logging, semaphores, and error handling.

Porting between platforms is nearly seamless (at least for the platforms I've tried). It works well with autoconf and gcc, M$ Visual Studio 6.0, cygwin, and Sun's C compiler (probably others but this is all I?ve used). I've used it personally on FreeBSD, Solaris, Linux, WinNT, and Win2k, and been very satisfied. Also, unlike some of the more notoriously slow Mozilla technologies, such as XUL, NSPR has decently low memory and processor overhead.

Check out for a project overview
http://mozilla.org/projects/nspr/

and the reference for a list of technical capablities
http://mozilla.org/projects/nspr/reference/html/in dex.html

Hardware is cheaper than code!

[Anonymous Coward]

Hi,

From reading your post I'm under the impression that the reason your cross platform developing is so that the system can run under existing hardware at the college.

Try doing a business proposal that outlines the costs of cross developing (2*testing, 2 sets of code etc) vs buying a few nix servers to drop in place.

Hardware is cheap - coding and development are expensive. You can pick up a great server these days (raid 5, 2-4 cpu's, good MBd,etc) for only $3-4k.

You will also completely eliminate the migration process you'd otherwise need in going from NT to nix. You can also pitch this as part of the colleges normal server upgrade routine.

There is no way what you're doing could be cheaper than this. You will basically be throwing all that coding you are doing for NT in the trash - what a waste of your time & your clients money.

Re:Hardware is cheaper than code!

[Anonymous Coward]

Not true.
If you have a clue, you can write perfectly reusable, protable c/c++ code.
I've done it, just let the compiler determin the os its compiling on.
ifdef win32
...
else otheros
...
end

Pragmatic

[Bo Vandenberg]

Most of the posts are at least as much about the posters as your project, interesting though. My only advice is stay away from anything 'new' where your credibility is on the line.

Mostly it depends on your confidence in completion and deadline -- what you can do quickly you can redo, and modify. I didnt see you respond to the contraints put on you by your customer, unless that is flexible the java question is moot.

It does seem much more straightforward to design for the new platform not the old. Be careful that you dont fall into having to validate cross platform confidence you dont possess.

Work from your strengths : dont promise the moon if the sky will do. It would look really bad to be justifying the legacy bugs from the old system on the new hardware.

Uh, no...

[Svartalf]

You've obviously not done a lot of systems programming or you've not tried to broaden your horizons. I've written code for systems that do things like drive Opto-22 I/O, etc. and they all are cross platform (Unix and NT) with minimal differences between the actual code bodies doing the work. If you have to do a lot of differing coding for the differing platforms, you're doing something wrong with your abstractions.

Paying for software

[dwsauder]

Why should Trolltech give their software away for free? How are they supposed to feed their families?

Cool.

[Svartalf]

But to say "deficiencies" is to put it lightly.

It, for example, allows you to do evil things like modify variables labeled as "const" among other things. I had the damnedest time getting the contractors I was responsible for to get themselves out of THAT habit of Windows programming. :-Â )

if

[Anonymous Coward]

Its the compiler, stupid.
#ifedf
Solaris
else
Win32
#endif.

contract

[geekoid]

I get paid 100 an hour to design cross platform code. who would of thought I could of just asked /. to do my work for me.
He could of at least posted a list of places he's checked.

Qt on cross platforms

[Anonymous Coward]

I develop large client applications which run on various unix platforms and windows NT amoung others.
We do all our development on linux and just build and release on the other architectures.
We've found that gcc's cross compile works really well and we build our NT releases from linux.
Ohh and with regard to the IO and threading etc. Read the Qt docco theres heaps of good cross platform classes in there. Qt 3.0 will do almost everything you seem to want to do.

possible, but one warning

[aozilla]

The ideal scenario would be to recompile on the new platform without changing a line of code - will this type of portability be possible?

It certainly is possible, though you'll almost certainly want to have separate Makefiles for the two platforms. You also have to either use ifdefs, platform specific static libraries, or platform specific shared libraries/dlls.

My one suggestion is that you at the least compile on both platforms early and often. I say at the least, because you'd be better off doing at least some unit testing and QA on both platforms. You will run into problems if you don't, and you probably will run into problems even if you do. This is even true in java, trust me, I know from experience that some platforms are going to have bugs even if you do everything by the book. And other times you'll notice bugs in one platform that are bugs in the other platform, but just don't show up in your tests.

Re:portable CORBA and threading: TAO - the ACE Orb

[Anonymous Coward]

TAO -The Ace ORB is a good one aswell, and probably is the best bang for the buck performance and costwise.

GNU and Cygwin

[phliar]

'Nuff said.

Look at MKS Toolkit

[jrjud]

The MKS Toolkit Nutcracker library is stable, proven, and has support for most Unix APIs. I've used it to enable lots of software packages to be portable from Unix to Windows. It comes with all of the scripting and compile tools that you'd need - except Visual C++ which you need to use cc.

What's best for "long term, large scale" project?

[Taco Cowboy]

You said:

"Oh, and to everyone that has been promoting
ideas like "just use gcc" or "just use
straight c++", maybe you've never worked on a
large scale, long term project, but gcc is not
the best option for an app that needs to be
highly optimized and writting everything in
c++ from scratch is a waste of time ...."

Now, may I pick your mind to what is best - in your opinion, of course - for large scale, long term project?

Thanks in advance !

cross platform

[masterofevil]

Writing Generic C++ could solve alot of your problems, but for certain things MS has done a good job with MFC. The company I work for writes code in Visual Studio using MFC and then uses a third party prorgram to compile the windows projects into solaris executables, etc. You can check it out here. http://www.bristol.com/crossplatform/index.html there are other progs available I'm sure but we get good results from this one. I have used it myself and get good results from it. I develop on windows2000 and eventually deploy to solaris8.

Java vs everything

[andr0meda]

Okay, I used to code a lot of Java, and I'm now back to c++. I will tell you that I like coding in c++ as much as I like the design of the Java language. In terms of design, Java has made c# a necessity, and program languages once being the core busines of that small company, I think MS has pretty good reasons to Imitate And Extend (tm).

If you looked closely at how Java is build, you'd probably notice the tons of AbstractFoo.class classes, which contain default implementations for certain interfaces. So if we subclass from that, we don't have to write a single byte extra for any subclassing class, avoiding any code duplication. Implement once, then inherit. Ofcourse you can't design your applications and classes in the same way you design your c++ classes, but a) it's certainly possible, and b) without writing duplicate code, and c) using no difficult syntactical constructs and keeping the design clean.

Templates are nifty but invite coding and compiler bugs. A much nicer solution is the Object single inheritance dependency tree which allows for complete polymorphic behaviour through interfaces, without having to worry about all kinds of casts and vtable jumps. The internals of the compiler can be as clean as you can possibly want them because the inheritance model allows for pure specialisation (is a), and no generalisation (has a), except through extension (implementing interfaces)..

To add some juice to the discussion, there are modelling problems that even c++ can not handle correctly, because the language wasn't build to handle it. For example, consider a geometric construct object 'circle' and 'ellipse'. Objviously, the two objects are related, but how would you describe their relationship ? Mathematically, a circle is special case of an ellipse (you only have one radius), but in c++ you would quite possibly derive ellipse from circle, since it has 2 radii. Now, what happens as soon as you have an ellipse that happens to be a circle (both radii are equal)? Presto, you have a faulting software model of the mathematical model.

Conclusion: use the right tool for the right job. Java is crossplatform, stable, well thought-out, manageable, and quite capable to do anything. C++ (including stl) is fast, ugly, all over the place. STL is certainly not that portable as everybody would like, and templates are usually not supported completely. Yet our software team (including me) is currently rewriting parts of the Java core in c++ to benefit from templates and multiple inheritance and it's speed wherever we can. We have various reasons to do this, one being that the c++ standard language constructs and libraries do not offer the ease of use that we need and that a Java-like inheritance scheme offers. Internally, we use c++ to the max, but our outside sdk shell is completely like Java behaves. It's robust, transparent, fast and nicely designed. It is assured to pay off in the future, when we write our applications.

link fix

[rfmobile]

Link fix XPCOM Intro

Obligatory Ada95 plug...

[McDoobie]

Fully object oriented, if youre platform has a Validated Ada95 compiler, your software will compile and run across platforms.

Just like Java, only it compiles to a native executable and runs about 20 times faster.
Not to mention the oodles of reliability and maintenance features built right into the language.

And the Interfaces.C libs make interfacing with C++ a cinch.

I write cross platform apps with C++ all the time, but for building portable and reliable libraries, nothing has come close to Ada95.

Blah, blah, blahhhhh... Just my personal opinion. It really has saved me alot of time and hassle though.

Good luck on your project.

http://www.adapower.com
comp.lang.ada

Mcdoobie

Re:Obligatory Ada95 plug...

[r_c_chapman]

I'd second that - we build mission- and safety-critical systems here, and Ada remains
our language of choice for that kind of work.

The GNAT frontend for GCC is rather good now.
The GtkAda binding is also excellent - check
out the GNU Visual Debugger (GVD) too see what
it can do.

GNAT has lots of useful libraries and they're
rigidly portable across all the implementations.

I'll now duck under my desk for the torrent
of replies... :-)
- Rod Chapman

Beware of Slashdot Reader Recommendations

[Kristopher Johnson]

The article does not really describe specifications or requirements of the application at all, yet a lot of the responses are of the form "I have used library X, and it is is exactly what you need." (And a few are of the form "I have not used library X, but I think it is exactly what you need.")

Many of these suggestions are good, but remember to consider the specific needs of your application first, and don't choose something just because it is cool, open-source, free, cross-platform, has a nice acronym, ...

ZTHREADS

[TuxedoCamen]

ZThreads is a very very nice C++ portable threading library. http://zthread.sourceforge.net

How about Galaxy?

[rmathew]

Some time back there was a complete cross-platform environment called Galaxy. It won lots of accolades and awards and was praised by quite a few developers. I guess it was killed (almost) by the arrival of Java, though it still seems to be alive.

Not so old!

[rfmobile]

Please read the following which appears at the end of the guide.

Revision History.
* 0.5 Initial Revision. 3-27-1998 David Williams
* 0.6 Added "C++ Style casts" and "mutable" entries. 12-24-1998 Ramiro Estrugo
* 0.7 Added "nsCOMPtr" entry and mozillaZine resource link. 12-02-1999 Ramiro Estrugo
* 0.8 Added "reserved words" entry. 2-01-2001 Scott Collins

Also, beware that a stong faction within the mozilla team wanted to code in C rather than C++ because of all the less-than-compatible implementations in C++ that existed. Templates are still broke on some versions of C++. There are folks running mozilla ported to C front for crying out loud. The objective here was to cover as many platforms as possible - not just the top four or five.

Re:Not so old!

[ChaoticCoyote]

I did read the revision history, and my statements still stand. The document is based on false assumptions, poor knowledge of C++, and an inattention to detail.

That given, I wonder why the Mozilla folk didn't simply stick to C and be done with it. Why use C++ at all if you won't use so many of its features?

Re:Not so old!

[rfmobile]

Could you please elaborate on what those false assumptions are?

Could you explain what appears in the document that indicates poor knowledge of C++?

What details were overlooked?

Finally, why in this second post do you suggest they go with C (a step down) instead of the latest standard compliant C++ (a step up)? You seem to insist to either extreme rather than the compromised path that was chosen for reasons I've already explained. -rick

Re:Not so old!

[Anonymous Coward]

Could you give some specific examples. Take into account the goal was to support a wide range of systems, such as HP-UX, OS/2, SunOS, BeOS.

While a language contruct in isolation may be supported by all compilers often there are bugs that crop up when it's used in conjunction with other constructs. For instance VC++ had mainstream support for templates but pair that with nested classes and the compiler complained. Even today VC++ 6.0's support of member templates isn't complete.

The problem is REALLY compliers

[DiveShark]

Flat out Cross platform development sucks. And sucks royally. As an example you can write fantasticly great code on IRIX systems that works on an Octane but cores on an O2. Both running the same IRIX. The code works nowhere except Octane systems.

I've been writing very large apps that deploy on many *nix's, NT, W9X/NT, Linux for 9 years. In that time I've come to the conculusion that there is no true ANSI standard C or even more remotely C++ and STL.

All of the compilers are different and have their different bugs and implementations of C/C++.
gcc seems to be the most truthful to the "standard" but even that lacks in spots that will bite your butt on other platforms.

I've written code that has compiled on 13 platforms that dies on the 14th too many times to remember.

My personal favorite was the (then) DEC Alpha C++ compiler that puked on

// I don't like this but it will be fixed tomorrow

because the single quote wasn't closed. To this day I shun quotes in my comments.

Other all time favorites:

All compilers except Solaris allow for loops that declare variables inside the if statements even though according to ANSI the defintion of "int i" is ambigious. Lord knows finding and fixing that one cost more than a few dollars in 2MM lines of code.

MSVC. if there is a more stupidly liberal compiler out there, I'd like to run into it and develop on that pig only. (I'll take job offers at my email)

All *nix compliers I've used for Motif allow

Arguments args[2]
XvSetArg(....0)
XvSetArg(....1)
XvSetArg(....2)
XvSetArg(....3)

except gcc. That one tossed Linux into a problem for a day or so 'til we found it.

If you think gcc is the solution, be advised that it allowed the 'setarg(2)' without a problem, it was the 'setarg(4)' that it puked on. It's all a matter of how much buffer is allocated by the compiler by default.

When writing templates about the only complier that has a remote clue of how to do it correctly is HP. Everything else is a poor implementation/fake of templates.

AFAICT, the only way to truely do cross platform development is to write the code, compile and TEST on every platform you want to ship on and, experience the pain, and then relieve the pain/problems.

Even if you have 15 years of C/C++ experience you still will get bit on the butt when you least expect it.

There are no easy solutions. There is only hardship. Heck, that's why we are called "Software Engineers" not "Software Scientists". Us "Engineers"/"Hackers" know we are perfect, the "Scientists" truly belive they are and will always be perfect.

Shark

What about Python?

[Anonymous Coward]

Okay, so maybe Python isn't exactly C++ or C, but you can link to C code with python if necessary. I know this isn't exactly a cross-platform library, but Python is said to take a lot of hassle out of porting.

http://python.org

An Energy Management System on NT

[sambira]

develop a large energy management system

Developing this for NT will definitely reduce energy costs for the college since the systems will be down most of the time thus, with proper management, reduce power costs for the college.

Do it the easy way

[Anonymous Coward]

Why make work for yourself? Here's the easy solution: develop it on linux+XFree86 in the first place - surely you can cadge a cheap/free box from somewhere - and access it from Windows
workstations using Hummingbird Exceed or some other X server.

Perl unreadable?

[Anonymous Coward]

Run, not walk, to freshmeat.net and inquire for "perltidy".

That's Firewire...

[Svartalf]

And it is unlikely to be used in every situation- there's on-board, ethernet, and RS-485 multidrop based Opto-22. This doesn't even get into the varying embedded solutions from other suppliers that drive the passive module backplane for an Opto-22.

And, that's just Opto-22 stuff, there's all this other lovely stuff that needs driving. In most cases, they have a C or C++ API that snaps right in. For Perl, you had to build the module from that source- and you'd have to pretty much do that for every device you're trying to drive. For me and C++, I had to do very little (pretty much add it to my .so's project) to make a driver for the RS-485 multidrop B2 interface driver that we were using.

And, not to question your choices, but Perl for a systems program (which is what you're describing) on a Naval vessel safety system? Man, you're more confident in Perl and your abilities in it than I would be.

The reality is..

[alecf]

This is simply not true...nobody is translating mozilla to C and running it, and there is no faction within the mozilla community which is pushing to use C. Long ago there were a number of C-only advocates working at Netscape (jwz as an example) but they are no longer there.

The C++ portability guidelines are just that: _portability_ _guidelines_. The primary goal is to make it work on as many compilers as possible, and they are guidelines not rules. There are some platforms which, to this day, do not support anything beyond the simplest C++ templates.

Mozilla makes extensive use of templates with their nsCOMPtr class, but this particular class has been well tested on many platforms, and has many conditional #ifdef's which handle the broken compilers. But this is one major class for which the usefulness outweighed the maintenance costs. If the Mozilla team had to maintain 100 different constantly-changing template classes on 20 different compilers each with their own quirks, it would be a nightmare.

What are you talking about?

[Strawberry Pie]

You are wrong about the lack of multiple inheritance in Java. It's there; you simply have to use Java interfaces to get it.

You are also wrong about cut&paste programming. That's a problem due to bad programming, not due to an inherent flaw in Java. A good programmer will abstract out the common code into a separate method. In fact, it's ridiculously easy to do, and your point about forced redundancy in Java programming are completely off base.

Excuse me?

[Anonymous Coward]

http://developer.java.sun.com/developer/technicalA rticles/Networking/timeouts/

You don't really understand what nonblocking sockets are, do you? Obviously, the Java community is a little fuzzy on the concept, as the document above will definitely tell you. Java as a language isn't that bad, but they had some real morons at the keyboard when they pounded out some of their util classes.

I'll give you timeouts for server sockets. Which isn't the same as setting O_NONBLOCK on the socket, but hey, I'll take even that much. It's better than nothing. I just want to get my job done before the end of the day.

Show me where you can set timeouts on client sockets. That's right, you can't. At least not before you connect, which drastically reduces the usefulness of setting timeouts. They tell you to put the socket in a thread, and then do some waiting/synchronization with that thread. A brain-damaged way of going about it, if you ask me. But I guess you like damaging your brain. You obviously don't know any better.

Fortunately, they're fixing it all in JDK 1.4, with the java.nio.* package, but I suppose that's beyond your comprehension level too. You might try looking at it sometime - it'll hurt your brain, but hey, you might actually learn something.

Re:Rogue Wave (Expensive!!!)

[Anonymous Coward]

Expensive as hell, you have to pay to Rogue Wave for every license you ship of your own software...

Perl.

[mattr]

The short answer to you questions is: Probably Perl. I think it matches your tentative decisions and is the only reasonable answer to your timeframe.

Perl *is* C and it constitutes the most robust (secure against buffer attacks too) cross platform library you could ask for. You can also do all the things you need to do (and it will work even better on Unix so you can look forward to that). Networking, I/O, forking servers, it is all already done for you and tested in the CPAN (search.cpan.org). It will save you time and make the six month timeframe realistic for you (can't see it happening with C/C++ or Java frankly). It can do Qt, Tk and other GUI toolkits and can handle C and C++ like a charm. Unlike Java, which babysits you so you don't make mistakes, Perl's theme is "There's More Than One Way To Do It" (TMTOWTDI) which may be refreshing. You can still write everything in C/C++ but first get yourself a Perl architecture on top of it.

It is faster to program in Perl and you will be able to use C/C++ for the parts in which you need speed. You can even type C inline in you Perl program and it will compile it for you automatically.

You will be able to take advantage of lots of easy to find algorithms and can prototype a network-aware system extremely quickly. One event loop architecture for client apps called POE may be interesting for you.

To be fair, you could also do it in Java. Though I don't think it magically solves cross-platform issues, it costs more money, and there is a limited number of situations in which you really need to build a Java system. This system might be one of those however. It is usually a matter of what your team knows (although you get more power faster out of Perl). Then I expect you would skip Qt, and stop all the C/C++ work you are doing. If you have a Java team ready you might want to use Java then. Until the next version of Perl it is faster, though Perl usually uses precompiled C/C++ code for time-dependent things.

I am a Perl programmer and have managed Java e-commerce site development in the past (on WebLogic and Tomcat). It depends on the experience of your team as to whether you pick Perl or Java. If you want to build an animated client that talks to servers, or do large corporate multi-tier intranets, maybe Java is best. But I don't see you doing that in your time frame and I don't see it as being important to you. And of course you can make Perl-based clients, either encapsulated in an exe file or very thin and based on top of a local Perl installation.

You will probably be able to prototype the full functionality in straight Perl, optimizing later with into C/C++ on a per package (module) basis. So you need to first design yourself a clean, modular architecture of black boxes. I'd recommend doing use-case design to help discover all human-machine interaction and identify priorities; this will help you with risk management too and is applicable to any language.

You might even want to use CORBA or something similar so that these modules are providing networked services and can be changed to whatever language or system you like without fear. It seems likely that the most important thing to your client will be not the language but the ability to see a prototype, know it is extensible and scalable, and be able to get all the functionality (plus the feature creep functionality) for minimum cost.

Also Perl can run Java! And it can use commands like catch-throw and switch-case because Perl is an extensible, postmodern language that is getting very scarily powerful. In case you haven't noticed I'd recommend Perl in particular because of your timeframe, your leaning toward C/C++/Qt, and probably many other needs you will begin to appreciate such as glue to current systems, talking to devices, other information services, and so on. I have not been impressed with Java performance either engineering wise or in terms of cost, but if you have a trained team with plenty of time, lots of money, and a need for very high traffic transaction systems, Java and something like WebLogic is probably best. But you are not the phone company and I think the answer is obvious. Time to upgrade to Perl!

Some references are perl.com, perlmonks.org, and cpan.org. I think you will be pleasantly surprised. Just to reinforce the message, Java is still a totally valid option and probably most people will say Java, and something that is only Java and nothing else does have a beautiful elegance to it. I think though that you will probably save a lot of time and get tons more efficiencies from available code, being able to use different languages, being able to prototype more quickly, and being able to start *now* when it is still a reasonable amount of time instead of doing more technology surveys. You might want to post your question to both perlmonks.org and a Java site and see what people say, it might be interesting.