Slashdot Mirror

As an addition to the already mentioned, there is also a commercial grade that might be easier to use than Boost. SourcePro C++, you can check it out at http://www.roguewave.com/products/sourcepro/.

cplusplus.com?

good lord no. use it for iostreams quick reference at most.

http://www2.roguewave.com/support/docs/sourcepro/edition9/html/stdlibref/index.html

http://www.dinkumware.com/manuals/Default.aspx?manual=compleat

note that dinkumware wrote much of msvc's c++ standard library.

http://www.gotw.ca/gotw/

http://www.faqs.org/faqs/C++-faq/

Rogue Wave Software has existed since 1989.

I believe the pattern/technique you are referring to is often called "IOU" or "futures" and can, indeed, be very useful when doing asynchronous programming. There really is no need for "spaghetti" code (as you rightly point out). And, with a decent library in place, most anyone can use async calls safely.

Rogue Wave has a nice, well thought out, API for C++ which you might find of interest: http://www.roguewave.com/support/docs/leif/sourcep ro/html/protocolsug/2-4.html

This technique can be used not only with multi-threading, but also with any async-based API (such as OS and DB calls). I mention this mainly due to the fact that sometimes people forget that techniques used in one domain of programming often are applicable in others with slight adjustment. Of course, that's not always the case :-). But here, it seems to be so.

yes

PostgreSQL has had support for stored procedures and triggers for quite some time now.

it's a DB that you really need to keep an eye on from time to time. Lots of people are still touting that it does not have stored proceedures and usually those people are simply talking without knowing.

it works quite well and the link above is the first one I could find on google that detailed it.

I can find more when I'm not surfing and posting from my Zaurus on the way into work.

I've been programming heavily in C++ for many years. While I have a love hate relationship with C++'s complexity, I never thought that I would use Java heavily. But I've been working on more web services applications that access a database. The huge class library that is available with Java is a great advantage when it comes to developing these applications. Sure I can pay thousands of dollars to Rogue Wave and get some of the same features in C++ that I get for free using the Sun and Apache Java libraries. But why? The higher performance of C++ is of little use to most applications that references a database, since these applications are usually bottlenecked in the database. And when it comes to web services (e.g., XML processing, servlets, dynamically generated web pages), C++ cannot compare to Java. And then there is garbage collection, which makes develoopment faster.

There are still applications that I would not write in Java. For example, compilers or other algorithmically intensive applications that are CPU bound. There are also times when I can simplify my code by using C++ features like operator overloading (see my wavelet packet transform algorithm for example). But these applications are now in such a minority in the work I'm doing that I worry that my C++ "chops" will get rusty.

I went to a talk by Stroustrup where he discussed C++ (some cool algorithms to support linear algebra computation), future developments and C+++ vs. Java. He promotes C++ as a systems programming language. For things like operating systems, virtual machines, hardware drivers and compilers. He trumpted C++ as the most widely used programming language. What does not seem to have occured to Stroustrup is that systems level applications, where C++ shines, are a small minority of the code programmers write. My view is that C++'s star is fading.

So yeah, I'd say Java is heavily used on Linux. At work I'm part of a group developing a distributed database application in Java (this runs on top of a relational database, so Java's performance is not an issue), hosted on Linux. I'm in the process of setting up a Linux/PostgreSQL system on which to develop a financial trading application, again in Java, using XML and web services.

Er. try comparing with something equivalent, like Stingray studio. It's a high-quality product dude.

My guess is that the demand for windows specific programmers will be essentially non-existant in the future. Cross-platform apps will undoubtedly rule everywhere, even the desktop.
I hope you're right, as cross platform development libraries (SourcePro) is one of the mainstays of my employer.

RogueWave's SourcePro DB is basically what you're looking for, and RogueWave is fairly well known in the C++ comminity. The only caveat for you is that it directly doesn't support MySQL. It does however support Oracle, Sybase, MS SQL, Informix, and DB2. It also supports generic ODBC on the back, and I'm pretty sure there's an ODBC interface for MySQL out there - so you could use it that way.

Not to "me too!" this thread, but I also program with the STL on Solaris, and I find it excellent.

I own the STL Tutorial and Reference Guide and Effective STL.

On the web, I use the SGI docs and also the Rogue Wave Docs since the Solaris STL is from Rogue Wave. I find them both adequate for 99% of the programming that I do. The one thing to note on Solaris is that the STL is missing a hash map. The hashmap is technically not part of the STL spec yet, but it most likely will be for the next iteration, and the stlport implementation has one available.

Several people have mentioned one of the downsides being unintelligible error messages. This is true, but I think that (on Solaris anyways) error messages coming from templated code generally suck.

Dust 2 has an ad in it I believe - kinda tacky.

Actually i'll tout a map of my own that had a few ads and digs at a former company I used to work for. In "de_waterworks", there is a large billboard for Rogue Wave Software. Also, there's some graffiti on a wall which says "RIP Scalley" - a tribute to the not very liked CEO that got sacked by the board. Oh no, excuse me. He resigned :^)

OOP techniques can provide amazing advantages for numerical computing, and I'm surprised that there isn't more written about it. When you deal with scientific computing, it's a combination of numerical computation and the usual comp-sci stuff figuring out how to implement simulations and the like. For "the usual stuff", we know very well how OOP can help. But for numerical programming, the benefits are still there.

In numerical work, you deal with a variety of mathematical objects such as complex numbers, vectors, matrices, tensors, algebras, and so on. In working with the math, we tend to use the more sophisticated objects because they are easier to deal with (laziness) and more meaningful. But when you go to code it up in, say, Fortran, all the beauty vanishes and the nitty-gritty details become a menace. Or, you could use OOP and make up things like vector classes, matrix classes, and so on. Then the code suddenly becomes simpler, you save a little time writing the code, and make many fewer mistakes. The code looks more like the math.

I hear that rogue wave makes some very fast C++ libraries for numerical work, though I haven't used them personally. There are other collections out there as well, I'm sure. My main beef about other languages such as C++ and Java is that there is a blatant lack of concern for numerical programming. Here are some rants:

• Complex numbers: In C++, there are a variety of ways of handling complex numbers, but there is no standard as far as I can tell. So by using complex numbers in C, you aren't writing portable code.
• Powers: This is an old issue. Why on Earth can't modern compilers handle integer powers efficiently (Fortran's ** operator)?? You must realize that in numerical work, you use **n operations about half as often as addition and multiplication!!!
• down-casting: 1.8 / 2 = 0? In Fortran, binary operators taking different types of operands generally do the "right thing" which is to promote integers to floats, floats to complex, single precision to double, etc. C and other languages do the opposite, which is almost always NOT what you want! This must be the #1 source of bugs in C numerical code.

I hate Fortran, I really do. But when doing pure numerical work Fortran's actually a lot better than most other languages I've seen. There's no good reason why other languages couldn't be reasonable in this regard.

Okay, I'll admit that the only two genuinely OO languages I know are Java and C++. And these both derive much of their behavior from C, which is not a very "modern" language any more. But it is still a lot younger than Fortran. (Yeah, Kernigan and Ritchie were going for speed and simplicity in the mid-70s, I understand.) Anyway, in spite of wanting to borrow syntax from C, why can't anyone simply decide to improve on the bad old features of C like those mentioned above?

Whew, okay. I'm done ranting now. I feel much better.

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.

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.

I guess I just imagined using Rogue Wave products then. Or maybe I was smoking crack.

Qt has only one major problem: it's written in C++.

This is actually Qt's greatest asset.

But that one's a problem from which I have never seen a toolkit recover without the marketing dominance of Microsoft.

You should go out more often : RogueWave
Ilog

try to get an average-skill C++ developer up to speed on a project that's been under development for a year or so, and you'll be spending months explaining why you used the language the way you did

Too often true in practice, not true with Qt/KDE.

You know, that language that Linux, X, GCC, BSD, Apache, Bind, Sendmail and most of the rest of the civilized world's software is written in.

As I said, you should go out more often. There's a whole universe outside of the tiny rosy world of free software.

If you want to use a C library from C++ you can.

But it's highly suboptimal. Frankly it generally sucks big time.

The matrix is a little hard to read because there are so many languages in it....

And how many are complete enough to actually be used to develop a big application right away ?

The conclusion of my experience of 3 years helping to maintain Gtk-- and trying to develop with it, followed by 1 year of programming with Qt professionnally and with Qt/KDE at home is that Qt/KDE is, without a doubt a vastly better and more productive development platform than Gnome is at this time.

The language bindings point is totally moot, and after all these years and so few mainstream Gnome applications written in anything else than C, may be people should re-evaluate it. I wrote about it two years ago already, and as far as I can see most of my claims are still true.

When I started using Qt at work, I found myself to be more proficient with it after just a few days than I ever was with GTK+ or even Gtk--, where I constantly had to lookup either in some barely existant documentation or at the source code itself, or needed to add yet-another-wrapper for some strange struct I'd need.

A direct consequence of this is that whenever I wanted to write a patch for a KDE app, even fairly large and old ones (konsole, kmail), I could get a moderately complex feature done in just a few hours, over code I had never seen before.

Contrary to what you think, the level of entry of KDE for a programmer is way lower than for Gnome. Even a C++ beginner can produce useful code after just a few days of learning. This is not true for all C++ toolkits or projects, but it is true for Qt and KDE.

This is the reason why KDE's development pace is so quick, and why so many high-level applications like konqueror, kdevelop, or koffice could be written by teams of less than half a dozen people. Programming under KDE is just so easy.

I suggest you try it. You'll be surprised, as I was too when I switched.

I could be wrong, but I think they pretty much bought it from someone else

That doesn't mean they didn't invest and pay for this technology. It just means that sometimes what Microsoft calls inovation is really licensing,merger, acquisition, and creative funding.

timbu

I think the only way that something like this would work is to allow any type of license.

Having said that, I think it's a great idea. Personally, I've dealt with RogueWave components a lot, and I'm not impressed, even if they have started releasing Linux versions :) I think open source could reach their mark very quickly.

Yes cross platform C++ development is not there and few people are trying to make it work. I consider this a problem.

CORBA is neat. It is very cool and fun for writing distributed NETWORK applications. CORBA at this point is only well supported for C++. Several people do have C bindings, but all that I have played with are weak compared to the C++. If I wasn't distributing my processing across a network I might think again about why I need CORBA.

Perl is nice, for any application of any size be prepared to write your own interface. Consider tcl, doesn't do that much, but it embedds itself really nicely and doesn't have any licencing issues to worry about.

Java, is cross platform ready, has some CORBA support, but I believe you have to be careful what orbs you use or write your own interface.

I have worked on several projects that did UNIX/NT work. Both were with companies with a fair ammount of money.

One solution was purchase roguewave (which finally supports linux!) and Iona/Orbix. Roguewave provide very nice C++ libraries, and they are cross platform, among UNIXen and NT. I would love for someone to copy these to the open source world. Orbix is very feature rich, deploys on UNIX and NT (no Linux booo), though at times can be buggy, especially if you try to integrate security into your application. But iona does provide easy programming intrerfaces. End users saw web pages in this particular application. Used CORBA to wrap legacy applications and then quickly integrate them into new applications. Also I have seen nice CORBA implementations on Mainframe which is extremly nice, since talking to mainframes is generally a nightmare. but CORBA isn't very portable either and you have to commit to a specific CORBA.

The second project stuck with C, used plain old Socket Communication. Went with writing an object layer in house (simple but did the job) then writing a tool to create the .h and .c files out of the simple object language (simply impliment objects as structures, or multi-dimensional arrays) and just use a C compiler to get your binaries. This doesn't give you any performance hits compared to C++, and it makes your underlying application code very portable. Abstract out your database interfaces and don't wory about them untill you work with a new version. Build your own communication server that all applications register there messages with and recieve messages from (old style of programming, but it works) and use Inet Sockets. The end result is you can get applications that are n nodes clusterable and the platforms don't matter. The GUI a poor choice was done in this regard they went with Neuron Data (Now Blaze Soft, Formerly Elements, formerly OIT) which really is as slow as tcl/TK at run time without the portability. They now have a Java product that I haven't tried. Right now either TK or Java make the most sense for GUI's to me.

Having seen what happens when you go vendor bound, building code interfaces in house with extensability and portability in mind gives you the greatest flexability in the future.

so that is my thoughts about how to tackle cross platfrom distributed appliations.