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.


 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


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


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

> 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

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

 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

 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

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

 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

 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

 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

 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

 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.

 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.

 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

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

 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

 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;

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


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


 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,


 etc. Is the result pleasing to the eye?

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

 (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

 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

 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?

 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?

 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?

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


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

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

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

 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

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

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


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


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


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

 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

 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

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


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

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


 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.

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


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


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


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


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


 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

 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

 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

 not thread aware, making it fairly useless.


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?

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.

 is some ratio of alphanumeric characters to special characters in a

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

 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

 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.

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

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

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

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

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

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

 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

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


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

 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

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


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

 to contain a pointer on the target plateform.

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

 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




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




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

 to contain a pointer on the target plateform.

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

 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


 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

 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

 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




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




 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

 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

 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

 to contain a pointer on the target plateform.

Why should anybody need it for _multiplatform_ application?

Mar 23 2002