No offence, but may be this is what is referred to as operator overloading abuse ?

Sai

In article <chmnrd$l9l$2@digitaldaemon.com>, Ivan Senji says...
>
>Well i use it just because i am lasy :)
>
>I have a Tabs class that prints tabs and i didn't feel like creating instances of it. So i do
>
>Tabs(file); //prints 0 tabs
>Tabs++;
>Tabs(file); /*printf  1 tabs*/
>    //printf what needs to be indented
>Tabs--;
>
>
>To support my lazyness :)
>

"Sai" <Sai_member@pathlink.com> wrote in message news:chmvhl$ob6$1@digitaldaemon.com...
> No offence, but may be this is what is referred to as operator overloading
abuse

No offernce taken, probably it is, and i'm not proud of it :) But using << and >> as stream operators isn't.

> ?
>
> Sai
>
> In article <chmnrd$l9l$2@digitaldaemon.com>, Ivan Senji says...
> >
> >Well i use it just because i am lasy :)
> >
> >I have a Tabs class that prints tabs and i didn't feel like creating instances of it. So i do
> >
> >Tabs(file); //prints 0 tabs
> >Tabs++;
> >Tabs(file); /*printf  1 tabs*/
> >    //printf what needs to be indented
> >Tabs--;
> >
> >
> >To support my lazyness :)
> >
>
>

In article <chmvhl$ob6$1@digitaldaemon.com>, Sai says...
>
>No offence, but may be this is what is referred to as operator overloading abuse

Why? It's his program, he can do whatever he wants with it. Using emotionally loaded terms like 'abuse' in a debate about programming is only counter- productive, IMO.

Nick

In article <chmbos$fe6$1@digitaldaemon.com>, Arcane Jill says...
>I could start an off-topic thread on keyboard layouts here. UK keyboards have an extra key, not present on US keyboards. Between [L] and [ENTER] there are three keys, not two, and the extra (rightmost) one contains [#] (unshifted) and [~] (shifted). Other symbols are moved around, basically so that there's room for the British currency symbol [£] on shift-3. I've actually encountered a few US folk who went out their way to obtain British keyboards just to take advantage of that extra key.

I have ø, æ and ' between L and ENTER :-)

>But I don't like <~ either. The main reason I don't like it is because I /do/ like <<, and I see no reason to change it. It works for C++; programmers are already used to it; and I've heard no good arguments against it.

In danger of giving an archetypical 'Me too!'-reply: Me too!

I think << is much easier on the eyes than <~ / ~<. And whatever your keyboard layout a double tap one key is quicker than striking two different keys.

Nick

Nick wrote:
<snip>
> I think << is much easier on the eyes than <~ / ~<. And whatever your keyboard
> layout a double tap one key is quicker than striking two different keys.

You could argue this for changing nearly every operator ever invented. In which case, we'd soon run out of them and need to invent some more triple taps, maybe even quadruple taps....

But either way, it would be somewhat quicker than the mouthful Java makes us type:

    System.out.println("whatever");

....

Stewart.

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

> In article <chn344$q2o$1@digitaldaemon.com>, Nick says...
>
> Why? It's his program, he can do whatever he wants with it.


Yes, as long as the original author is not writing library for others you are right.


> Using emotionally
> loaded terms like 'abuse' in a debate about programming is only counter-
> productive, IMO.


Oops ! but I thought the pharse "operator overloading abuse" is commonly used everywhere.


Anyway, excuse me for "emotional loading" a debate on "operator overloading" :D

;) Sai

Maybe Walter's old idea of using opCall isn't so bad when combined with the
new varargs. Stream's opCall can figure out if it needs to "writef" or
"scanf" for instance by checking if the stream is read-only or write-only
(and if it is both then probably checking where the file pointer is would be
good enough). That way the equivalent to the C++ code below would be
 {
     stdout("Hello!",3.14);
     float f1,f2;
     int i;
     stdin(&f1,&i,&f2);
 }
It still doesn't bind at compile time but it's short and sweet.

In slightly more detail stdout's opCall would be the same as writef("",...) and stdin's opCall would be scanf(computed_format_string,...) where computed_format_string depends on the types of the inputs or, if stream's scanf is improved, the format string could be empty as well and scanf could just parse and fill depending on the types of the inputs.

-Ben

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:chh8fc$16at$1@digitaldaemon.com...
> 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?
>
> :)
>
>
>

"Sai" <Sai_member@pathlink.com> wrote in message news:chnjm5$13nj$1@digitaldaemon.com...
> > In article <chn344$q2o$1@digitaldaemon.com>, Nick says...
> >
> > Why? It's his program, he can do whatever he wants with it.
>
>
> Yes, as long as the original author is not writing library for others you are right.

Oops! This _is_ in a libray but isn't something a user will use or see :)

>
> > Using emotionally
> > loaded terms like 'abuse' in a debate about programming is only counter-
> > productive, IMO.
>
>
> Oops ! but I thought the pharse "operator overloading abuse" is commonly used everywhere.

Well for static opPostInc there should first be a use before it can be
abused.
I don't believe in operator oveloading abuse, it can be done,but many things
that people call abuse isn't actually.

>
> Anyway, excuse me for "emotional loading" a debate on "operator
overloading" :D
>
> ;) Sai
>
>
>
>

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:chnjsb$13r3$1@digitaldaemon.com...
> Maybe Walter's old idea of using opCall isn't so bad when combined with
the
> new varargs. Stream's opCall can figure out if it needs to "writef" or "scanf" for instance by checking if the stream is read-only or write-only

This is a usable idea but why reinvent hot water?
There are far more c++ programmers out there at the moment and
id D provided iostream-like streams it would atract many of them.

cout and cin is the thing i liked most when i started learning c++,
thinking that i can finally get rid of printf. By some chance i stayed with
D in hope of something like that for D. (D is so good that not even
it's forsing of printf couldn't turm me away :)

> (and if it is both then probably checking where the file pointer is would
be
> good enough). That way the equivalent to the C++ code below would be
>  {
>      stdout("Hello!",3.14);
>      float f1,f2;
>      int i;
>      stdin(&f1,&i,&f2);
>  }
> It still doesn't bind at compile time but it's short and sweet.

I agree it is short and sweet, but if we can have compile time why not? I don't think there is anyone who thinks that doing this at runtime is better ;) (if so i would be very interested in hearing why)

PS. when Walter fixed that op*_r problem i thought that we will be getting c++ style streams soon, but std.streams is almost the same as then.

> In slightly more detail stdout's opCall would be the same as
writef("",...)
> and stdin's opCall would be scanf(computed_format_string,...) where computed_format_string depends on the types of the inputs or, if stream's scanf is improved, the format string could be empty as well and scanf
could
> just parse and fill depending on the types of the inputs.
>
> -Ben
>

> 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]);
>     }

Why don't you use scanf? It would become

 stdin.scanf("%f %d",&f,&i);