I've always had trouble neatly converting a numb to string (or via versa) in C++.  Not that I haven't done it a million times using either sprintf, atof/atoi, string or CString.  Is there an quick/easy way to convert values to strings and back in D?  (there probably is)

If not I'd be nice if integers/floats came with a ".string" propertly and strings with a ".int" propertly. I know Java does something simular to this, but it does it as part of the class which would be extra overhead. Parhaps the conversion mechanism used in classes could be used so they could support this as well.

"anderson" <anderson@firestar.com.au> wrote in message news:aca1hm$2fv6$1@digitaldaemon.com...

> I've always had trouble neatly converting a numb to string (or via versa)
in
> C++.  Not that I haven't done it a million times using either sprintf, atof/atoi, string or CString.  Is there an quick/easy way to convert
values
> to strings and back in D?  (there probably is)

atof() and atoi() are there for sure. I don't exactly remember if toString()
is defined for doubles somewhere in Phobos, but you can use my version from
math2.d (it's in src/phobos as well). Also, the string module has toString()
overloaded for int.

It is a good idea.

"anderson" <anderson@firestar.com.au> wrote in message news:aca1hm$2fv6$1@digitaldaemon.com...
> I've always had trouble neatly converting a numb to string (or via versa)
in
> C++.  Not that I haven't done it a million times using either sprintf, atof/atoi, string or CString.  Is there an quick/easy way to convert
values
> to strings and back in D?  (there probably is)
>
> If not I'd be nice if integers/floats came with a ".string" propertly and strings with a ".int" propertly. I know Java does something simular to
this,
> but it does it as part of the class which would be extra overhead. Parhaps the conversion mechanism used in classes could be used so they could
support
> this as well.
>
>

anderson wrote:

> I've always had trouble neatly converting a numb to string (or via versa) in C++.  Not that I haven't done it a million times using either sprintf, atof/atoi, string or CString.  Is there an quick/easy way to convert values to strings and back in D?  (there probably is)
>
> If not I'd be nice if integers/floats came with a ".string" propertly and strings with a ".int" propertly. I know Java does something simular to this, but it does it as part of the class which would be extra overhead. Parhaps the conversion mechanism used in classes could be used so they could support this as well.

How does D give methods to primitive types? Are they "pseudo-objects" whose
methods are translated to function calls by the compiler? I am for the idea of
adding toString, toInt, etc... (syntax up to you, but that is how java does it)
methods to all of the types, regardless of how it is implemented though.  Just
implementing a full set of "to" functions in the standard lib would be nice as
well.
-Jon

"Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CE92AEB.8A901AAF@ece.arizona.edu...

> How does D give methods to primitive types? Are they "pseudo-objects"
whose
> methods are translated to function calls by the compiler? I am for the
idea of

Exactly.

> adding toString, toInt, etc... (syntax up to you, but that is how java
does it)
> methods to all of the types, regardless of how it is implemented though.
Just
> implementing a full set of "to" functions in the standard lib would be
nice as
> well.

And it is how it works. For anything that is object, you use the toString() method. For anything else, an overloaded version of global toString() should exist. I think this rule is being followed so far...

"Walter" <walter@digitalmars.com> wrote in message news:acb55h$lof$1@digitaldaemon.com...
> It is a good idea.

Perhaps there is a way to extend use of this to solve the I/O formatting problem as well.  Just have the formatting code call each variable's to string method. (If a variable was already a string, the method would return the same string.).  Then, if someone wanted some special formatting, he could override the tostring method.  It also handles the formatting problems of complex variables automatically and very nicely also.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam


> "anderson" <anderson@firestar.com.au> wrote in message news:aca1hm$2fv6$1@digitaldaemon.com...
> > I've always had trouble neatly converting a numb to string (or via
versa)
> in
> > C++.  Not that I haven't done it a million times using either sprintf, atof/atoi, string or CString.  Is there an quick/easy way to convert
> values
> > to strings and back in D?  (there probably is)
> >
> > If not I'd be nice if integers/floats came with a ".string" propertly
and
> > strings with a ".int" propertly. I know Java does something simular to
> this,
> > but it does it as part of the class which would be extra overhead.
Parhaps
> > the conversion mechanism used in classes could be used so they could
> support
> > this as well.
> >
> >
>
>

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:acbltp$14nt$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:acb55h$lof$1@digitaldaemon.com...
> > It is a good idea.
>
> Perhaps there is a way to extend use of this to solve the I/O formatting problem as well.  Just have the formatting code call each variable's to string method. (If a variable was already a string, the method would
return
> the same string.).  Then, if someone wanted some special formatting, he could override the tostring method.  It also handles the formatting
problems
> of complex variables automatically and very nicely also.

The problem with that approach is there's no vptr for the basic types, so no way to override it.

Walter, if you do this, please have the compiler know that the string should be cached if the value hasn't changed since it was last used.  I'd go so far as to make it a restiction on implementing toString() that it has to return the same string if it hasn't been changed.  It wouldn't have to remember the value but could be allowed to reuse it if it wished.

In fact that's a good thing to have in the language somehow;  The concept of a "const method" which absolutely cannot change the state or value of an object, and if called on the same object is assumed by the compiler to always return the same result so long as that object doesn't change.  In Turing, all functions are this way, (they cannot have side-effects), and all procedures are assumed if not required to have side effects.

I'm not sure it should go so far as requiring that this always has to be true:  Foo a,b; b = a; assert(a.string() == b.string());  that objects which are copies of each other should always return the same value as each other but that could be a powerful optimization tool as well.  But all basic types share this kind of guarantee.  It'd be nice to be able to tell the compiler my class is like that; i.e. it's like a basic type.  Maybe in D, structs could be like basic types and classes could be how they are now.

Or perhaps you could consider truly unifying basic types and user-defined types at the language level.

Sean

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:acbltp$14nt$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:acb55h$lof$1@digitaldaemon.com...
> > It is a good idea.
>
> Perhaps there is a way to extend use of this to solve the I/O formatting problem as well.  Just have the formatting code call each variable's to string method. (If a variable was already a string, the method would
return
> the same string.).  Then, if someone wanted some special formatting, he could override the tostring method.  It also handles the formatting
problems
> of complex variables automatically and very nicely also.
>
> --
>  - Stephen Fuld
>    e-mail address disguised to prevent spam
>
>
> > "anderson" <anderson@firestar.com.au> wrote in message news:aca1hm$2fv6$1@digitaldaemon.com...
> > > I've always had trouble neatly converting a numb to string (or via
> versa)
> > in
> > > C++.  Not that I haven't done it a million times using either sprintf, atof/atoi, string or CString.  Is there an quick/easy way to convert
> > values
> > > to strings and back in D?  (there probably is)
> > >
> > > If not I'd be nice if integers/floats came with a ".string" propertly
> and
> > > strings with a ".int" propertly. I know Java does something simular to
> > this,
> > > but it does it as part of the class which would be extra overhead.
> Parhaps
> > > the conversion mechanism used in classes could be used so they could
> > support
> > > this as well.
> > >
> > >
> >
> >
>
>

So, a basic type and a struct have a lot in common.  You can inherit from them but you can't override any existing method.  I'd actually like to be able to decorate some struct I didn't write or some basic type with new properties or methods.  They would only have to be visible within my code, and the compiler could easily transform this syntax into function calls. Consider:

file f1.d:
=======
int x;

void f(){ x = -5; }

void j() { x = x.abs(); } // error... didn't import that definition here

file f2.d:
=======
import f1;

// tell the compiler we're going to extend the definition of int.  int must
be declared in this file, or in an import, or must be a basic type.
extend struct const int   // const tells the compiler this class is like a
basic value type; no tricky hidden behaviors
{
  int abs() { return *this < 0 ? -*this : *this; }
};

int main()
{
   f1.f();
   return f1.x.abs();  // returns 5
}


Now that could be cool.

The restriction would be that you could inherit from basic types only to structs, not classes.  And structs can not have virtual methods and cannot override a method (though they can hide it).  I wouldn't allow hiding or alteration of basic properties of basic types (such as int's operator +) since it would certainly break a lot of code that depended on basic types working in a certain way.  But it'd be nice to be able to improve upon my compiler vendor's supplied basic types by adding *new* methods to them.

Or maybe next year Intel will make another chip that has a division bug.  ;) It'd make it easy for all those programmers if they could just redefine global operator float operator/(float,float) and float& operator/=(float,float).  ;)  Of course no more than one of these "overrides" could be allowed in a given scope, or there'd have to be an indication of which one to use.

How do you indicate global scope in D?  There's no ::

Sean

"Walter" <walter@digitalmars.com> wrote in message news:acc8o2$1lok$1@digitaldaemon.com...
>
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:acbltp$14nt$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:acb55h$lof$1@digitaldaemon.com...
> > > It is a good idea.
> >
> > Perhaps there is a way to extend use of this to solve the I/O formatting problem as well.  Just have the formatting code call each variable's to string method. (If a variable was already a string, the method would
> return
> > the same string.).  Then, if someone wanted some special formatting, he could override the tostring method.  It also handles the formatting
> problems
> > of complex variables automatically and very nicely also.
>
> The problem with that approach is there's no vptr for the basic types, so
no
> way to override it.

In addendum I'd like to point out that I don't want methods declared outside the original declaration to be able to access private methods or data (maybe only one definition linked in could not have the "extend" keyword, all others would have to have it.).

So you could only decorate classes with methods built on their original public interface.  Just convenient syntax sugar for a normal function call taking a reference to an object of the type as a hidden "this" parameter, just grouped together and placed into the scope of the class.

Is this even remotely technically feasible?  I wonder how one would import them;  maybe they would just become part of the class symbol table if the file imports a module containing the (public) extended class definition.  Or declare the extention in the current module somewhere.

Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:accr8j$25nd$1@digitaldaemon.com...
> So, a basic type and a struct have a lot in common.  You can inherit from them but you can't override any existing method.  I'd actually like to be able to decorate some struct I didn't write or some basic type with new properties or methods.  They would only have to be visible within my code, and the compiler could easily transform this syntax into function calls. Consider:
>
> file f1.d:
> =======
> int x;
>
> void f(){ x = -5; }
>
> void j() { x = x.abs(); } // error... didn't import that definition here
>
> file f2.d:
> =======
> import f1;
>
> // tell the compiler we're going to extend the definition of int.  int
must
> be declared in this file, or in an import, or must be a basic type.
> extend struct const int   // const tells the compiler this class is like a
> basic value type; no tricky hidden behaviors
> {
>   int abs() { return *this < 0 ? -*this : *this; }
> };
>
> int main()
> {
>    f1.f();
>    return f1.x.abs();  // returns 5
> }
>
>
> Now that could be cool.
>
> The restriction would be that you could inherit from basic types only to structs, not classes.  And structs can not have virtual methods and cannot override a method (though they can hide it).  I wouldn't allow hiding or alteration of basic properties of basic types (such as int's operator +) since it would certainly break a lot of code that depended on basic types working in a certain way.  But it'd be nice to be able to improve upon my compiler vendor's supplied basic types by adding *new* methods to them.
>
> Or maybe next year Intel will make another chip that has a division bug.
;)
> It'd make it easy for all those programmers if they could just redefine global operator float operator/(float,float) and float& operator/=(float,float).  ;)  Of course no more than one of these "overrides" could be allowed in a given scope, or there'd have to be an indication of which one to use.
>
> How do you indicate global scope in D?  There's no ::
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:acc8o2$1lok$1@digitaldaemon.com...
> >
> > "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:acbltp$14nt$1@digitaldaemon.com...
> > >
> > > "Walter" <walter@digitalmars.com> wrote in message news:acb55h$lof$1@digitaldaemon.com...
> > > > It is a good idea.
> > >
> > > Perhaps there is a way to extend use of this to solve the I/O
formatting
> > > problem as well.  Just have the formatting code call each variable's
to
> > > string method. (If a variable was already a string, the method would
> > return
> > > the same string.).  Then, if someone wanted some special formatting,
he
> > > could override the tostring method.  It also handles the formatting
> > problems
> > > of complex variables automatically and very nicely also.
> >
> > The problem with that approach is there's no vptr for the basic types,
so
> no
> > way to override it.
>
>
>