www.digitalmars.com         C & C++   DMDScript  

D - New to group, but have some suggestions

reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
I am relatively new to this group.  I read the article in DDJ and have been
lurking here for a few weeks to get a feel for the way things are done here.
I think D has great potential.  I am making the following suggestions not
from the perspective of converting programs from C or C++ (sometimes aptly
called C double cross), but from the perspective of sometime in the future
when D is the prevalent first language and C and C++ are relegated to legacy
status. :-)  If any of these have been hashed out before, my apologies.

1.    Variable type names.  I know that short, long, etc. are a C heritage,
but they have and will lead to confusion.  There was confusion over how long
int was when we went from 16 bit to 32 bit computers.  There was a lot of
discussion in the C standards group over what to call 64 bit integers when
they became prevalent.  I am quite sure that we will go through the same
thing when 128 bit variables become common.  What will D call them?
"LongLong", "DoubleLong", "Quad", "ExtraLong", "DoubleTallSkinnyDecaf"? :-)
Given that you have already bitten the bullet and defined integers to be 8,
16, 32, etc. bits exactly (that is, you are ruling out support for systems
with 36 bit words, etc.), why not just use names that reflect what they
truly are.  That is, "Int16", Int32", etc.  If you did that, is there any
doubt what the type name of a future 128 bit integer is?  Of course, you
would add the prefix U for unsigned.  Similarly, you would have "Float32",
etc.  I understand that this might be "jarring" to C programmers converting,
but you could support the old forms as "deprecated" conversion aids.  Note
that another advantage is that this also makes the potential future
implementation of at least some "big num" stuff almost syntactically
transparent.

2.    I agree that the printf holdover from C has lots of problems.  But
even if it isn't replaced, and especially if it is, one of my pet gripes
about most programming languages is that they make it hard for humans to
read the values of large integers and non-exponentially notated floats.  For
example, which of the following is easier to "get" a quick feel for the
magnitude of

    The answer is 875639241357                        or

    The answer is 875,639,241,357

Most languages make it very hard to put in the comma separators that make
reading so much easier.  In order to allow this without breaking anything, I
propose that the format string be enhanced to allow a comma where the period
is now.  Using a comma there would format the number with comma separation
every three digits.  Of course, extra space would have to be allowed when
calculating print spacing, etc., but that is pretty easy.

Along similar lines, and while we are discussing easy of reading of computer
output by humans, consider the following.

    Amount Due $         36.20                            or

    Amount Due          $36.20

The second is easier to read.  This could be trivially implemented by again
enhancing the format string.  Currently, if you put a zero before the type
specifier, it left zero fills, instead of left blank fills to the value.  If
you allowed a dollar sign in addition to the zero, it could indicate float
the currency sign to the last non-blank position.

Some considerations would probably have to be made in these for
internationalization.  These are the two most important and easy to
implement additional formatting functions.  I am not suggesting that D
implement all the flexibility of COBOL's picture clause, just the most
significant.  However, if you want to do more there is more that could be
done pretty easily.

3.    I took the liberty of posting a link on the comp.arch newsgroup.  One
poster noted that the run time model for D currently prohibits its running
on 64 bit systems (more properly on systems that allow greater than 32 bit
pointers).  Given the desire to keep the run time model constant across
architectures, and given the relatively imminent implementation of 64 bit
X86 architectures, with which you would want to be compatible, I think you
should fix that.  Allowing a few more bytes of memory is a pretty trivial
price to pay for not having to worry about this for a long time.

Related to that, I think it would be useful to D if you, Walter, posted on
comp.arch a request for comments and input.  there are a lot of people there
who are quite knowledgeable about what language features allow/prevent
compilers generating code that runs well on the latest and next generations
of processors, have lots of experience in high performance computing,
floating point handling with all of the special cases, exception handling,
etc.  If you requested inputs on that stuff especially, as well as any other
input, I think you would be vastly rewarded.


--
 - Stephen Fuld
   e-mail address disguised to prevent spam
Mar 22 2002
next sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
Stephen Fuld wrote:

 1.    Variable type names.  I know that short, long, etc. are a C heritage,
 but they have and will lead to confusion.  There was confusion over how long
 int was when we went from 16 bit to 32 bit computers. 
 [snip details of int8, int16, int32, int64, uint8...,
 float32... proposal]


Apart from your heretical use of capital letters in
language-defined types, I wholeheartedly support this
notion.



 2.    I agree that the printf holdover from C has lots of problems.  But
 even if it isn't replaced, and especially if it is, one of my pet gripes
 about most programming languages is that they make it hard for humans to
 read the values of large integers and non-exponentially notated floats.  For
 example, which of the following is easier to "get" a quick feel for the
 magnitude of
 
     The answer is 875639241357                        or
 
     The answer is 875,639,241,357


If printf were to be retained, I'd suggest:
printf( "The answer is %,d\n", my_large_integer );

-Russell B
Mar 22 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C9B7C54.5050707 estarcion.com...

 Stephen Fuld wrote:

 2.    I agree that the printf holdover from C has lots of problems.  But
 even if it isn't replaced, and especially if it is, one of my pet gripes
 about most programming languages is that they make it hard for humans to
 read the values of large integers and non-exponentially notated floats.




For

 example, which of the following is easier to "get" a quick feel for the
 magnitude of

     The answer is 875639241357                        or

     The answer is 875,639,241,357


 If printf were to be retained, I'd suggest:
 printf( "The answer is %,d\n", my_large_integer );


That is quite a good idea.
Mar 22 2002
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C9B7C54.5050707 estarcion.com...


 Stephen Fuld wrote:

 1.    Variable type names.  I know that short, long, etc. are a C




heritage,

 but they have and will lead to confusion.  There was confusion over how




long

 int was when we went from 16 bit to 32 bit computers.


  > [snip details of int8, int16, int32, int64, uint8...,
  > float32... proposal]

 Apart from your heretical use of capital letters in
 language-defined types, I wholeheartedly support this
 notion.


I'd say, leave them in, and define the aliases:

    alias byte int8;
    alias short int16;
    alias int int32;
    alias long int128;

The thing is, while all those int* might be easier to understand,
most C programmers will want to see common, expected names. I personally
wouldn't use int16 instead of short in my programs, even if it were
available.
Mar 22 2002
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7ftf8$1gpi$1 digitaldaemon.com...

 I am relatively new to this group.  I read the article in DDJ and have


been

 lurking here for a few weeks to get a feel for the way things are done


here.

 I think D has great potential.  I am making the following suggestions not
 from the perspective of converting programs from C or C++ (sometimes aptly
 called C double cross), but from the perspective of sometime in the future
 when D is the prevalent first language and C and C++ are relegated to


legacy

 status. :-)  If any of these have been hashed out before, my apologies.


Glad to see you posting here.


 1.    Variable type names.  I know that short, long, etc. are a C


heritage,

 but they have and will lead to confusion.  There was confusion over how


long

 int was when we went from 16 bit to 32 bit computers.  There was a lot of
 discussion in the C standards group over what to call 64 bit integers when
 they became prevalent.  I am quite sure that we will go through the same
 thing when 128 bit variables become common.  What will D call them?
 "LongLong", "DoubleLong", "Quad", "ExtraLong", "DoubleTallSkinnyDecaf"?


:-)

 Given that you have already bitten the bullet and defined integers to be


8,

 16, 32, etc. bits exactly (that is, you are ruling out support for systems
 with 36 bit words, etc.), why not just use names that reflect what they
 truly are.  That is, "Int16", Int32", etc.  If you did that, is there any
 doubt what the type name of a future 128 bit integer is?  Of course, you
 would add the prefix U for unsigned.  Similarly, you would have "Float32",
 etc.  I understand that this might be "jarring" to C programmers


converting,

 but you could support the old forms as "deprecated" conversion aids.  Note
 that another advantage is that this also makes the potential future
 implementation of at least some "big num" stuff almost syntactically
 transparent.


I can argue that you can create a list of aliases,
    alias int int32;
etc.



 Along similar lines, and while we are discussing easy of reading of


computer

 output by humans, consider the following.
     Amount Due $         36.20                            or
     Amount Due          $36.20
 The second is easier to read.  This could be trivially implemented by


again

 enhancing the format string.  Currently, if you put a zero before the type
 specifier, it left zero fills, instead of left blank fills to the value.


If

 you allowed a dollar sign in addition to the zero, it could indicate float
 the currency sign to the last non-blank position.


Internationalization of currency formatting is a real problem, but one I
suggest is suited to a library class. Would you like to write one?


 3.    I took the liberty of posting a link on the comp.arch newsgroup.


One

 poster noted that the run time model for D currently prohibits its running
 on 64 bit systems (more properly on systems that allow greater than 32 bit
 pointers).  Given the desire to keep the run time model constant across
 architectures, and given the relatively imminent implementation of 64 bit
 X86 architectures, with which you would want to be compatible, I think you
 should fix that.  Allowing a few more bytes of memory is a pretty trivial
 price to pay for not having to worry about this for a long time.


I don't know why it would be so limited. I'll check the newsgroup and see.


 Related to that, I think it would be useful to D if you, Walter, posted on
 comp.arch a request for comments and input.  there are a lot of people


there

 who are quite knowledgeable about what language features allow/prevent
 compilers generating code that runs well on the latest and next


generations

 of processors, have lots of experience in high performance computing,
 floating point handling with all of the special cases, exception handling,
 etc.  If you requested inputs on that stuff especially, as well as any


other

 input, I think you would be vastly rewarded.


That's a great idea!
Mar 22 2002
next sibling parent reply "Serge K" <skarebo programmer.net> writes:
 I can argue that you can create a list of aliases,
     alias int int32;


or even better:

alias int32 int;
Mar 22 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Serge K" <skarebo programmer.net> wrote in message
news:a7gd14$m0$1 digitaldaemon.com...

 I can argue that you can create a list of aliases,
     alias int int32;


 or even better:
 alias int32 int;


I was afraid someone would point that out <g>.

I suppose I need to point out just why I didn't pick int32. It's purely an
aesthetic one, I just don't like the look of declarations with int32, int16,
etc. It's a little awkward for me to type, too, as I can touch type the
letters but not the numbers.

Try a global search/replace on some source code with int->int32, char->int8,
etc. Is the result pleasing to the eye?
Mar 22 2002
parent reply Russell Borogove <kaleja estarcion.com> writes:
Walter wrote:

 I suppose I need to point out just why I didn't pick int32. It's purely an
 aesthetic one, I just don't like the look of declarations with int32, int16,
 etc. It's a little awkward for me to type, too, as I can touch type the
 letters but not the numbers.
 
 Try a global search/replace on some source code with int->int32, char->int8,
 etc. Is the result pleasing to the eye?


Perhaps not, but IMO far more expressive. So what are you
going to call the 128-bit type?
Mar 22 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C9BD148.6030203 estarcion.com...

 Walter wrote:

 I suppose I need to point out just why I didn't pick int32. It's purely




an

 aesthetic one, I just don't like the look of declarations with int32,




int16,

 etc. It's a little awkward for me to type, too, as I can touch type the
 letters but not the numbers.
 Try a global search/replace on some source code with int->int32,




char->int8,

 etc. Is the result pleasing to the eye?


 Perhaps not, but IMO far more expressive. So what are you
 going to call the 128-bit type?


cent?  (as kilo means 1024, cent should mean 128)
centint?
centurion? <g>
Mar 22 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a7gl5u$6rm$1 digitaldaemon.com...


 Perhaps not, but IMO far more expressive. So what are you
 going to call the 128-bit type?


 cent?  (as kilo means 1024, cent should mean 128)
 centint?
 centurion? <g>


damnlongint =)
Mar 22 2002
prev sibling parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Russell Borogove wrote:


 Walter wrote:

 I suppose I need to point out just why I didn't pick int32. It's purely an
 aesthetic one, I just don't like the look of declarations with int32, int16,
 etc. It's a little awkward for me to type, too, as I can touch type the
 letters but not the numbers.

 Try a global search/replace on some source code with int->int32, char->int8,
 etc. Is the result pleasing to the eye?


 Perhaps not, but IMO far more expressive. So what are you
 going to call the 128-bit type?


Hey!  I've got all these nybbles running around on my 4-bit CPU (for which I
anxiously await a port of D)!  What do I call them?  :P

And what about the lowly bit?  Aren't bits really integers too?  (Teeny-tiny,
itsy-bitsy unsigned ones.  Their signed cousins are used as sign bits, right?)

Let's include everything, and see where it takes us (best viewed with a
fixed-width font):

  C/D       Proposed        Hardware
-------   ------------    ------------
bool        int1            bit
???         int2            ???
????        int4            nybble
char        int8            byte
short       int16           word
int         int32           double-word or dword
long        int64           quad-word or qword
?????       int128          ???
??????      int256          ???


Yes, I added a few just to make the system complete, from a single bit to
int256.  The int2 type (or, more likely, uint2) would be useful for
multiple-valued logic, such as trinary ("true", "false", "indeterminate") or
quaternary (which is often just trinary with a "no value" state).

There actually is a use for int256!  It is the smallest integer size (in our
sequence of size doublings) that can represent the size of the universe (1.5e26
m) using units of the Plank distance (1.6e-35 m).  That's a range of 61 orders
of
magnitude, which requires at least 140 bits to represent, which rules out
int128.  (And you know, I'd just love to do my cosmological quantum gravity
calculations using integer math.)

If I had a vote, I'd vote to make the proposed the default, with whatever
imprecise and/or confusing legacy naming schemes you want to use being optional
(but possibly included with D for porting purposes).

Much of the code I write already uses the intNN notation, no matter what
language
I use.  More and more coding standards specify it (for examples, check the
current DOD standards, and the published coding guides from Cisco, Nortel, IBM
and HP).

Even worse is the use of "unsigned":  Don't we ALL use a typedef or #define to
create the "uint" type?  Unsigned integers should be treated as fundamental
types, not as a "modified" types.  C has a horrible habit of confusing storage
size with type.  Should D propagate it?

After all, int32, uint32 and "float" all occupy 32 bits:  Why don't we have
"signed int", "unsigned int" and "floating int" in C (or in D)?  Silly, eh?  A
numeric type is a numeric type, and they come in families, where the size in
bits
is a VERY useful, unambiguous and compact way to denote the capacity of the
type.  Storage is irrelevant.

There is nothing that says a D implementation can't store int32 in a 64-bit wide
register or memory location, is there?  Or that multiple int2s would be stored
packed into a byte.  Storage is an implementation decision, and so long as I can
use something like "sizeof()" to get the allocation space used by a data item,
I'll get along just fine.  Compilers are supposed to know that kind of stuff,
right?  And anyhow, isn't that the "right" way to program?  (Or are we expected
to handle the alignment and packing issues surrounding aggregate types some
other
way?  Of course not.)

For symmetry, I'd also like to see float32, float64 and float80 added to the
list
of numeric types.  Forget the confusing "float", "double" and "long double"
stuff.  Eliminate fundamental type modifiers!  Each fundamental type should have
its own name, and only its storage/access capabilities should be modifiable
(const, volatile, etc.).

D really should get out in front on this one.

If I had a vote, that is.  If only I had a vote...


-BobC

(Did I remember to ask for D integers that are as smart as D's floats?  I'd like
to have an integer "NAN" be available...)
Mar 22 2002
next sibling parent "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C9BE9CC.9300AD70 yahoo.com...

 Eliminate fundamental type modifiers!  Each fundamental type should have
 its own name, and only its storage/access capabilities should be


modifiable

 (const, volatile, etc.).


One language I know of doesn't have unsigned integers.  It has "nat"s (short
for naturals, as in natural numbers).  So it has nat4 nat8, etc.


 D really should get out in front on this one.


Of course, I agree. :-)

--
 - Stephen Fuld
   e-mail address disguised to prevent spam
Mar 22 2002
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C9BE9CC.9300AD70 yahoo.com...

 Even worse is the use of "unsigned":  Don't we ALL use a typedef or


#define to

 create the "uint" type?


No, I used to use a lot of typedefs for basic types, but have tended to move
away from it.


  Unsigned integers should be treated as fundamental
 types, not as a "modified" types.  C has a horrible habit of confusing


storage

 size with type.  Should D propagate it?


No, D shouldn't (and doesn't). There are no basic types in D composed of
multiple keywords.


 (Did I remember to ask for D integers that are as smart as D's floats?


I'd like

 to have an integer "NAN" be available...)


I'd like it too, unfortunately, the hardware is lacking :-(
Mar 22 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:


 (Did I remember to ask for D integers that are as smart as D's floats?


 I'd like

 to have an integer "NAN" be available...)


 I'd like it too, unfortunately, the hardware is lacking :-(


How about defining a type that has the functionality...some sort of modifier on
int.  For those who want it, it exists and is implemented implicitly (with, of
course, a major runtime penalty) by the compiler.  If it turns out that we use
this a lot, then the chip makers will get a clue and do it in hardware...just
like they started doing floating point, SIMD, and matrix multiplication in
hardware after years of it being in software.

--
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))) ]
Mar 25 2002
parent reply Russell Borogove <kaleja estarcion.com> writes:
Russ Lewis wrote:

 Walter wrote:
 
 

(Did I remember to ask for D integers that are as smart as D's floats?


I'd like


to have an integer "NAN" be available...)


I'd like it too, unfortunately, the hardware is lacking :-(


 
 How about defining a type that has the functionality...some sort of modifier on
 int.  For those who want it, it exists and is implemented implicitly (with, of
 course, a major runtime penalty) by the compiler.  If it turns out that we use
 this a lot, then the chip makers will get a clue and do it in hardware...just
 like they started doing floating point, SIMD, and matrix multiplication in
 hardware after years of it being in software.


Gosh, this almost seems like another use for classes
and operator overloading.

-Russell B
Mar 25 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C9F65C6.9070101 estarcion.com...
<SNIP>

 Gosh, this almost seems like another use for classes
 and operator overloading.

 -Russell B


LOL  :)

--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail
Mar 26 2002
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C9BE9CC.9300AD70 yahoo.com...

 Russell Borogove wrote:



 Even worse is the use of "unsigned":  Don't we ALL use a typedef or


#define to

 create the "uint" type?  Unsigned integers should be treated as


fundamental

 types, not as a "modified" types.  C has a horrible habit of confusing


storage

 size with type.  Should D propagate it?


D doesn't have unsigned. ubyte, ushort, uint, and ulong are all distinct
types.
Mar 22 2002
prev sibling parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a7gb1q$30ej$2 digitaldaemon.com...

 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:a7ftf8$1gpi$1 digitaldaemon.com...

 I am relatively new to this group.  I read the article in DDJ and have


 been

 lurking here for a few weeks to get a feel for the way things are done


 here.

 I think D has great potential.  I am making the following suggestions




not

 from the perspective of converting programs from C or C++ (sometimes




aptly

 called C double cross), but from the perspective of sometime in the




future

 when D is the prevalent first language and C and C++ are relegated to


 legacy

 status. :-)  If any of these have been hashed out before, my apologies.


 Glad to see you posting here.


Thank you.  It seems like a friendly place.



 1.    Variable type names.




snip


 I can argue that you can create a list of aliases,
     alias int int32;
 etc.


Sure, but then it would be my private practice.  I was arguing for better
"hygene" for all users.  :-)


 Along similar lines, and while we are discussing easy of reading of


 computer

 output by humans, consider the following.
     Amount Due $         36.20                            or
     Amount Due          $36.20
 The second is easier to read.  This could be trivially implemented by


 again

 enhancing the format string.  Currently, if you put a zero before the




type

 specifier, it left zero fills, instead of left blank fills to the value.


 If

 you allowed a dollar sign in addition to the zero, it could indicate




float

 the currency sign to the last non-blank position.


 Internationalization of currency formatting is a real problem, but one I
 suggest is suited to a library class. Would you like to write one?


I agree about the problem.  As for me helping to provide a solution, I may
have a problem with that. In what language are such libraries written?  My
first language was Fortran, learned in 1969.  And, while I know others, by
the time C came along and got popular, I was into system architecture and
product strategy so, while I have managed projects written in C, I never
written in it and certainly wouldn't call myself a C programmer.  As for
C++, I saw enough of it to say that I don't want to learn it at all.  There
is some ratio of alphanumeric characters to special characters in a typical
program that I consider a minimum for readability, and C++ is way below that
minimum.  :-)



 3.    I took the liberty of posting a link on the comp.arch newsgroup.


 One

 poster noted that the run time model for D currently prohibits its




running

 on 64 bit systems (more properly on systems that allow greater than 32




bit

 pointers).  Given the desire to keep the run time model constant across
 architectures, and given the relatively imminent implementation of 64




bit

 X86 architectures, with which you would want to be compatible, I think




you

 should fix that.  Allowing a few more bytes of memory is a pretty




trivial

 price to pay for not having to worry about this for a long time.


 I don't know why it would be so limited.


The run time model has the pointer at offset 0 and the monitor at offset 4.
This limits pointers to four bytes.  Other addresses similarly limit you.


 I'll check the newsgroup and see.


It is an interesting place too.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam
Mar 22 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7gom1$96n$2 digitaldaemon.com...


 I can argue that you can create a list of aliases,
     alias int int32;
 etc.


 Sure, but then it would be my private practice.  I was arguing for better
 "hygene" for all users.  :-)


Well, a module like this could be put into standard D distribution.


 Internationalization of currency formatting is a real problem, but one I
 suggest is suited to a library class. Would you like to write one?


 I agree about the problem.  As for me helping to provide a solution, I may
 have a problem with that. In what language are such libraries written?  My


D, of course!
By the way, Walter, what's your vision of D locales? Have you thought
of the class it might employ, its interfaces, etc?


 The run time model has the pointer at offset 0 and the monitor at offset


4.

 This limits pointers to four bytes.  Other addresses similarly limit you.


This was on Intel 32-bit architecture. Otherwise, pointer size is undefined,
so 64-bit systems will have 64-bit pointers (so monitor will be at offset
8).
Mar 22 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a7h22b$eq8$1 digitaldaemon.com...

 By the way, Walter, what's your vision of D locales? Have you thought
 of the class it might employ, its interfaces, etc?


I haven't thought about it. Trouble is, what I do know about it I don't
like - I find C's way of doing it to be unnaturally clunky and of course is
not thread aware, making it fairly useless.

D does do the first step right, by fully supporting unicode both in the
source text and the typing system.
Mar 23 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a7hkob$11c5$2 digitaldaemon.com...


 I haven't thought about it. Trouble is, what I do know about it I don't
 like - I find C's way of doing it to be unnaturally clunky and of course


is

 not thread aware, making it fairly useless.


What about C++? Locales and facets...


 D does do the first step right, by fully supporting unicode both in the
 source text and the typing system.


Yes, and now we need some way to describe formats of numbers and dates,
etc.
Mar 23 2002
parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a7hnrk$1325$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:a7hkob$11c5$2 digitaldaemon.com...

 I haven't thought about it. Trouble is, what I do know about it I don't
 like - I find C's way of doing it to be unnaturally clunky and of course


 is

 not thread aware, making it fairly useless.


 What about C++? Locales and facets...


I don't know much about how that works in real apps.
Mar 24 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a7gom1$96n$2 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:a7gb1q$30ej$2 digitaldaemon.com...

 Internationalization of currency formatting is a real problem, but one I
 suggest is suited to a library class. Would you like to write one?


 I agree about the problem.  As for me helping to provide a solution, I may
 have a problem with that. In what language are such libraries written?  My
 first language was Fortran, learned in 1969.  And, while I know others, by
 the time C came along and got popular, I was into system architecture and
 product strategy so, while I have managed projects written in C, I never
 written in it and certainly wouldn't call myself a C programmer.  As for
 C++, I saw enough of it to say that I don't want to learn it at all.


There

 is some ratio of alphanumeric characters to special characters in a


typical

 program that I consider a minimum for readability, and C++ is way below


that

 minimum.  :-)


A D library should be written in D, of course.
Mar 23 2002
prev sibling parent reply "Christophe Bouchon" <cbouchon hotmail.com> writes:
"Stephen Fuld" Wrote:

 "LongLong", "DoubleLong", "Quad", "ExtraLong", "DoubleTallSkinnyDecaf"?


:-)

 Given that you have already bitten the bullet and defined integers to be


8,

 16, 32, etc. bits exactly (that is, you are ruling out support for systems
 with 36 bit words, etc.), why not just use names that reflect what they
 truly are.  That is, "Int16", Int32", etc.


I always use int1...4 and uint1...4 (with typedefs in a types.h include, I
use the byte size insteaad of the bit size for shorter and easier to type
types) in my C/C++ projects so I completely agree.


     The answer is 875639241357                        or
     The answer is 875,639,241,357


Agreed but: in french ;-) (but also in other roman languages), ',' and '.'
use is reversed:
        La réponse est 875.639.241.357
so you have to think twice about internationalisation and possible
confusions.
I also like the possibility to insert '_' between digits in integers and
floating point constants (but only AFTER the first digit or after the digit
following the '.', else it's ambiguous with identifiers). This way, you can
use 875_639_241_357 in your source code, and also 0x1234_5678_9ABC.


 One poster noted that the run time model for D currently prohibits its


running

 on 64 bit systems (more properly on systems that allow greater than 32 bit


pointers).
Another usefull type: an intptr type being an integer garanted large enough
to contain a pointer on the target plateform.
Mar 22 2002
next sibling parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Christophe Bouchon" <cbouchon hotmail.com> wrote in message
news:a7gjt0$63o$1 digitaldaemon.com...

 "Stephen Fuld" Wrote:


     The answer is 875639241357                        or
     The answer is 875,639,241,357


 Agreed but: in french ;-) (but also in other roman languages), ',' and '.'
 use is reversed:
         La réponse est 875.639.241.357


Oui!  Je t'comprende.  I did say, in part of the post you snipped, that
there were issues with internationalization.  I don't know if Walter has
made any decisions here, but since this stuff is in a library, it seems a
good solution is to leave the syntax in the format string as I specified it,
but interpret it differently in different versions of the library.  I note
that the use of the period in the existing C format string seems standard,
but do libraries print out floating point numbers with a comma between the
integer and fractional parts?  Or do they ignore the internationalization
issues.


 so you have to think twice about internationalisation and possible
 confusions.


Yes.


 I also like the possibility to insert '_' between digits in integers and
 floating point constants (but only AFTER the first digit or after the


digit

 following the '.', else it's ambiguous with identifiers). This way, you


can

 use 875_639_241_357 in your source code, and also 0x1234_5678_9ABC.


And some people prefer blanks.  i.e. 875 639 241 357.

As I said, I wasn't proposing the full generality of the COBOL picture
clause, but there are many enhancements that could be added.


 One poster noted that the run time model for D currently prohibits its


 running

 on 64 bit systems (more properly on systems that allow greater than 32




bit

 pointers).
 Another usefull type: an intptr type being an integer garanted large


enough

 to contain a pointer on the target plateform.


Doing integer arithmetic on pointers is an error prone evil that I would not
want to make any easier.  :-(.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam
Mar 22 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 One poster noted that the run time model for D currently prohibits its


 running

 on 64 bit systems (more properly on systems that allow greater than 32




 bit

 pointers).
 Another usefull type: an intptr type being an integer garanted large


 enough

 to contain a pointer on the target plateform.


 Doing integer arithmetic on pointers is an error prone evil that I would


not

 want to make any easier.  :-(.

 --
  - Stephen Fuld


For systems programming, pointer arithmetic is fairly crucial.  I hear D
aims to be a systems programming language.  And I want everything to be
easier.  ;)

Sean
Mar 23 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a7hpv4$145g$1 digitaldaemon.com...


 For systems programming, pointer arithmetic is fairly crucial.  I hear D
 aims to be a systems programming language.  And I want everything to be
 easier.  ;)


Well, you can cast an integer to a pointer, and you can shift pointers
and subtract them. Just enough, I think.
Mar 23 2002
prev sibling next sibling parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a7hpv4$145g$1 digitaldaemon.com...

 One poster noted that the run time model for D currently prohibits








its

 running

 on 64 bit systems (more properly on systems that allow greater than








32

 bit

 pointers).
 Another usefull type: an intptr type being an integer garanted large


 enough

 to contain a pointer on the target plateform.


 Doing integer arithmetic on pointers is an error prone evil that I would


 not

 want to make any easier.  :-(.

 --
  - Stephen Fuld


 For systems programming, pointer arithmetic is fairly crucial.


Actually, it isn't.  It does require some deviation from the C way of
thinking about things, but a fair amount of systems software has been
written in languages that don't support pointer arithmetic.


 I hear D
 aims to be a systems programming language.  And I want everything to be
 easier.  ;)


Me too.  But we may have a slightly different definition of easier.  Mine
includes encouraging the writing of easily debuggable, maintainable and
modifyable code as a high priority.  Pointer arithmetic works against that,
as Walter pointed out in his DDJ article.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam
Mar 23 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 For systems programming, pointer arithmetic is fairly crucial.


 Actually, it isn't.  It does require some deviation from the C way of
 thinking about things, but a fair amount of systems software has been
 written in languages that don't support pointer arithmetic.


 I hear D aims to be a systems programming language.  And I want




everything to be

 easier.  ;)


 Me too.  But we may have a slightly different definition of easier.  Mine
 includes encouraging the writing of easily debuggable, maintainable and
 modifyable code as a high priority.  Pointer arithmetic works against


that,

 as Walter pointed out in his DDJ article.

 --
  - Stephen Fuld


Good luck getting the hardware people to stop requiring aligned addresses
then.

Maybe if D runtime library provided a way to align pointers without all the
icky typecasting to int and such... i.e.

instead of :

Foo* pAlignedFoo = cast(Foo*)((cast(uint)pFoo + 31)& ~31);

you'd have something like:

Foo* pAlignedFoo = AlignPtr(pFoo, 32);

Be nice to have versions that rounded either up or down.

Sure there's that nifty ideal of highly portable and maintainable very clean
code... and then there's code that's written in the real world, that
actually gets the work done.  The ideal is neat, and I commend anyone who
tries to approach it, but face it; it's not possible to make most programs
100% clean.

Sean
Mar 25 2002
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a7nuas$2p23$1 digitaldaemon.com...

 Sure there's that nifty ideal of highly portable and maintainable very


clean

 code... and then there's code that's written in the real world, that
 actually gets the work done.  The ideal is neat, and I commend anyone who
 tries to approach it, but face it; it's not possible to make most programs
 100% clean.


I like a practical person. I've ported a lot of code between systems, and it
really isn't necessary to have your code 100% portable to do it. Just put
the code that changes in a separate module and reimplement that module for
each platform. No big deal, and I'm not willing to sacrifice performance to
the gods of ANSI clean and 100% portable code <g>.

(One horrible thing I do is vptr jamming to change the type of a variant.
Naturally, where the vptr is stored varies from compiler to compiler, but I
just have a special function to do that and reimplement it for each
compiler/system. No biggie.)
Mar 29 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a7hpv4$145g$1 digitaldaemon.com...

 One poster noted that the run time model for D currently prohibits








its

 running

 on 64 bit systems (more properly on systems that allow greater than








32

 bit

 pointers).






This was an error in the documentation. D will work fine with 64 bit
pointers.


 Another usefull type: an intptr type being an integer garanted large


 enough

 to contain a pointer on the target plateform.






Yes, there should be an import with typedefs in it <g>.


 For systems programming, pointer arithmetic is fairly crucial.  I hear D
 aims to be a systems programming language.  And I want everything to be
 easier.  ;)


LOL. In my experience, and in working on other peoples' code, I constantly
find sort implemented and reimplemented, sometimes multiple times in the
same program. Some people do use qsort(), but (at least I) always have to
look up the man page on qsort(), and always have to carefully construct the
right compare() function for it, then test that I put the right number of
*'s on the pointers to it, etc. Even going through all that, it isn't thread
safe if compare() needs additional info.

But in looking at qsort(), all it can sort are arrays. So why not build in a
sort as part of an array? Voila, in D,

    type[] array;
    ...
    array.sort;        // sort it

That's all.
Mar 29 2002
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Christophe Bouchon" <cbouchon hotmail.com> wrote in message
news:a7gjt0$63o$1 digitaldaemon.com...


 Another usefull type: an intptr type being an integer garanted large


enough

 to contain a pointer on the target plateform.


Why should anybody need it for _multiplatform_ application?
Mar 22 2002
parent "Christophe Bouchon" <cbouchon hotmail.com> writes:
For functions passing/retrieving generic data (either int or pointer). This
is not a recommanded coding practice but you have to consider existing
code/libraries... Windows uses INT_PTR/UINT_PTR (plus SSIZE_T/SIZE_T, same
types with different names) where an integer large enough to contain
pointers is required. On some plateforms, sizeof(void*) != sizeof(int) (not
CURRENT targets for D, like AS/400 if I remeber what a colleague told me
about a port on this plateform, something like 48 bit long pointers). It's
always better to have the type in the language than to try to maintain
system specific definitions.

"Pavel Minayev" wrote:

 "Christophe Bouchon" <cbouchon hotmail.com> wrote in message
 news:a7gjt0$63o$1 digitaldaemon.com...


 Another usefull type: an intptr type being an integer garanted large


 enough

 to contain a pointer on the target plateform.


 Why should anybody need it for _multiplatform_ application?
Mar 23 2002