How can i:

{
    cout << "Hello!" << 3.14;
    float f1,f2;
    int i;
    cin >> f1 >> i >> f2;
}

in D?

The cout part can be done (although a lot uglier)
with printf. Some time ago i thought writef was the right
way to go. I thought if i wanted to print a string all i had to do
was writef(str), but this isn't actually the solution because if the
string i am trying to print is "%" i will get access violation.
I have to write writef("%s",str), so it is just a little smarter printf.

What about the cin part? What i am doing now is reading a line,
spliting it, checking if there are anough parts, converting each one
into the right type. Need i say that when i use cin i can enter those
two floats and an int from the example seperated by spaces or they
can be separated by enters, so my d version is really simplified
(meaning less flexibility) and it is a lot harder and longer code
to write.

Not to mention the neverending danger of using a wrong format specifier and getting things printed either the wrong way or not printed at all.

Does enyone else think that d.std needs compile time safe stdio with some heavy abuse of << and >> operators?

:)

In article <chh8fc$16at$1@digitaldaemon.com>, Ivan Senji says...
>
>How can i:
>
>{
>    cout << "Hello!" << 3.14;
>    float f1,f2;
>    int i;
>    cin >> f1 >> i >> f2;
>}
>
>in D?

Andy made streams like that I think. I'm not sure phobos overloads those operators for stream yet.

http://andy.tadan.us/d/apropos-27-june-2004.zip

>The cout part can be done (although a lot uglier)
>with printf. Some time ago i thought writef was the right
>way to go. I thought if i wanted to print a string all i had to do
>was writef(str), but this isn't actually the solution because if the
>string i am trying to print is "%" i will get access violation.
>I have to write writef("%s",str), so it is just a little smarter printf.

You can use the .write in streams like stdout and stderr. I suppose stdin would provide read and readline, though I'm sort of a newbie.

>What about the cin part? What i am doing now is reading a line,
>spliting it, checking if there are anough parts, converting each one
>into the right type. Need i say that when i use cin i can enter those
>two floats and an int from the example seperated by spaces or they
>can be separated by enters, so my d version is really simplified
>(meaning less flexibility) and it is a lot harder and longer code
>to write.
>
>Not to mention the neverending danger of using a wrong format specifier and getting things printed either the wrong way or not printed at all.
>
>Does enyone else think that d.std needs compile time safe stdio with some heavy abuse of << and >> operators?
>
>:)
>

Stream's write function overloads different types so you don't have to bother about it. However, you'll have to parse characters/integers to strings if you want them to appear as text, still.

In article <chh8fc$16at$1@digitaldaemon.com>, Ivan Senji says...

>Does enyone else think that d.std needs compile time safe stdio with some heavy abuse of << and >> operators?
>
>:)

That's "use", not "abuse", surely?  "abuse" would be, like, overloading binary "+" to calculate the geometric mean of two numbers, or unary "-" to calculate a natural logarithm. (We could have a competition for sillier examples :) ).

Using << and >> for insertion and extraction seems quite normal to me. (Certainly no worse than re-using the bitwise-not operator for string concatenation).

I do agree with you on the general principle though. printf() and its ilk provide /run-time/ type-checking. If we had /compile-time/ type-checking, as C++ does, that would obviously be better.

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:chhioq$1a7u$1@digitaldaemon.com...
> In article <chh8fc$16at$1@digitaldaemon.com>, Ivan Senji says...
>
> >Does enyone else think that d.std needs compile time safe stdio with some heavy abuse of << and >> operators?
> >
> >:)
>
> That's "use", not "abuse", surely?  "abuse" would be, like, overloading
binary
> "+" to calculate the geometric mean of two numbers, or unary "-" to
calculate a
> natural logarithm. (We could have a competition for sillier examples :) ).

Surely! But i got used to people calling this abuse because << and >> are
shift
operators. Silly examples you say? I have a class that implements
static ++ static -- and static opCall.

> Using << and >> for insertion and extraction seems quite normal to me. (Certainly no worse than re-using the bitwise-not operator for string concatenation).
>
> I do agree with you on the general principle though. printf() and its ilk provide /run-time/ type-checking. If we had /compile-time/ type-checking,
as C++
> does, that would obviously be better.

That would be great! (not better) :)

>
> Jill
>
>

Arcane Jill wrote:

<snip>
> That's "use", not "abuse", surely?  "abuse" would be, like, overloading binary
> "+" to calculate the geometric mean of two numbers, or unary "-" to calculate a
> natural logarithm. (We could have a competition for sillier examples :) ).

Good idea!  Let's get the IODCC set up.

> Using << and >> for insertion and extraction seems quite normal to me.
> (Certainly no worse than re-using the bitwise-not operator for string
> concatenation).
<snip>

And historically, using the multiplication operator for pointer dereferencing, and the bitwise-and operator for address taking.

Except that unary * and binary * are really different operators.  OTOH, binary << and binary << are the same operator.

Does anyone else actually agree with the idea of inventing new operators for this purpose?

http://www.digitalmars.com/drn-bin/wwwnews?D/25096

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Joey Peters" <Joey_member@pathlink.com> wrote in message news:chh9c6$16rt$1@digitaldaemon.com...
> In article <chh8fc$16at$1@digitaldaemon.com>, Ivan Senji says...
> >
> >How can i:
> >
> >{
> >    cout << "Hello!" << 3.14;
> >    float f1,f2;
> >    int i;
> >    cin >> f1 >> i >> f2;
> >}
> >
> >in D?
>
> Andy made streams like that I think. I'm not sure phobos overloads those operators for stream yet.
>
> http://andy.tadan.us/d/apropos-27-june-2004.zip
>
> >The cout part can be done (although a lot uglier)
> >with printf. Some time ago i thought writef was the right
> >way to go. I thought if i wanted to print a string all i had to do
> >was writef(str), but this isn't actually the solution because if the
> >string i am trying to print is "%" i will get access violation.
> >I have to write writef("%s",str), so it is just a little smarter printf.
>
> You can use the .write in streams like stdout and stderr. I suppose stdin
would
> provide read and readline, though I'm sort of a newbie.
>
> >What about the cin part? What i am doing now is reading a line,
> >spliting it, checking if there are anough parts, converting each one
> >into the right type. Need i say that when i use cin i can enter those
> >two floats and an int from the example seperated by spaces or they
> >can be separated by enters, so my d version is really simplified
> >(meaning less flexibility) and it is a lot harder and longer code
> >to write.
> >
> >Not to mention the neverending danger of using a wrong format specifier and getting things printed either the wrong way or not printed at all.
> >
> >Does enyone else think that d.std needs compile time safe stdio with some heavy abuse of << and >> operators?
> >
> >:)
> >
>
> Stream's write function overloads different types so you don't have to
bother
> about it. However, you'll have to parse characters/integers to strings if
you
> want them to appear as text, still.

Here is the problem:
try:
 std.stream.stdout.write(65);
 std.stream.stdout.write(3.141);

You will get "A   T?Ñ¢?       @"
Not what someone coming from iostream would expect! :)

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:chhkfu$1auf$1@digitaldaemon.com...
> <snip>
> Except that unary * and binary * are really different operators.  OTOH,
> binary << and binary << are the same operator.
>
> Does anyone else actually agree with the idea of inventing new operators for this purpose?
>
> http://www.digitalmars.com/drn-bin/wwwnews?D/25096

It would be nice, but it is hard to invent a new operator. << and >> has a defined meaning for millions of C++ programmers, and will atract them.

we can't tell them:

float f; int i;

instead of:
    cin >> f >> i;

in D you write:

    char[] temp;
    temp = std.stream.stdin.readLine();
    char[][] parts;
    parts = split(temp);
    if(parts.length!=2)
    {
        //maybe throw some Exception
    }
    else
    {
        f = stringToFloatConv(parts[0]);
        i = stringToIntConv(parts[1]);
    }



>
> Stewart.
>
> --
> My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Ivan Senji wrote:

<snip>
> It would be nice, but it is hard to invent a new operator. << and >> has a
> defined meaning for millions of C++ programmers, and will atract them.

C++ programmers already have to adapt to the D way of thinking.  So why shouldn't they adapt a character or two to the D way of doing I/O?

> we can't tell them:
> 
> float f; int i;
> 
> instead of:
>     cin >> f >> i;
> 
> in D you write:
<snip>

But we could tell them that in D I write:

    cin ~> f ~> i;

if only that could be made true....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <chhnle$1c1n$1@digitaldaemon.com>, Stewart Gordon says...

>But we could tell them that in D I write:
>
>     cin ~> f ~> i;
>
>if only that could be made true....

Except that:

#    cout <~ x;

could ambiguously also mean:

#    cout < (~x);

and, since opCmp() is defined for all objects (!!!), including our hypothetical
cout, this would actually compile and run (incorrectly) if x happened to be an
instance of a class for which opCom() was defined.

Arcane Jill

Arcane Jill schrieb:

> Except that:
> 
> #    cout <~ x;
> 
> could ambiguously also mean:
> 
> #    cout < (~x);
> 
> and, since opCmp() is defined for all objects (!!!), including our hypothetical
> cout, this would actually compile and run (incorrectly) if x happened to be an
> instance of a class for which opCom() was defined.

The "greatest munch" lexing (as stated in D specification) will sort that out. <~ written together would always be one token. There are similar situations in C and all derived languages.

-eye