www.digitalmars.com         C & C++   DMDScript  

D - Conversion numb to string.

reply "anderson" <anderson firestar.com.au> writes:
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.
May 19 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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.
May 20 2002
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
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.
May 19 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"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.
May 20 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
May 20 2002
next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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.
May 21 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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.
May 22 2002
parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"Sean L. Palmer" wrote:


 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.


I like this idea!  I would also note, though, that any functions you define this
way could never be virtual.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
May 22 2002
prev sibling parent "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"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.


Ahhh!  Another beautiful theory, spoiled by an ugly fact  :-(

--
 - Stephen Fuld
   e-mail address disguised to prevent spam
May 22 2002
prev sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
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.
May 20 2002
prev sibling parent reply Jonathan Andrew <jon ece.arizona.edu> writes:
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
May 20 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"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...
May 20 2002