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?

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

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?
>
>
>

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

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 from Delphi, Java and C#.

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

> 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.

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)

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

[...]

> (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

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