Seeking Multi-Platform I/O Libraries?

An Anonymous Coward asks: "I'm just getting ready to plunge into a new project, and joy of joys have been given complete freedom when it comes to the implementation language - so long as the program will build and run on both x86 Linux and Windows. Now, I don't need a GUI, this is systems stuff only (processing binary executables in fact, so lots of bitfiddling and big nasty algorithms over hairy data structures) so pretty much all I need are standard IO libraries. C is currently at the top of my list..but what other language should I be looking at? I'm happy to learn a new one, and have the go ahead to do it..like I say, they want absolute speed. Can someone suggest a better language? C++ is out, it does come with a speed hit (using C++ properly anyway, not as a souped-up C). If I'm gonna take the speed hit, I may as well consider something like Ocaml which might let me claw the speed back with better algorithms and data structures.."

Comments

-1, Flamebait

[JabberWokky]

C++ is out, it does come with a speed hit

[ in my best announcer voice ]:

Let's get ready to RUMBLE!!!

--
Evan

Re:-1, Flamebait

[jason_watkins]

The only speed hit relevant to c++ would be using virtual methods, which is just one of many tools c++ provides you.

Templates, for example, allow for similar common factoring of code without resorting to inheritance and virtuals.

C++ certainly has it's downsides, but please don't reject it based on arguments that have been repeated over and over without basis.

Re:-1, Flamebait

[RoninM]

The only speed hit relevant to c++ would be using virtual methods, ...

Ideally, perhaps, but not in reality. There's definite, significant overhead in using much of C++'s standard library. Time a loop using IOstreams (std::cout) against one using std::printf(). In GCC 3.0, at least, you should find the C++ significantly slower. (In fact, slower than a similar test in Java.) C++ is a good language with a lot of critics, but just because the criticisms have all been heard before doesn't mean they lack merit. One can say most of the performance problems aren't inherent in the language, and that'd be true, but what difference does it make if all of the implementations are so bad?

Re:-1, Flamebait

[Anonymous Brave Guy]

You're right on the money there, unfortunately. There is no theoretical reason for C++ to be slower than C at all; if you implement the equivalent functionality to, say, virtual function dispatch in C, then it's likely to run with at least the same overhead as if the compiler does it for you in C++.

OTOH, standard library implementations mostly suck. At least they're improving, though, sometimes drastically; check out SGI's latest. And the template implementation actually helps the optimiser a lot in some cases. When you've finished comparing cout and printf, try qsort vs. the C++ library sort and spot the difference.

IMHO, though, the biggest problem is still the optimisers behind the compilers. We've got decades of experience optimising C to high levels. We've got perhaps a quarter of that optimising things like templates, exceptions and so on in a C++ compiler. Again, it's getting better, and sometimes quantum leaps get made as a new implementation technique is discovered, but it's still got a way to go. That is where the really big practical disadvantage lies, at least for now.

Re:-1, Flamebait

[Anonymous Coward]

C++ I/O has the historical baggage of synching its cout and cerr with C's stdout and stderr respectively. This incurrs a sizeable hit. Also, the morons at Sun made _every_ _frigging_ _operator_ in the iostream classes THREADSAFE with mutex locks! Why??? This is the stupidest thing in the world. Let the programmer use external synchronization if warranted - but do not slow down the general single threaded case! The GNU idiots followed suit by copying Sun's reference implementation as per usual.

Re:-1, Flamebait

[jason_watkins]

Not so. Go benchmark. Iostreams often beat printf et all. Not accross the board mind you, my point is merely that it sometimes does, and that accross the board, the performance delta is so slight as to be a non-issue. Review Stroustrup et all's presentation at SD2000, they addressed this issue.

A Virus Scanner

[Anonymous Coward]

An Anonymous Coward writes:

> Now, I don't need a GUI, this is systems stuff only (processing binary executables
> in fact, so lots of bitfiddling and big nasty algorithms over hairy data structures)

Sooo, you are writing a Virus Scanner ...

Try lots of implementations....

[borgboy]

You will likely find that algorithmic improvements will gain you more speed than IO library efficiency, as long as you avoid VB. Heck, I'd even strongly look at Java with a good JIT. Don't write off anything 'till you've tried it.

Re:Try lots of implementations....

[JanneM]

But given the same algorithmic improvements,you will of course be able to gain additional speed by choosing your language.

If speed were not so critical, I'd suggest Perl, actually. With the speed demands, and the need for cross-platform IO, I think C is probably what you want to use.

/Janne

Re:Try lots of implementations....

[ThePilgrim]

I wonder if you could rip the Perl abstracted I/O layer, its written in C and is cross platform

Re:Try lots of implementations....

[larry bagina]

If speed were not so critical, I'd suggest Perl, actually

If I'm not mistaken, he said "lots of bitfiddling and big nasty algorithms over hairy data structures", not "text processing".

But then again, you;d probably recommend Perl for embedded real time applications, too...

Re:Try lots of implementations....

[JanneM]

Perl is actually very good for bit fiddling; the pack and unpack operations would be excellent for this type of work. And it is also a very nice language for manipulating complex data structures with the ability to dynamically create and manipulate hashes and arrays.

Perl is no good at real-time tasks, of course. I doubt I would consider Perl for heavily calculation-oriented applications either.

/Janne

Consider Python... Wait! Don't leave!!!

[Phoukka]

I know it's a bit of a stretch, but consider Python. Prototype the heck out of the system in Python, profile the application, then recode the bottlenecks in C. Use SWIG to generate your interfaces. Easier to program, easier to extend, easier to read/maintain. Shorter programming time, too.

You'll be happier, your fellow programmers will be happier, your successor programmers will be happier, and the chewy parts of your code will still be really fast. Think about it.

I have a similar question:

[Cuthalion]

Hi, yes! I have a similar question: What is the best language for What I Want To Do? It needs to be able to handle floating point numbers. I don't want to use perl, because it's slower than C but messier than Smalltalk. Also, should I use vi or emacs to edit my source?

But seriously.. Every language provides standard support for file IO, unless it's totally half-assed*.

If you actually want to get helpful answers, you might provide a little more information. For instance: How much analysis will you be doing on the files? How much data are you dealing with? Is this probably going to be blocking on input all the time, or does run speed actually matter? How large and/or complicated will your program be? Does cost of deployment really matter?

* Or halfway totally assed, or whatever.

Re:I have a similar question:

[Anonymous Coward]

> What is the best language for What I Want To Do? It needs to be able to handle floating point numbers

Use J2ME!

Re:I have a similar question:

[sinserve]

Long answer:
What you are asking for does not need an entire language, just a
library.
Get the best library out there, and scan through list of its "binding"
languages, then pick the one you are most comfortable with.

Short answer:
Common Lisp (CLISP + CLOCC + emacs + ilisp) is a killer.

Re:Consider Python... Wait! Don't leave!!!

[Anonymous Coward]

Yes and no. Python is a nice language, and potentially useful. However, where I work we have a "legacy" system written in python with SWIG (interacting with C++).

The problem is that under large workloads (which is normal for us) you end up with python spending more time marshalling and unmarshalling objects. It's a PITA. I blame this mostly on SWIG (which I am NOT a fan of. Don't get me started on what the maintainers consider good development practice.)

Python's a great choice if you can do it all natively. It's also a great language to prototype in and then "translate" to another language like C++ or C or Java. (depending on task and preference.) But I wouldn't do the python+swig thing.

[Note: I'm only posting anonymously to protect my identity. There are certain political factions at work that read /. and would be very unhappy with me discussing this.]

Yes, try O'Caml!

[Tom7]

Yes, I would really recommend O'Caml. Here's why:

If you just write the same program you would have written in C, the speed will be quite good, probably about 20% CPU-slower than C. (And if your program is IO-heavy, you might not notice this at all.)

If you have any sort of limited time or interest (as most projects do), you'll be able to write a much better program in O'Caml than you would in C, because:

- Because it's safe, you won't need to ever spend time tracking down or debugging core dumps or memory leaks. Because it's statically typed, a large percentage of bugs are caught at compile-time.
- If your program is interacting with the network, you won't need to worry about buffer overflows, format string bugs, or most of the common security problems.
- O'Caml has a much richer core language than C, with support for algebraic datatypes, pattern matching, higher-order functions, threads, modules, and objects. You can do a lot of great stuff with these.
- O'Caml has a nicer (though not as nice as, say, SML) module system, which keeps your program from getting unmanageable, and helps isolate faults to a particular module.

And by better, I also mean faster -- development wisdom says that algorithms and data structures are what matter most, not just the instruction-level efficiency of your code.

Of course, if you don't know the language, then it will have a higher startup cost for you. But I think it's worth it; you'll learn a different programming style that can help you think in new ways even when you're writing code in Old School languages. =)

Use OCaml

[__past__]

Scince you mention it yourself, why not really use OCaml. The "speed hit" isn't too big compared with other languages, and optimizing "nasty algorithms over hairy data structures" will definitly work better than in C.

Of course, it has a portable IO lib - just because the corresponding module for more low level stuff is called "Unix" doesn't mean that it isn't available on Windows as well, with some restrictions.

c++ is out?

[Aniquel]

I'm really very curious why you decided that c++ is out. I understand that the common (mis)perception is that c++ is slower - but let me ask this: Have you ever benchmarked it? If not, then I strongly suggest that you don't discount c++ out of hand. It has the cross-platform io facility of which you speak (streams), already has all the (completely debugged) algorithms and advanced data structures. Look, nothing is going to be faster than c (except for hand-tuned assembly) - If you absolutely need every little bit of performance, then don't bother with a language other than c. But, if you're looking for a language nearly as fast, with a complete template and streams library, that's portable, then you ought to seriously consider c++. (btw, I've written extensive projects in c++ (25000+ lines) - There isn't much performance difference, and the benefits to using it far outweigh any other penalties.)

Re:c++ is out?

[4of12]

Right on.

Benchmarking is the key. And, it pays to do it every few years or so, as compilers and hardware and software platforms evolve.

While not related directly to your I/O question, a colleague found that earlier benchmarks we had done for floating point intensive calculations which showed FORTRAN beating C++ by about a factor of two were outdated. Current tests show them comparable in speed (as long as you're not too careless with your C++).

I think I/O in C++ can be reasonably fast for most purposes, but again, as long as your careful about how you do it.

By all means, benchmark!

Re:c++ is out?

[jmv]

My experience shows that in many situations, C++ can actually be much faster than C (not always of course). The reason: templates and inlining. With inlining, not only do you save function calls (which usually aren't that expensive), but the optimizer is free to use common sub-expression elimination across the "call". With templates, you can produce better generic code. Just compare the C qsort to the C++ sort algorithm. In the first case, you go through a function call by pointer (for the comparison operator) which is *very* expensive, while in the second case, the function will be optimized just for the type you need.

Re:c++ is out?

[gkatsi]

Even though you have it right that it is a misconception that C++ is slower than C, you miss one very importatnt point: the supposedly slower features of C++ (like virtual functions) do not have an equivalent in C. In fact, in order to achieve the same functionality in C, you will have to hand code what the compiler already does for you in C++. But we already know that compilers are better than humans in avoiding errors and applying the same solution over and over with good efficiency.

Moreover, because the compiler knows what you're actually trying to do, it can often perform optimizations that are not possible in C. For the example of virtual function calls, the equivalent in C (both in terms of functionality and efficiency) is calls using function pointers. The difference is that in C++ the compiler often knows the dynamic type of an object (if it's an actual object and not a pointer or reference) and can optimize away the virtual function call and replace it with a static call (or even inline the function). The C compiler is unable to do that.

So yes, there are features in C++ that have a performance penalty, but they have no equivalent in C, so the comparison is invalid.

As for ocaml or other FP languages, I think it's a good idea to try them. Besides the productivity and maintainability gains, you may also have actual efficiency benefits. Again, because the compiler knows what you're trying to do in a high(er) level language, sometimes it can perform obscure but very effective optimizations that can beat what an average or even good C programmer can do.

Re:c++ is out?

[hotpotato]

I agree. Here's why using C++ properly doesn't incur much of a performance penalty: The only difference performance-wise when using 'basic' C++ (i.e. classes, inheritance, perhaps operator overloading) is during method calls to class instances, because the this pointer must be passed as an extra argument to the method. This means an extra push instruction on the caller side. Adding this extra instruction isn't much of an overhead.

The next additional overhead involves virtual methods. A call to a virtual method costs much more than to a normal method, because there's a memory lookup involved into the vtable.

The nice thing about C++ is that you opt-in to these extra features. Don't use virtual methods if you don't need them. And if you do need them but can't live with the overhead, sometimes you can use templates instead, which use up more memory but are just as efficient as normal classes.

Don't forget the 90-10 rule. 90% of the program time is spent running 10% of the code. Even if you build your entire program using virtual functions, at the end you can profile it, find those 10% (usually less than that, according to my experience) and optimize them using improved algorithms, time-memory tradeoffs, inlining, and other such methods. I find it hard to believe you'll regret using C++ over C because of the performance hit.

Re:c++ is out?

[strangemoose]

Did you or any of the people who replied to you actually read the original post? He said he had to do some nasty input etc... fstream, just won't cut it. he needs some thing as low level as stdio, or even just 'open', 'read', 'write', 'close'. (notice no 'f' prefix)

Re:c++ is out?

[Anonymous Coward]

Do even know C++? Just know C doesn't mean you know C++ too.

nobody's talking about fstream.

Re:c++ is out?

[jason_watkins]

Go do a benchmark, stream based io often beats atomic io. Never automaticly equate low level code with fast code. Just because it's specified in a way close to the machine representation does not mean it's effective code. Anyone can write slow c, and slow assembly just as easily as they could write slow c++ or slow ocaml.

Re:c++ is out?

[larry bagina]

The difference is that in C++ the compiler often knows the dynamic type of an object (if it's an actual object and not a pointer or reference) and can optimize away the virtual function call and replace it with a static call (or even inline the function).

This is the police. Put down the bong and come out with your hands up.

Re:c++ is out?

[larry bagina]

If you're going to read an entire file into memory, the low level open()/read()/close() calls will be fastest. If you'll be reading a few bytes at a time, streamed IO with buffering enabled will save quite a few disk hits & context switches.

Re:c++ is out?

[kraf]

> It has the cross-platform io facility of which you speak

My work experience is that c++ is not easily portable.
All c++ compilers I've worked with on various unixen had some kind of brain damage that made most of the advanced c++ features (like templates) near unusable.

Re:c++ is out?

[Anonymous Coward]

My work experience is that c++ is not easily portable.

So how long has it been since you've had a job?

Re:c++ is out?

[Anonymous Coward]

Most real C++ compilers do a damn good job of inlining otherwise expensive method calls. Just mad 'cause you've got nothing to put in your bong?

If you realy have an open house

[ThePilgrim]

Try using Ocam with a transputer board or 2 pluged into your PC

Java, Nothing but Net

[yancey]

Java is very portable and can do all that bit fiddling just as well as C. The syntax is very similar to C, so it shouldn't take long to adapt.

Once you have written the progam for Linux, the exact same code would work on Windows. Write the program once, not twice. Save yourself some time.

You won't have to worry anywhere near as much about messing up a pointer somewhere or about allocating the wrong amount of memory.

Performance? If you're worried about performance, then you have not used a recent copy of Java. Find Java 1.3 or 1.4 and try it for yourself. I've got a Java program that scans through about 6,500 Novell user accounts in under two minutes. Performance is not a problem unless you want speedy GUI.

Since you're not needing a GUI, I think Java would be an excellent choice.

Re:Java, Nothing but Net

[Arthur Dent]

Exactly.
And at some point, if you decide you want a GUI, take a look at IBM's SWT instead of AWT and Swing. Programs written with SWT are indistinguishable from native programs on Windows, Linux and Solaris (That's all I've tested BTW, and in addition SWT has bindings for Photon so you can run it on QNX!).

Re:Java, Nothing but Net

[hotpotato]

Performance? If you're worried about performance, then you have not used a recent copy of Java.

But if you do get into a performance problem in a particular section of your program (from the sound of it it'll probably be an algorithm-related part), you can always implement that part in C and call it from Java using JNI. This still leaves most of your program cross-platform, while solving the performance bottleneck.

Re:Java, Nothing but Net

[Anonymous Coward]

Except JNI calls are SLOW; which hits you doubly hard because it slows down exactly the thing you're trying to speed up.

Re:Java, Nothing but Net

[Anonymous Coward]

Depends where you stick your JNI call. A tight loop doing JNI calls would hurt performance, but a single JNI call to a tight loop could help quite a bit.

Use Logo!!!! (not...)

[walt-sjc]

If you know C best, use C. If you know Java best, use Java. Ditto for Perl.

Really.

The better you know a language, the faster you will be able to write your app, the more optimized it will be, fewer bugs, etc. This is common sense.

(I was going to have a really smart-assed comment on Logo, but I'll reserve that for later....)

Compiled FORTH

[morbid]

Use a threaded compiled FORTH implementation, if you fancy learning a new language. In fact, you can start off by writing yourself a little FORTH nulceus in C to bootstrap itself. You can easily add new primitives (ie machine code) by simply writing a new function and plugging it in to the dictionary, or even a c function with inline assembler, if speed is that important. You can write your own words to allocate and initialise memory for all the data structures you need etc. It'll be a great learning experience.

more than just a language performance question...

[CaptainAbstraction]

This is more than just a language question. It looks like you're starting to get the standard responses already for Java, C++, etc.

But all of these opinions presume that you're fairly experienced in these languages. Ignore them.

Language experience/familiarity is THE factor here, so don't discount it. Someone who has been eating and breathing Java would likely produce speedier code than someone who is just learning C, for example.

Your employer/client wants SPEED. This project involves hairy and complicated bit fiddling. I would suggest NOT using this project to learn a new language, for the risks outweigh the rewards in this situation.

If you choose to use a new langauge for this critical job, you're setting yourself up for disappoint. Do not forget that you're going to have to go through the all the growing pains associated with a new langauge. You're going to spend weekends tracking down (and learning from) all the newbie mistakes one makes with a new langauge. You are going to encounter new and unfamiliar bugs at all levels - logical design, physical design, semantic, syntactic.

Do you really want to spend your nights and weekends figuring out what the heck is throwing some particular JAVA exception seamingly at random? Why your C++ function template specialization is being ignored?

Learning a new language is exhilarating, but that will quickly turn to FRUSTRATION when you run into that weekend-long show-stopper bug.

With your product being measured by performance, and with deadlines looming... When it comes down to crunch-time, I think the choice is OBVIOUS!!

Choose a different, fun project to learn a new language. But for this product you're delivering, I would encourage you to stick with the tools you know and love.

Best,
Captain Abstraction

C will do the task...

[Anonymous Coward]

stdio and UNIX I/O (depending on what you need) will work on both Windows and UNIX.
From the C language perspective, and ignoring GUIs, Windows and UNIX are very similar. Windows has a UNIX compatability layer so for the most part you should be okay with I/O functions.

Multi-threading libraries

[rkgmd]

Even though both NT and linux are POSIX compliant, there are enough quirks in the implementations, especially with regard to multi-threading libraries. As long as you use C or C++ (or any language that does not provide both a rich threading interface and good runtime support), consider using the NSPR libraries that are meant to provide a rich set of cross-platform interfaces.

Use C

[mccalli]

Looking for an IO library standard across platforms?

#include <stdio.h>

Says it all really.

Cheers,
Ian

Re:Use C

[josepha48]

I'd add:
#include <stdlib.h>

Yeah, that does say it all. I have been working on such a thing. I have been attempting to do a cross platform library. So that it will at least be source compatible.

This is really difficult to do. If all you are doing is memcpy, file io, printf, then it is possible. If you get into sockets then it gets a little more machine dependant. Use log on and off, is even worse.

One option is to pick a cross platform C API. glib may work. I think there is a port to windows and if not it still should work under cigwin. Its speed is not that bad and it gives you things like sockets and linked lists and all the things you'd need for a daemon process or simple none gui program.

Memory-mapped files

[sergeyli]

I had a lot of good experiences using memory-mapped files. If you need random access to file body as opposed to sequential (streams), pick whatever has MM files in it. That would be C, C++, or Java SDK 1.4.

learn C++

[j09824]

O'Caml is an excellent choice. I think it should definitely be your first choice.

Nevertheless, C++ can be fast, powerful, and simple as well. People have problems with C++ if they don't understand it well or if they work with people who don't understand it well. That is a real problem (most commercial and open source C++ programs and libraries are awful), but don't blame the language.

Java

[alanjstr]

Ok, so Java isn't the greatest at performance, but it is cross-platform.

Don't forget the Apache Portable Runtime

[Anonymous Coward]

Apache 2.0 is based on an excellent platform independent IO library (and many other cross platform data types, data structures, etc), the Apache Portable Runtime. It's written in C, and it's fast.

http://apr.apache.org/

Re:Consider Python... Wait! Don't leave!!!

[Anonymous Coward]

Ummmm... no.

IMHO Python has 3 flaws that make it unacceptable.

1. Using indentation instead of brackets to define blocks. I used to think this was a good idea then I actually looked at code written this way. Most editors have a "find matching" feature which I find handy to navigate code. No brackets and that feature is almost useless. Now where did that functions start?

2. A lack of variable declarations. First varaible declarations are free docmentation. They're a really nice way to know what varaibles someone else's code uses. Secondly typos in long vaiable names can create annoying bugs. If the compiler/interpreter will find them for me so much the better..

3. Function definitions in the class definition. This makes class definitions tend to be multiple screens which obscures the layout of the class.

wow

[sinserve]

Your "speed" priority, and the binary processing bit, got me almost sold, and then
I saw O'Caml!!

You quiche eating wanker, how COULD you forget assembly? Isn't that what programming is
all about? And WHY are you comparing C to O'Caml, a fine assembly macro language, to
shity ML dialect used by equally hard-wanking mathematicians and abstractly thinking
creatures? If these wankmaticians knew how the world operated, they would not
have invented recursion let alone APPROVED of inductions as a sane, corner stone
princible in their so called "art". Induction is only possible as long as the
the "counter" register can hold your index, and recurssion is the crackwhore narcessistic
twin sister of iteration (there is nothing she does, iteration can't do with
a well placed label and a jump.)

Listen to me son, read Quine, Boole and DeMorgan, get the manual to your processor,
and "script" at the level of the ONE TRUE ABSTRACTION LAYER.

Re:wow

[popeyethesailor]

Are you Mel by any chance?

Using C++ properly????

[PD]

How can you use it improperly? C++ is an object capable language, not a strict object oriented language. If you want to use objects, then fine. If not, then please don't.

Object oriented development is a tremendous thing, useful for many things, and a marvel of overcoming complexity through abstraction.

BUT, OOP is not the solution for everything. There are many problems that don't need an object structure, and should be written another way. Above all, drop the notion that C++ should be used only a certain way to be proper. The latest cool feature of C++, the Standard Template Library, isn't even object oriented - it's GENERIC, because that type of programming just was the right thing to do for that library.

Re:Consider Python... Wait! Don't leave!!!

[Circuit Breaker]

Have you actually tried using Python? If you have, it's probably for not enough time or using the wrong tools

1. Using indentation instead of braces kills the religious "coding convention" wars before they have a chance to start. It's easy to read, it makes what you read and what the parser read consistent (Never chased a mismatched indentation/braces case, have you?), and it just plain works. Where did that function start? Any editor worth its while can tell you that, most of them already have a macro that does this. If you ever used Scintilla/SciTE you'd probably never go back to "find matching" only style editors unless you were forced to - collapsing functions makes a lot of sense even in the curly brace world (more so in Python's indentation world).

2. There are add-ons that can enforce that, but that would be missing the point. The Python interpreter and language specification goes to some length to catch this kind of errors, and although it's a long way from e.g. C or Java, it caters for the common cases. Typos in long variable names may create annoying bugs, but ones that are _always_ easy to identify and fix. True, they wait for run time rather than compile time; personally, the number of bugs of this kind that I get is consistently low enough for this not to matter (and, since Python code tends to be an order of magnitude shorter than any other language except Lisp or APL, it's more than worth it. Plus, there's a Lint for Python if you insist). Variable declarations are NOT free documentation. "Object my_object = new Blah();" is not more informative than "my_object = Blah()". It's the variable's name that's the documentation, rarely it's type.

3. Oh jesus. C++, Java, SmallTalk, LISP and just about any other language does this too. What language are you using? Plus, try scintilla and you'll be amazed at what a GOOD language sensitive editor can do (for any of the above languages).

TCL

[WetCat]

Try TCL.
For me, using TCL my performance increased by 60%
(especially when using its [Incr TCL] OO Extension)
TCL works on most unices, Windows, Mac, VMS, Palm Pilot...
Tk graphical library is so successful that other languages
(perl, prolog, python) are using it.

Use ASM For Pure Speed

[rootmon]

NASM is a great multi-platform assembler with useful macro syntax, where you could do defines for Windows and Linux so you call the same macro names for both. Do the low-level stuff in ASM as .dll's, .so's, and you can write the rest of your code code in your language of choice and call your libs.

No, thanks.

[Rick the Red]

I'm not seeking Multi-Platform I/O Libraries. Thanks for asking.

One Word:

[brunes69]

QBasic.

Re:One Word:

[Gaurang]

I am glad that somebody apart me ever used QBasic.

QBasic was a cool language, and I used it a lot in my childhood days....when I was learning programming...

But now I just love C/C++....its more structured and coool....i just love it...

How about AT&T's sfio

[Anonymous Coward]

You may want to try AT&T's sfio, coauthored by David Korn of the shell by the same name fame.

Re:Consider Python... Wait! Don't leave!!!

[Anonymous Coward]

I stand somewhat corrected.

1. I don't have that kind of trouble with braces. Though I will accept that a good editor can handle that.

2. Variable declarations make fairly decent free documentation since all the variable names tend to be in one place.

3. However C++ does not require it.

As far as editors go. I use vi/vim. There may be a mode for collapsing things. I haven't noticed it yet.

What speed hit?

[SIGFPE]

Last time I checked people were writing faster readable code in C++ than in C.

A smart C++ programmer can use template metaprogramming in a library like Blitz++ to automatically build code optimised for the job. To write the equivalent code in C is possible but it's much more laborious and harder to maintain.

There are good reasons not to use C++. Performance isn't one of them.

Re:What speed hit?

[strangemoose]

Sure it is. ever clocked the time it takes for KDE to start up? Sure the runtime speed is fine... but load time for all that loadtime linking is too much.

Oh, and before someone says, Just aply the prelink patch... Tried it, but I can't spare my computer for the days it would take to compile all that C++ code.

Re:What speed hit?

[jason_watkins]

wtf are you blathering on about. KDE's dynamic linking broker has nothing whoatsoever to do with the performance of c++ in general.

That's like saying c sucks because my linear search of my 100meg dataset is slow. Perl is much faster when I use binary search, therefore Perl is always faster than c.

Now, you *have* raised one valid point about template heavy c++: It can be a bit slower to compile. So far, this has never been an issue for me. By far the longest compiles I've had to deal with were output from yacc, which is of course, POCC (plain ole c code).

Re:What speed hit?

[strangemoose]

Not talking about KDEs dynamic linking broker. wtf are _you_ blathering about? What it has to do with is the high overhead of using deep levels of inheritance. and the memory usage.

Re:What speed hit?

[SIGFPE]

These traits that you point out aren't necessarily C++ problems. Yeah...some people get carried away with Russian-doll like hierarchies of C++ - but some people don't. Similarly there's no reason for C++ to have much of an memory overhead compared to C. If you use virtual functions you might get a tiny performance hit and memory hit but plenty of C code uses tables of pointers to functions. I think the problems you're seeing are due to the way programmers who like bloat are drawn to C++ rather than being a C++ problem inherently.

Re:What speed hit?

[RoninM]

You're clearly confused. The performance of ld.so has little to do with C++ and nothing to do with deep levels of inheritance. There IS an issue with virtual functions (vtables) and relocations, which is probably what you're trying to reference, but this isn't really an issue with C++ and the problem can be addressed by lazy binding of vtables. It's also completely moot when we're talking about a low-level C++ application: the chances of him needing to do heavy dynamic linking or having a vast framework of objects with significant numbers of virtual functions is so slim that it doesn't even bear mentioning in this discussion.

duhhhhh

[ajw1976]

If you're really looking for performance, then you should look no further than C#. I wrote a C application and a C# application to compare the performance. The C app was over 1500% slower than the C# app. Then of course, I did have some infinite loops in the C app ;-)

Newbie, shoot thyself

[jo42]

Write it in Intel assembler. All the bit fiddling you want or not. Then simply cobble up some I/O code for the target platforms you want to run on. Should take you about an afternoon - if you know what you are doing, which it sure doesn't sound like from your dumb question.

VB

[Anonymous Coward]

The best tool for low-level IO and cross-platform stuff is VB. A lot of people don't realize it's cross platform, but it can be used to develop applications for windows 3.1, 95, 98, Me, XP, and NT 4/5.

Re:VB

[zaqattack911]

that's a joke right?
you didn't mention any platforms other than win32, or win16 :)

Re:VB

[Anonymous Coward]

yes it was a joke. Sort of.

A couple years ago at work, they developed a web-front end for our terminal-based database backend. In the presentation, they remarked about how difficult it was making it cross platform. Cross platform? Yep, it works with IE 4 and 5 under Windows 98SE or NT 4.

General purpose vs. best of breed

[Kirruth]

You can choose to use a general-purpose language which has a good spread of capabilities, or you can go with a best of breed language in the area you are trying to work in.

For general projects, I use a mix of Python and C++. I'd say the best of breed languages for text would be Perl, math would be Haskell, and for getting down to the metal would be Assembler.

For what you are trying to do, the no-brainer choice would be souped-up C, i.e. C which uses a few C++ features to make your life easier.

Kylix

[jmoshakis]

As your going for Windows, Linux and x86. I think Borland's Kylix would be a nice fit.

http://www.borland.com/kylix

Use K

[Jayson]

K is a high-performance data processing language. It is a high-level language with very fast performance (it even beats out well written C code). Many people after switching to K have noticed 100x decrease in code side (yes, 2 orders of magnitude) and sometimes even more. It has very high-performance I/O facilities and was explicitly made for muching data. It is cross-platform and runs on NT, Solaris, Linux, FreeBSD, and AIX (you can probably get a build for other systems, too, since the guy who write it is very nice about that).

Some of theK programming maxims are that memmap is better than read/write (the native file I/O is memmap), operating over bulk data is better than scalar data (the language is built around bulk operators), and terse code is good.

There is a warning, though. K is very elite and may be too elite for you (it was for me at first), but it is very eay to learn.

Memories... from the corner of my mind...

[halivar]

I coded in QBasic for 6 years before I learned Pascal, with never an indention. Now that I've moved on to "real, professional" coding in C, C++ and Java, I can't help but look back and notice that the stuff I could do in QBasic was a lot cooler than the stuff I can do in C and Java today.

I'm a worse programmer today, and the worst part is, I can't remember any of it... :(

ACE - The ADAPTIVE Communication Environment

[Anonymous Coward]

ACE is an OO Network Programming Toolkit in C++

In the company I work for our server products are just a recompile away from multiple UN*X flavors, including GNU/Linux, and Windows, using ACE.

Maybe it can help you.

Kylix / Delphi

[Micah]

No one's mentioned Borland's tools, but I think they'd fit the bill. Borland has great compiler technology, and it will compile and run cleanly across Linux and Windows (possibly with a few {$IFDEF}s). It has an I/O library that's as capable as C's (maybe a bit more wordy sometimes). Developing and debugging in Kylix is *much* quicker, in my experience, than using gcc/gdb. It's truly compiled, the compiler is lightning fast, and the integrated debugger is quite a bit more efficient than gdb based solutions.

Re:Kylix / Delphi

[Anonymous Coward]

Please moderate this up.
Delphi uses the same code generator as
C++ Builder so it's as fast as C but with sane
syntax, and it has well defined data sizes unlike
C, where all the data sizes are compiler defined
(so to use C you have to drown in preprocessor
directives) Also it uses Pascal's pre-checking
for file errors (such as eof) instead of insane
C style post-checking. And id I mention the built
in x86 Assembler? For low level programming
Delphi's much better all around.

That's easy...

[trailerparkcassanova]

FORTRAN 95.

Re:Consider Python... Wait! Don't leave!!!

[jdh28]

As far as editors go. I use vi/vim. There may be a mode for collapsing things. I haven't noticed it yet.

Vim 6 has very nice folding functionality.

john

The Great Computer Language Shootout

[bertvl]

Take a look at this guy's page, some interesting benchmarks between a number of computer languages for a number of well known algorithms.

Common Lisp

[Anonymous Coward]

Use a Common Lisp compiler. As fast as C, as easy as, well, Lisp.

Lisp's reputation for inefficiency stems from the 60s/70s. It's actually blindingly fast.

Ada 95

[Ada_Rules]

Given the stated requirements, Ada 95 should be in the trade space. Only downside I can think of is that while there are several vendors for the Windows side, I am only aware of a single vendor for a Linux Ada 95 compiler (www.gnat.com).

You can download a non-supported version (windows and Linux) from
ftp://ftp.cs.nyu.edu/pub/gnat
or wait a few weeks for gcc 3.1 to be released (since the Ada 95 GNAT backend will now be included)

K is a proprietary commercial language

[Anonymous Coward]

Don't bother with K - just a bastardized FORTH. Give me a break. How much do you make selling the commercial languange 'K'?

Warning: my ass is very elite.

[Anonymous Coward]

Too elite for you or K.

PHP

[von Konrad]

It aint just another rave drug. You too can be a coder...

It has a few things going for it.
** Faster than a turtle
** Anyone can code it
** Doesn't show up during random drug testing