what ever you talk about. properly implemented concatenated calls can beat every printf in terms of performance. possibly not in the design of the iostreams of the c++ standard library, dunno (don't see any reason why), but definitely by default.

the reason is simple: the multicall determines at COMPILE TIME how the string has to look, how to convert what variable with wich function to what string output (int2string, MyStoopidObj2string, char2string, float2string, etc), and the only runtime workload are the actual needed conversions. they can even inline rather well for some of them, etc.

printf ALWAYS parses runtime, determines and switches runtime what type to print how, where. this can't be faster than compile time determining the same. it simply can not. no way.

the mutliple function calls are actually done in printf as well (thought it is often a switch statement, doesn't make it really bether..).

you don't gain anything with printf. show me what you gain.

In article <btbhri$23j9$1@digitaldaemon.com>, Matthew says...
>
>> cout is buffered, printf not.
>
>That's implementation-defined, and not a stipulated characteristic. In fact, printf is often implemented in terms of, or shares implementation with, fprintf (stderr).
>
>> but technically, the design of the streams in c++ need less runtime work
>than
>> printf.
>
>I don't find this credible. Have you implemented either/both, or equivalent functions?
>
>> they are as well typesave and extendable.
>
>No-one's contesting that. As with just about anything, the contest is between robustness and efficiency.
>
>> its true that cout itself is not that fast. but it has other reasons,
>_NOT_ the
>> "multiple function calls are slow" ones.. reasons that wouldn't mather in
>D
>
>Disagree. There are several reasons for the high performance costs of the iostreams, only some of which pertain to the multiple calls.
>
>
>> In article <btb7aj$1ihl$1@digitaldaemon.com>, Matthew says...
>> >
>> >
>> >"davepermen" <davepermen_member@pathlink.com> wrote in message news:btb741$1hsd$1@digitaldaemon.com...
>> >> In article <btaqtk$j8i$1@digitaldaemon.com>, kinghajj says...
>> >> >
>> >> >printf() and scanf() are just fine IF u take the time to learn them!
>> >(though, I
>> >> >do like std::cin for input...). printf() is better than std::cout
>(it's
>> >faster).
>> >> >
>> >> >
>> >> no, it's not
>> >
>> >Not faster? I'd be very surprised if this was not true for the majority
>of
>> >test cases. Each output to cout has to go through significant locale management.
>> >
>> >
>> >
>>
>>
>
>

Asked and answered: "properly implemented concatenated calls"

You're absolutely right. It's just the case that iostreams is not, and I believe cannot, beat printf in performance. I've implemented type safe and very-high performance streaming libs in C++ (although the syntax was not particularly welcoming).

I am hopeful that D will do what you assert is possible, and I agree should be. It's just not easy, especially when one gets to working with objects, whose strream-representation formats are often subject to runtime decisions. The only way to do it is to prove it. :)

"davepermen" <davepermen_member@pathlink.com> wrote in message news:btbj4j$25cl$1@digitaldaemon.com...
> what ever you talk about. properly implemented concatenated calls can beat
every
> printf in terms of performance. possibly not in the design of the
iostreams of
> the c++ standard library, dunno (don't see any reason why), but definitely
by
> default.
>
> the reason is simple: the multicall determines at COMPILE TIME how the
string
> has to look, how to convert what variable with wich function to what
string
> output (int2string, MyStoopidObj2string, char2string, float2string, etc),
and
> the only runtime workload are the actual needed conversions. they can even inline rather well for some of them, etc.
>
> printf ALWAYS parses runtime, determines and switches runtime what type to
print
> how, where. this can't be faster than compile time determining the same.
it
> simply can not. no way.
>
> the mutliple function calls are actually done in printf as well (thought
it is
> often a switch statement, doesn't make it really bether..).
>
> you don't gain anything with printf. show me what you gain.
>
> In article <btbhri$23j9$1@digitaldaemon.com>, Matthew says...
> >
> >> cout is buffered, printf not.
> >
> >That's implementation-defined, and not a stipulated characteristic. In
fact,
> >printf is often implemented in terms of, or shares implementation with,
> >fprintf (stderr).
> >
> >> but technically, the design of the streams in c++ need less runtime
work
> >than
> >> printf.
> >
> >I don't find this credible. Have you implemented either/both, or
equivalent
> >functions?
> >
> >> they are as well typesave and extendable.
> >
> >No-one's contesting that. As with just about anything, the contest is between robustness and efficiency.
> >
> >> its true that cout itself is not that fast. but it has other reasons,
> >_NOT_ the
> >> "multiple function calls are slow" ones.. reasons that wouldn't mather
in
> >D
> >
> >Disagree. There are several reasons for the high performance costs of the iostreams, only some of which pertain to the multiple calls.
> >
> >
> >> In article <btb7aj$1ihl$1@digitaldaemon.com>, Matthew says...
> >> >
> >> >
> >> >"davepermen" <davepermen_member@pathlink.com> wrote in message news:btb741$1hsd$1@digitaldaemon.com...
> >> >> In article <btaqtk$j8i$1@digitaldaemon.com>, kinghajj says...
> >> >> >
> >> >> >printf() and scanf() are just fine IF u take the time to learn
them!
> >> >(though, I
> >> >> >do like std::cin for input...). printf() is better than std::cout
> >(it's
> >> >faster).
> >> >> >
> >> >> >
> >> >> no, it's not
> >> >
> >> >Not faster? I'd be very surprised if this was not true for the
majority
> >of
> >> >test cases. Each output to cout has to go through significant locale management.
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>

if the way to determine is runtime, then it has to be. printf doesn't help as well.

c++ streams _should_ be capable in being high performing. don't know why they shouldn't (but i don't know much about them anyways..)

all we need is the ability to write operators as non-member-functions.

In article <btbkd6$27bd$1@digitaldaemon.com>, Matthew says...
>
>Asked and answered: "properly implemented concatenated calls"
>
>You're absolutely right. It's just the case that iostreams is not, and I believe cannot, beat printf in performance. I've implemented type safe and very-high performance streaming libs in C++ (although the syntax was not particularly welcoming).
>
>I am hopeful that D will do what you assert is possible, and I agree should be. It's just not easy, especially when one gets to working with objects, whose strream-representation formats are often subject to runtime decisions. The only way to do it is to prove it. :)
>
>"davepermen" <davepermen_member@pathlink.com> wrote in message news:btbj4j$25cl$1@digitaldaemon.com...
>> what ever you talk about. properly implemented concatenated calls can beat
>every
>> printf in terms of performance. possibly not in the design of the
>iostreams of
>> the c++ standard library, dunno (don't see any reason why), but definitely
>by
>> default.
>>
>> the reason is simple: the multicall determines at COMPILE TIME how the
>string
>> has to look, how to convert what variable with wich function to what
>string
>> output (int2string, MyStoopidObj2string, char2string, float2string, etc),
>and
>> the only runtime workload are the actual needed conversions. they can even inline rather well for some of them, etc.
>>
>> printf ALWAYS parses runtime, determines and switches runtime what type to
>print
>> how, where. this can't be faster than compile time determining the same.
>it
>> simply can not. no way.
>>
>> the mutliple function calls are actually done in printf as well (thought
>it is
>> often a switch statement, doesn't make it really bether..).
>>
>> you don't gain anything with printf. show me what you gain.
>>
>> In article <btbhri$23j9$1@digitaldaemon.com>, Matthew says...
>> >
>> >> cout is buffered, printf not.
>> >
>> >That's implementation-defined, and not a stipulated characteristic. In
>fact,
>> >printf is often implemented in terms of, or shares implementation with,
>> >fprintf (stderr).
>> >
>> >> but technically, the design of the streams in c++ need less runtime
>work
>> >than
>> >> printf.
>> >
>> >I don't find this credible. Have you implemented either/both, or
>equivalent
>> >functions?
>> >
>> >> they are as well typesave and extendable.
>> >
>> >No-one's contesting that. As with just about anything, the contest is between robustness and efficiency.
>> >
>> >> its true that cout itself is not that fast. but it has other reasons,
>> >_NOT_ the
>> >> "multiple function calls are slow" ones.. reasons that wouldn't mather
>in
>> >D
>> >
>> >Disagree. There are several reasons for the high performance costs of the iostreams, only some of which pertain to the multiple calls.
>> >
>> >
>> >> In article <btb7aj$1ihl$1@digitaldaemon.com>, Matthew says...
>> >> >
>> >> >
>> >> >"davepermen" <davepermen_member@pathlink.com> wrote in message news:btb741$1hsd$1@digitaldaemon.com...
>> >> >> In article <btaqtk$j8i$1@digitaldaemon.com>, kinghajj says...
>> >> >> >
>> >> >> >printf() and scanf() are just fine IF u take the time to learn
>them!
>> >> >(though, I
>> >> >> >do like std::cin for input...). printf() is better than std::cout
>> >(it's
>> >> >faster).
>> >> >> >
>> >> >> >
>> >> >> no, it's not
>> >> >
>> >> >Not faster? I'd be very surprised if this was not true for the
>majority
>> >of
>> >> >test cases. Each output to cout has to go through significant locale management.
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

> if the way to determine is runtime, then it has to be. printf doesn't help
as
> well.
>
> c++ streams _should_ be capable in being high performing. don't know why
they
> shouldn't (but i don't know much about them anyways..)
>
> all we need is the ability to write operators as non-member-functions.

That's something we need that is supported by a large number of issues, not just this one. It's an absolute must, and I can't seee Walter escaping us on this one. :)

>
> In article <btbkd6$27bd$1@digitaldaemon.com>, Matthew says...
> >
> >Asked and answered: "properly implemented concatenated calls"
> >
> >You're absolutely right. It's just the case that iostreams is not, and I believe cannot, beat printf in performance. I've implemented type safe
and
> >very-high performance streaming libs in C++ (although the syntax was not
> >particularly welcoming).
> >
> >I am hopeful that D will do what you assert is possible, and I agree
should
> >be. It's just not easy, especially when one gets to working with objects, whose strream-representation formats are often subject to runtime
decisions.
> >The only way to do it is to prove it. :)
> >
> >"davepermen" <davepermen_member@pathlink.com> wrote in message news:btbj4j$25cl$1@digitaldaemon.com...
> >> what ever you talk about. properly implemented concatenated calls can
beat
> >every
> >> printf in terms of performance. possibly not in the design of the
> >iostreams of
> >> the c++ standard library, dunno (don't see any reason why), but
definitely
> >by
> >> default.
> >>
> >> the reason is simple: the multicall determines at COMPILE TIME how the
> >string
> >> has to look, how to convert what variable with wich function to what
> >string
> >> output (int2string, MyStoopidObj2string, char2string, float2string,
etc),
> >and
> >> the only runtime workload are the actual needed conversions. they can
even
> >> inline rather well for some of them, etc.
> >>
> >> printf ALWAYS parses runtime, determines and switches runtime what type
to
> >print
> >> how, where. this can't be faster than compile time determining the
same.
> >it
> >> simply can not. no way.
> >>
> >> the mutliple function calls are actually done in printf as well
(thought
> >it is
> >> often a switch statement, doesn't make it really bether..).
> >>
> >> you don't gain anything with printf. show me what you gain.
> >>
> >> In article <btbhri$23j9$1@digitaldaemon.com>, Matthew says...
> >> >
> >> >> cout is buffered, printf not.
> >> >
> >> >That's implementation-defined, and not a stipulated characteristic. In
> >fact,
> >> >printf is often implemented in terms of, or shares implementation
with,
> >> >fprintf (stderr).
> >> >
> >> >> but technically, the design of the streams in c++ need less runtime
> >work
> >> >than
> >> >> printf.
> >> >
> >> >I don't find this credible. Have you implemented either/both, or
> >equivalent
> >> >functions?
> >> >
> >> >> they are as well typesave and extendable.
> >> >
> >> >No-one's contesting that. As with just about anything, the contest is between robustness and efficiency.
> >> >
> >> >> its true that cout itself is not that fast. but it has other
reasons,
> >> >_NOT_ the
> >> >> "multiple function calls are slow" ones.. reasons that wouldn't
mather
> >in
> >> >D
> >> >
> >> >Disagree. There are several reasons for the high performance costs of
the
> >> >iostreams, only some of which pertain to the multiple calls.
> >> >
> >> >
> >> >> In article <btb7aj$1ihl$1@digitaldaemon.com>, Matthew says...
> >> >> >
> >> >> >
> >> >> >"davepermen" <davepermen_member@pathlink.com> wrote in message news:btb741$1hsd$1@digitaldaemon.com...
> >> >> >> In article <btaqtk$j8i$1@digitaldaemon.com>, kinghajj says...
> >> >> >> >
> >> >> >> >printf() and scanf() are just fine IF u take the time to learn
> >them!
> >> >> >(though, I
> >> >> >> >do like std::cin for input...). printf() is better than
std::cout
> >> >(it's
> >> >> >faster).
> >> >> >> >
> >> >> >> >
> >> >> >> no, it's not
> >> >> >
> >> >> >Not faster? I'd be very surprised if this was not true for the
> >majority
> >> >of
> >> >> >test cases. Each output to cout has to go through significant
locale
> >> >> >management.
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Nikita Proskourine wrote:

>D currently uses printf for printing strings. This has a number of
>disadvantages:
>1. Number of arguments is not validated.
>2. Types of arguments are not validated.
>3. Non-primitive types can't be printed.
>
>The solution could be something in the style of Java, with overridable
>toString() in every object or in the style of C++ with << operators and streams.
>Or it could be some intrinsic feature of D.
>
>scanf has the same type of problems.
>
>Something should be done about it. What do you think?
>
>Nikita.
>
>
>  
>
What about something with templates. ie

void print(int val)
{
//print val
}
void print(char[] val)
{
//print val
}

template printT(T)
{
  void printT(T list)
  {
     //If list of arguments
     if (typeof(list) == typeof(...)) //Optimised away
     {
        foreach (val; list)
       {
           print(val);
        }
     }
     else
     {
         printf(list); //Single value
      }
  }
}

alias printT!(...).printT print; //... = a list of arguments.

print("number = ", 50); //prints "number = 50"

Users could add their own print's. Particular cases could be speciallised.

The ... could be something else like typelist, the idea here is more important then the syntax.

Actually the ... could be used in other syntax as well.

void print(... list)
{

}

It would differentiate from the c version because it's before, not after the variable. Anyway another term could be used.

or parhaps a more wordy version:

template print(T : ...)
{
  void print(T list)
  {
      foreach (val; list)
     {
           print(val);
      }
  }
}

print!(char*, int)("number = ", 50);

Anderson

J Anderson wrote:

> Nikita Proskourine wrote:
>
>> D currently uses printf for printing strings. This has a number of
>> disadvantages:
>> 1. Number of arguments is not validated.
>> 2. Types of arguments are not validated.
>> 3. Non-primitive types can't be printed.
>>
>> The solution could be something in the style of Java, with overridable
>> toString() in every object or in the style of C++ with << operators and streams.
>> Or it could be some intrinsic feature of D.
>>
>> scanf has the same type of problems.
>>
>> Something should be done about it. What do you think?
>>
>> Nikita.
>>
>>
>>  
>>
> What about something with templates. ie
>
> void print(int val)
> {
> //print val
> }
> void print(char[] val)
> {
> //print val
> }
>
> template printT(T)
> {
>   void printT(T list)
>   {
>      //If list of arguments
>      if (typeof(list) == typeof(...)) //Optimised away
>      {
>         foreach (val; list)
>        {
>            print(val);
>         }
>      }
>      else
>      {
>          printf(list); //Single value
>       }
>   }
> }
>
> alias printT!(...).printT print; //... = a list of arguments.
>
> print("number = ", 50); //prints "number = 50"
>
> Users could add their own print's. Particular cases could be speciallised.
>
> The ... could be something else like typelist, the idea here is more important then the syntax.
>
> Actually the ... could be used in other syntax as well.
>
> void print(... list)
> {
>
> }
>
> It would differentiate from the c version because it's before, not after the variable. Anyway another term could be used.
>
> or parhaps a more wordy version:
>
> template print(T : ...)
> {
>   void print(T list)
>   {
>       foreach (val; list)
>      {
>            print(val);
>       }
>   }
> }
>
> print!(char*, int)("number = ", 50);
>
> Anderson
>
Parhaps instead of:

void print(int val)
{
//print val
}
void print(char[] val)
{
//print val
}

the toString method could be used, but I requested that before for primitive types ;(

In this long thread I have not noticed anyone mentioning that the format string in printf (and scanf) can be defined at runtime. I personally think this is the single most elegant detail in printf.

Still, I've never used it myself, and haven't actually seen anyone else use it either. It can also be said that code that uses a varying format stirng in printf is bound to get less readable and harder to debug than const format string type printf. (I.e. the usual way of using it.)

This ability IMHO is the main reason why printf does runtime parsing. If we were to decide on static format strings, then the compiler could do the parsing for us. This would result in the disappearance of several restrictions regarding a new implementation of a printf equivalent.

Also, since printf is a C-function, it remains callable from D, whatever happens. Knowing this, it might be a good idea to design the "genuine D printing function" for the most prevalent cases and usages.

This would ultimately lead to a Pascal writeln like functionality. But what's the harm with that?

To gains some insight into why we already haven't implemented something writeline alike, could someone explain if there are any technical restrictions in D that make it hard to implement writeline as in Pascal? (Not that I'm advocating that we should, but a good answer would go a long way to letting some of us understand the non-obvious issues involved.)

Georg Wrede wrote:
> In this long thread I have not noticed anyone mentioning that
> the format string in printf (and scanf) can be defined at runtime. I personally think this is the single most elegant
> detail in printf. 

Well, it can, but that's definately not what you would do in C due to memory management issues. In C++ or D, this is quite an option.

> Still, I've never used it myself, and haven't actually seen
> anyone else use it either. It can also be said that code that uses a varying format stirng in printf is bound to get
> less readable and harder to debug than const format string
> type printf. (I.e. the usual way of using it.)

I know at least one use of it: software internationalisation, which btw leads to very silly sentenses in some languages, in which word order is not the same as in english! My native language is Russian, and i can remember some funny moments reading some messages in software translated this way! I think IBM OS/2 was the first major piece of software which broke up with it, and actually had a high-quality translation with correct word order.

I think we need a better solution to that than printf, namely format with named placeholders!

As to generic use, it doesn't make much sense to construct own printf format line, since we have language features which can abstract the working IO stream away - since that was probably the most important use back then. Also recall that you cannot construct a printf argument list this way.

> This ability IMHO is the main reason why printf does runtime
> parsing. If we were to decide on static format strings, then
> the compiler could do the parsing for us. This would result
> in the disappearance of several restrictions regarding a new
> implementation of a printf equivalent.

I bet it is not. It was a hack which allowed the compiler to be slim, and printf to accept variable number of arguments. Note that varags were not available as a language feature at the moment.

> Also, since printf is a C-function, it remains callable from
> D, whatever happens. Knowing this, it might be a good idea to
> design the "genuine D printing function" for the most prevalent
> cases and usages. 
> 
> This would ultimately lead to a Pascal writeln like functionality.
> But what's the harm with that? 

The problem with Pascal writeln "function" was that it could not be defined in Pascal. It had to be a built in. In D it still has, because in-line array declarations don't work, and because there is no way to determine the length of variable arguments list, and because there is no good way one could specify automatic export conversion for a custom type. Making writeln built in, would mean that a user can't write his own writeln-like function - which the C/C++ community definately cannot accept. I believe one viable way now is opCall overload.

Another thing would work, but Walter would not like it: overload opMod, opDiv or opSub, or maybe even the same opShl and opShr. Or rather opCat, which i would prefer. These operators are not commutative, and can thus be overloaded on the UDT through the _r equivalent!!! opMod can be overloaded to do named format replacement.

-eye