[Mdate-devel] Re: mdate 1.4.3 released
Brought to you by:
ewe2
|
From: <mda...@li...> - 2003-09-23 00:50:29
|
On Mon, Sep 22, 2003 at 08:54:25PM +0200, Shard wrote: > ok, i've tried printf and it works now. std:: streams are in pretty bad > condition on BeOS :( Yes, I wasn't even interested in c++ development until the g++ 3.x series, it was that bad. <iostream> was a disgrace. It's really sad in a way, that c++ has had the same problems that c had; now we're all moving away from it for general development. > I'm sending changed main.cc. BTW i've removed "\n" from main() here - so > You can see what i ment talking about not ending with nextline. if You > want more \n at the and it should be in format definition IMHO (i mean the > ones in en.h,es.h,pl.h,de.h, and other future translations). that way, > using mdate in scripts, doesn't make developer/script writer to play with > strings to cut out last nextline char. Well I tried it out but it's too inconsistent - doing this would split the output into "some output has newlines, some doesn't". All the data in the language files are there for translation, and your suggestion would make the rest of the program dependent on them for different reasons, which are hard to spot if you don't understand the code, or (like me often) haven't seen it for a while. I take my programming cues from Steve Ouilline, whose books taught me more about general coding than necessarily c/c++. Put yourself in the position of someone else trying to port mdate to another system - what assumptions can they make about the program's behaviour? If he/she/it can assume, for instance, that all output is newline-terminated, there won't be any surprises (like a user-supplied format running into the command-prompt because the format functions don't insert newlines), even if the output is an error-message. The buffers themselves aren't necessarily newline-terminated, but if you're dealing with them directly, you're doing something quite different to capturing output. Having said that, I won't enforce my output policy on BeOS :) If it looks worse to have an extra newline on a BeOS console, then it looks worse on a Linux rxvt without it :) Someday I'll get round to reformatting the options so DOS freaks don't wonder where the /? went :)) If a scripting language has problems with newlines in captured stdout, I have to say it doesn't impress me. Even Tcl, which is pretty basic compared to perl or python, had no trouble with it 3/4 years ago (and it's improved hugely since then): basically anything that can deal with a system() or exec() call properly is going to return a usable string. Rant over :) I'm currently playing with autoconf and friends. What support does BeOS have for autoconf/automake etc? Sean -- "NOONE expects the Death Eaters! Amongst our weaponry are such diverse elements as...Fear! Surprise! Ruthless efficiency! An almost fanatical devotion to Lord Voldermort! Nice black uniforms - oh damn!" |