DM>Sure I do.  It does slightly different things on 
DM>each compiler I've used
DM>it on.  For example, when using cprintf in Turbo, to replicate the same
DM>thing on Watcom, I couldn't use cprintf but the combination of sprintf
DM>and _outtext.
 HS> That's a great explanation, Darin. Petty it doesn't 
 HS> really explain anything. Now, are you SURE you know 
 HS> what cprintf() does?
Yup - mostly nothing.  At least, not consistantly.
DM>particular attention to the standard in the hopes of getting everyone's
DM>compilers (even _Visual Age_, _EMX_, and _PCC_, or even non-Intel
DM>machines) giving the same results.  Use of extentions is therefore
DM>limited to times where it is absolutely necessary.
 HS> Note: Flame bait.
At least now you're warning us.
 HS> The current topic is cprintf, which you managed to 
 HS> change originally from ANSI-C standard, which you 
 HS> changed from the EVENT HANDLER program i previously 
I've never commented on the event handler, only on your insistance to use 
non-standard functions, and your entire disdain from those of us using 
compilers that are closer to the standard than yours.
 HS> posted. Back to our current topic, (which you seem to 
 HS> want to drift away from, again) cprintf() is only 
 HS> useless for DOS. Get your facts straight before you 
cprintf() is useless for cross platform development, or even cross compiler 
development (since it neither exists on every compiler in one platform nor 
does exactly the same thing on each platform).  Useless for DOS?  When you're 
flaming, you should at least recheck what you type for reversal errors like 
that.
DM>Well, if you're going to be pedantic, I *know* I've seen the list, I
DM>just don't recall which compilers they were.
 HS> Oh, okay. You must be right then.
I always am.
 HS> .. Watcom, Borland, Djgpp, etc. If a compiler doesn't
 HS> have it, then it most likely contains an equivalent.
DM>They don't do the same thing on all compilers.
 HS> (sigh)
 HS> cprintf() sends a formatted output STRAIGHT to the screen.
Well, not always in the same way, it seems.
 HS> printf() sends a formatted output string to stdin.
What that means is not defined by the standard.
 HS> Can you understand that?
 HS> If you can, then you would understand why the textcolor-
 HS> family functions FAIL with printf() (ANSI-C disallows 
 HS> it to do anything else other than send to stdin). 
What does "stdin" mean?  It means two basic things:
- It can be redirected externally to the program
- If not redirected, output goes to "the screen".
There is no requirement in the second scenario that stdout be an indirect 
method to the screen - it still could be blasted direct to the screen.
 HS> That's why all these companies put in cprintf which 
 HS> formats the string with ansi-colours. Like I said, if a 
 HS> compiler doesn't have cprintf() then it contains an 
 HS> equivalent which is most likely just printf().
What would this equivalent be called?  It won't be cprintf - making your code 
not portable again.  The entire point is that you posted code using "cprintf" 
in it that won't work on compilers that don't support cprintf.  People - 
especially those who aren't as sure about their own skills - will have to 
change your cprintf's to whatever their compiler uses...
 HS> Then as already mentioned, it is the equivalent of 
 HS> cprintf(). Although it shouldn't be, since the standard 
 HS> doesn't allow printf() to do that.
It's an "equivalent" ... but, your code used cprintf.  And the standard does 
not prevent printf from doing this.
DM>Which is NOT cprintf!
 HS> If it doesn't, then printf() does it automatically. 
 HS> Which is against the ansi-stanard, but still useable - 
 HS> which goes back to my previous point that you DONT NEED 
 HS> TO FOLLOW THE STANARD ALL THE TIME.
But if I use printf, YOU will be able to compile it.  So will people on other 
platforms.  I'm not against using non-standard functions, so long as you 
understand the consequences (which can be as restrictive as stuck on a single 
compiler - and only on that single version - on a single platform).  You 
don't seem to understand the consequences.
 HS> Same concept applies to C. You did realize that, didn't you?
 HS> No. The same general concept applies - Even though it's
 HS> erroneous to the standard, it works.
You asked a leading question.  You then said it was wrong.  You're 
disagreeing with yourself.
DM>And failing to cast
DM>void* to the appropriate type hasn't worked on any 
DM>of my compilers for a
DM>while...
 HS> Wrong, yet again.
 HS> char *a = malloc(1243);
 - I'm trying to follow your jumps in topic from C to C++ and now back, 
but I just can't do it.
 HS> Please point out where i've been "disagreeing with myself".
Above - since you can't seem to follow your own jumps in languages either.
 HS> Note: Personal insult.
Yup.
---
---------------