• Matthew Wilson (11/11) Nov 06 2003 In light of today's discussion of the regarding the type-safe printf, I ...
• Walter (8/19) Nov 06 2003 got
• Sarat Venugopal (4/6) Nov 07 2003 Well, you are hardly the typical user. :-)
• Charles Sanders (8/19) Nov 06 2003 I don't think I've ever had a problem with printf, not that I can rememb...
• Luna Kid (14/27) Nov 06 2003 I also agree that compiler errors on printf-misuse might
• Luna Kid (4/6) Nov 07 2003 (Just to make it clear: good compromise in terms of
• Sarat Venugopal (12/18) Nov 07 2003 Streams are a powerful abstraction. I hope some serious work goes into
• Ilya Minkov (29/35) Nov 07 2003 I can *never* remember the flags. I have to look them up every time.
• davepermen (35/35) Nov 07 2003 first: there should be no special printf compiler feature required to ma...
• Sarat Venugopal (7/10) Nov 07 2003 Maybe. The good thing about .nl() is that it is an abstraction of

"Matthew Wilson" <dmd synesis.com.au> writes:

In light of today's discussion of the regarding the type-safe printf, I got
to wondering about whether using printf is as dangerous as it's cracked up
to be.

I am pretty confident that the only printf mistakes I've made this year are
in writing code that deals with 64-bit ints, which (for C/C++) use either
%I64d or %lld formats. Since I primarily use Intel 7/7.1 plugged into Visual
Studio 98, the Intel compiler picks up anything else for me.

I don't think I'm uniquely gifted in using printf, so I wonder whether we'd
be best served by just boosting the D compiler's analysis of printf
arguments to at least the competency of the Intel compiler.

Thoughts?

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:bodh54$agt$1 digitaldaemon.com...
 In light of today's discussion of the regarding the type-safe printf, I

got
 to wondering about whether using printf is as dangerous as it's cracked up
 to be.

 I am pretty confident that the only printf mistakes I've made this year

are
 in writing code that deals with 64-bit ints, which (for C/C++) use either
 %I64d or %lld formats. Since I primarily use Intel 7/7.1 plugged into

Visual
 Studio 98, the Intel compiler picks up anything else for me.

 I don't think I'm uniquely gifted in using printf, so I wonder whether

we'd
 be best served by just boosting the D compiler's analysis of printf
 arguments to at least the competency of the Intel compiler.

 Thoughts?

While everyone is correct in that printf is certainly not typesafe, I have
rarely had any problems with it.

Sarat Venugopal <sarat removeme.huelix.com> writes:

Walter wrote:
 While everyone is correct in that printf is certainly not typesafe, I have
 rarely had any problems with it.

Well, you are hardly the typical user. :-)

Cheers,
Sarat

"Charles Sanders" <sanders-consulting comcast.net> writes:

I don't think I've ever had a problem with printf, not that I can remember.

C


"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:bodh54$agt$1 digitaldaemon.com...
 In light of today's discussion of the regarding the type-safe printf, I

got
 to wondering about whether using printf is as dangerous as it's cracked up
 to be.

 I am pretty confident that the only printf mistakes I've made this year

are
 in writing code that deals with 64-bit ints, which (for C/C++) use either
 %I64d or %lld formats. Since I primarily use Intel 7/7.1 plugged into

Visual
 Studio 98, the Intel compiler picks up anything else for me.

 I don't think I'm uniquely gifted in using printf, so I wonder whether

we'd
 be best served by just boosting the D compiler's analysis of printf
 arguments to at least the competency of the Intel compiler.

 Thoughts?

"Luna Kid" <lunakid neuropolis.org> writes:

"Matthew Wilson" <dmd synesis.com.au> wrote in message
news:bodh54$agt$1 digitaldaemon.com...
 In light of today's discussion of the regarding the type-safe printf, I got
 to wondering about whether using printf is as dangerous as it's cracked up
 to be.

 I am pretty confident that the only printf mistakes I've made this year are
 in writing code that deals with 64-bit ints, which (for C/C++) use either
 %I64d or %lld formats. Since I primarily use Intel 7/7.1 plugged into Visual
 Studio 98, the Intel compiler picks up anything else for me.

 I don't think I'm uniquely gifted in using printf, so I wonder whether we'd
 be best served by just boosting the D compiler's analysis of printf
 arguments to at least the competency of the Intel compiler.

 Thoughts?


"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:boebh7$1icq$1 digitaldaemon.com...
 I don't think I've ever had a problem with printf, not that I can remember.

 C


I also agree that compiler errors on printf-misuse might
be enough to save the day, especially if that would be
a required language feature, not just the niceness of a
compiler.

(However, I'd still miss typesafe varargs, I think. OTOH,
I suspect that with typesafe vararg, we'd end up having
similar overhead as with the C++ << >> stuff. (I don't
say this because I have feelings either pro or contra
about the C++ approach; I just think that's probably the
best compromise C++ could afford.)

Later,
Sz.

"Luna Kid" <lunakid neuropolis.org> writes:

 about the C++ approach; I just think that's probably the
 best compromise C++ could afford.)

(Just to make it clear: good compromise in terms of
type-safety / performance + syntax. Regarding formatting,
it's a poor one.)

Mr. X.

Sarat Venugopal <sarat removeme.huelix.com> writes:

[...]

 (However, I'd still miss typesafe varargs, I think. OTOH,
 I suspect that with typesafe vararg, we'd end up having
 similar overhead as with the C++ << >> stuff. (I don't
 say this because I have feelings either pro or contra
 about the C++ approach; I just think that's probably the
 best compromise C++ could afford.)

Streams are a powerful abstraction. I hope some serious work goes into 
current streams.d. The overhead is probably justified in this context. 
Same with type-safety. It is certainly possible to write robust code 
without strong type checking. only harder - especially for the majority 
of the users. It'll be faster not to check array bounds, not use smart 
pointers, not use GCs.....ad infinitum. Ultimately robust code ends up 
checking every one of these manually, often with more overhead.


printf(...) is no real substitute for full featured streams and is 
unaware of objects.

IMHO,
Sarat Venugopal

Ilya Minkov <midiclub tiscali.de> writes:

I can *never* remember the flags. I have to look them up every time. 
It's really not very convenient for users which have little experience 
with C. I myself have switched to C++ right within a couple of months 
after having learned C. And we will hopefully have users switching to D 


Matthew Wilson wrote:
 In light of today's discussion of the regarding the type-safe printf, I got
 to wondering about whether using printf is as dangerous as it's cracked up
 to be.

In C, it's usable. In D, it's dangerous and even more stupid. We have 
had Burton's typesafe printf, which doesn't necessarily requiere or 
could check type specification.

It simply accepted an own kind of a discriminated union, which would 
contain the original type or its string conversion. A more elegant 
solution could be based on inheritance.

While everyone is talking of typesafe varargs, they are actually quite 
easy to make by yourself. Maybe compiler could support automatic 
box-type generation?

 I don't think I'm uniquely gifted in using printf, so I wonder whether we'd
 be best served by just boosting the D compiler's analysis of printf
 arguments to at least the competency of the Intel compiler.

You are just protecting your old habits. ;)

After 10 years of extensive printeffing :> everyone would probably 
become a printf wizard, knowing binary layouts of each struct in their 
program by heart, and thus being able to elegantly output it using 
printf. :>>>>>>> Thus making his code also quite immune against reverse 
engineering. :)

Probably printf is not the most important skill in the world, so i would 
say we should free new users of it. I cannot say that i approve the C++ 
iostrams completely, but they made a step into the right direction, 
allowing to use them easily for usual stuff. For unusual stuff, like 
formatting, these modifiers get really awkward, it could be solved in a 
more lightweight manner. But that's actually the only complaint against 
a ton which i have towards C output and especially the input!!!

-eye

davepermen <davepermen_member pathlink.com> writes:

first: there should be no special printf compiler feature required to make
printf typesave. this is hackish, premature fixing of something that could get
fixed in a general, reusable way (like streams in c++ are).

the other problem is forgotten often: because of the lack of typesavety, there
is as well lack of type determination and due that, type support AT ALL. there
is no way to get printf to take my custom vec3 struct, or my Window class, or
what EVER and print it out correctly. THAT is possible with streams in c++,
too..

we should not forget this. streams in c++ can ALL get extended to support
arbitary types. printf only knows some string variants, some int variants, and
some float variants.

i for myself are completely with the opCall idea, as i've done this in c++
myself, thinking its a very clean way. it is, as well, a very reusable way..
think of this:

class MyObj {
void serialize(ISerializer serializer) {
serializer(this.foo)(this.bar)(this.foobar)(this.whatever);
}
}

MyObj obj = new MyObj;
obj.serialize(new TextFileLoader("obj.txt"));
obj.serialize(new BinaryFileWriter("obj.data"));


this is something the << and >> in c++ doesn't directly support..


(yes, this could be directly done with opCall and not serialize.. but i've just
thought of the general messy way to actually DO serialization to highlight that
here with the proper naming)


then again, to make it really extendable, operators should not be member
functions.. that way, we could just write..

ISerializer opCall(ISerializer me,vec3 v) {
return me(v.x)(v.y)(v.z);
}

and done.. or so..



oh, and about the very stupid discussion about ("\n") or (endl) or .nl() or what
ever bullshit.. how about... (\n) ? this works! \n is a special char you can
use. short, clean, simple.. we just need opCall(char chr)

Sarat Venugopal <sarat removeme.huelix.com> writes:

davepermen wrote:
[...]

 oh, and about the very stupid discussion about ("\n") or (endl) or .nl() or
what
 ever bullshit.. how about... (\n) ? this works! \n is a special char you can
 use. short, clean, simple.. we just need opCall(char chr)

Maybe. The good thing about .nl() is that it is an abstraction of 
newline (may be your (\n) can be too...). On Windows "\r\n", "\n" on 
POSIX, and so on (Is it "\r" on Mac?).

Cheers,
Sarat Venugopal