"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.

"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.

"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.

> > > 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

"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.

"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

"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.

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

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

> > 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