www.digitalmars.com         C & C++   DMDScript  

D - Suggestions

reply Mr. B.B.C. <Mr._member pathlink.com> writes:
Some suggestions for D:

data types:
use int8, int16, int32, int64, int128 and so on instead of "char" "unsigned
char" "short" and so on, especially instead of "long long" and other stuff.

Perhaps you may include even a "uint8" or let this make a "typedef unsigned int8
uint8;"...

address: instead of void* - an unsigned integer in the address width of the
destination platform i.e. uint32 or uint64... address/pointer as memory block
size in one.

int: is always "signed address" (address width of platform), but not treated as
a pointer.

filesize: an unsigned integer in the width of a filesize of the destination
platform.

dec64, dec128 - decimal data types, i.e. decimal factor(3/4) and exponent(1/4)
to the base 10 for avoiding conversion errors between decimal float point values
and IEEE 754

"float" and "double" are o.k. float32/float64 would be more systematical.

- porting to D stays easy, simply add a typedef-header...

---

treating the data types like a class is a good idea (e.g. char.size char.max)

---

strings should be better classes - invent a new standard class.

The disadvantage of a compiler string type is, that it can't be extended, e.g.
from ASCII to UTF8 or UTF16...

Resizing strings this way: string.length = ... is bad style; such must be done
by a member function; further "length" is the length of the string, not the
memory that has been allocated for.

---

I don't see any sense in the use of "interfaces" - this is just an invention of
M$ making programming much more incompatible. But couldn't this really not be
done by classes/member functions ?

---

Linking libraries by a simple "import" keyword instead of #including a header
file and add the respective library to the linker settings is a good idea.

---

Doing without macros/preprocessor instructions is a bad idea. You can't do
everything just with functions. A simple example is conditional compiling, e.g.
debug stuff in debug builds...

I'd make "import" to a preprocessor instruction - and think "#using" is a better
expression.

---

The advantage of prototypes/declarations was that it forced the programmers to
write down all functions in some kind of overview, which lead to the first code
documentation.

---

Memory managment should be the job of the debugger/library. If someone really
doesn't care about the memory usage, his program shall crash, or he shall use
BASIC.

At least functions like free() and delete/destructors shall stay for the clean
programmers.
Mar 03 2004
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Mr. B.B.C. wrote:

 Some suggestions for D:
 
 data types:
 use int8, int16, int32, int64, int128 and so on instead of "char" 
 "unsigned char" "short" and so on, especially instead of "long long" 
 and other stuff.

That would be taking a step back. byte and char, short and wchar, int and dchar weren't distinguished for nothing.
 Perhaps you may include even a "uint8" or let this make a "typedef
 unsigned int8 uint8;"...

'unsigned' is not a D keyword. Have you even read the docs?
 address: instead of void* - an unsigned integer in the address width 
 of the destination platform i.e. uint32 or uint64... address/pointer 
 as memory block size in one.

That's exactly what a pointer is.
 int: is always "signed address" (address width of platform), but not
 treated as a pointer.

You mean that's your misunderstanding, or what you want it to be? <snip>
 strings should be better classes - invent a new standard class.
 
 The disadvantage of a compiler string type is, that it can't be 
 extended, e.g. from ASCII to UTF8 or UTF16...

How do you work that out?
 Resizing strings this way: string.length = ... is bad style; such 
 must be done by a member function; further "length" is the length of 
 the string, not the memory that has been allocated for.

Are you a language purist?
 I don't see any sense in the use of "interfaces" - this is just an 
 invention of M$

Actually, I think $un got there first.
 making programming much more incompatible.

Would you care to elaborate?
 But couldn't this really not be done by classes/member functions ?

If Walter had convoluted the language to support multiple inheritance, it could. But he hasn't, and for a reason. <snip>
 Doing without macros/preprocessor instructions is a bad idea. You 
 can't do everything just with functions. A simple example is 
 conditional compiling, e.g. debug stuff in debug builds...

Troll alert! Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Mar 03 2004
prev sibling next sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
Some suggestions for D:

data types:
use int8, int16, int32, int64, int128 and so on instead of "char" "unsigned
char" "short" and so on, especially instead of "long long" and other stuff.

Perhaps you may include even a "uint8" or let this make a "typedef unsigned int8
uint8;"...

There is no typeunsigend char, nor long long., so what are you talking about? look at http://www.digitalmars.com/d/type.html
address: instead of void* - an unsigned integer in the address width of the
destination platform i.e. uint32 or uint64... address/pointer as memory block
size in one.

???
int: is always "signed address" (address width of platform), but not treated as
a pointer.

What is a sigend address.
filesize: an unsigned integer in the width of a filesize of the destination
platform.

Valid point. at the moment it's uint (32Bit) whih isn't enough.
dec64, dec128 - decimal data types, i.e. decimal factor(3/4) and exponent(1/4)
to the base 10 for avoiding conversion errors between decimal float point values
and IEEE 754

Write your own class.
"float" and "double" are o.k. float32/float64 would be more systematical.

D wants to look like C, so this isn't an option.
- porting to D stays easy, simply add a typedef-header...

porting what?
treating the data types like a class is a good idea (e.g. char.size char.max)

They arent. Ever tried int foo = new int();
The disadvantage of a compiler string type is, that it can't be extended, e.g.
from ASCII to UTF8 or UTF16...

Don't get it.
Resizing strings this way: string.length = ... is bad style; such must be done
by a member function; further "length" is the length of the string, not the
memory that has been allocated for.

In D methods with only one argument can be called using the assignment operator: class Foo { public void length (int x) {} } Foo foo = new Foo(); foo.length = 44; So enforcing another synthax would be very inconsistent. So this is a very bad idea.
I don't see any sense in the use of "interfaces" - this is just an invention of
M$ making programming much more incompatible. But couldn't this really not be
done by classes/member functions ?

M$ didn't invent interfaces. Thy took them from Java and there were languages before that had some kind of interface/protocoll. And no, it can't be done using classes, as D only supports single inheritance.
Linking libraries by a simple "import" keyword instead of #including a header
file and add the respective library to the linker settings is a good idea.

You don't link librarys using import.
Doing without macros/preprocessor instructions is a bad idea. You can't do
everything just with functions. A simple example is conditional compiling, e.g.
debug stuff in debug builds...

Learn the basics of the language before you criticiese something!!! There is "version".
I'd make "import" to a preprocessor instruction - and think "#using" is a better
expression.

But import does something that can't be done by a preprocessor. So this is plain stupid.
The advantage of prototypes/declarations was that it forced the programmers to
write down all functions in some kind of overview, which lead to the first code
documentation.

You have to write down everything twice at different places. That makes it harder to change something. You are the first person I know that likes redundancy.
Memory managment should be the job of the debugger/library. If someone really
doesn't care about the memory usage, his program shall crash, or he shall use
BASIC.

(ironic)Of course, memory management is done by the debugger.(/ironic) Do you know anything about coding?
At least functions like free() and delete/destructors shall stay for the clean
programmers.

What could you do what you can't using auto and/or self written allocators/deallocators? Damn, this was the most stupid thread for a long time.
Mar 03 2004
prev sibling parent Nam <Nam_member pathlink.com> writes:
In doc , D has a type alias named "alias";
So you can write a type defined module like that

alias byte int8;
alias short int16;
alias int int32;
and let's go with the source ;)

int32 temp;
temp=32432; ettc...

I see it but I never try it ;) short and int are enough for me .
btw , the int32 seems like the one come from Delphi and HLA . D'you a HLA user ?
In article <c24l04$lrg$1 digitaldaemon.com>, Mr. B.B.C. says...
Some suggestions for D:

data types:
use int8, int16, int32, int64, int128 and so on instead of "char" "unsigned
char" "short" and so on, especially instead of "long long" and other stuff.

Perhaps you may include even a "uint8" or let this make a "typedef unsigned int8
uint8;"...

address: instead of void* - an unsigned integer in the address width of the
destination platform i.e. uint32 or uint64... address/pointer as memory block
size in one.

int: is always "signed address" (address width of platform), but not treated as
a pointer.

filesize: an unsigned integer in the width of a filesize of the destination
platform.

dec64, dec128 - decimal data types, i.e. decimal factor(3/4) and exponent(1/4)
to the base 10 for avoiding conversion errors between decimal float point values
and IEEE 754

"float" and "double" are o.k. float32/float64 would be more systematical.

- porting to D stays easy, simply add a typedef-header...

---

treating the data types like a class is a good idea (e.g. char.size char.max)

---

strings should be better classes - invent a new standard class.

The disadvantage of a compiler string type is, that it can't be extended, e.g.
from ASCII to UTF8 or UTF16...

Resizing strings this way: string.length = ... is bad style; such must be done
by a member function; further "length" is the length of the string, not the
memory that has been allocated for.

---

I don't see any sense in the use of "interfaces" - this is just an invention of
M$ making programming much more incompatible. But couldn't this really not be
done by classes/member functions ?

---

Linking libraries by a simple "import" keyword instead of #including a header
file and add the respective library to the linker settings is a good idea.

---

Doing without macros/preprocessor instructions is a bad idea. You can't do
everything just with functions. A simple example is conditional compiling, e.g.
debug stuff in debug builds...

I'd make "import" to a preprocessor instruction - and think "#using" is a better
expression.

---

The advantage of prototypes/declarations was that it forced the programmers to
write down all functions in some kind of overview, which lead to the first code
documentation.

---

Memory managment should be the job of the debugger/library. If someone really
doesn't care about the memory usage, his program shall crash, or he shall use
BASIC.

At least functions like free() and delete/destructors shall stay for the clean
programmers.

Mar 03 2004