[Mdate-devel] Re: mdate 1.4.3 released

[<mda...@li...>]

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!"