www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - to alias, or not to alias

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
... that is the question.

I was looking over some libraries again,
and reflected upon the typedefs that such
C libraries tend to have (especially old):

alias ubyte   Byte;  /* 8 bits */
alias uint    uInt;  /* 16 bits or more */
alias uint   uLong;  /* 32 bits or more */

alias byte GLbyte;
alias short GLshort;
alias int GLint;

alias byte      Sint8;
alias short     Sint16;
alias int       Sint32;


The first gut reaction is of course to
change them, copy and paste them to the
fixed-size types built into D instead.

But that quickly gets rather tedious,
multipled by X libraries and Y headers
and Z lines of sample code and examples ?


So I'm thinking to leave them in instead.
That would make it much simpler to "port"
the headers and the sample code, from C/C++.
(like 95% of it being done by a Perl script)

The new "pure" D code should of course just
as well just use the built-in types instead.
(for instance: "std.zlib" could use D types,
while as "std.c.zlib" could use the C types)


What do you think ? (thought it would be
better to decide, before I sent zlib.d in
- I updated it from the zlib-1.2.2: zlib.h)

Walter copied/pasted the old copy of zlib,
but I'm thinking that using the C types is
the approach to take with the import modules...

--anders


PS. Fortunately, stdint.h / stdint.d should make
     these things easier in the future. Hopefully.
     (as one can use the same aliases on both...)
Apr 13 2005
next sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Yes, I would also think it better to leave the C definitions as they are, and
change things as they are ported over to D.  Anybody working on a program to
port C to D, by the way?  Got me curious now, because I've been thinking since
I first encountered the D language (which wasn't long ago) that it would be
great if there was a way to port C code into D, even if only to see how it
might look.  :)

TZ

"Anders F Björklund" <afb algonet.se> wrote in message
news:d3ipji$1ac8$1 digitaldaemon.com...

 ... that is the question.

 I was looking over some libraries again,
 and reflected upon the typedefs that such
 C libraries tend to have (especially old):

 alias ubyte   Byte;  /* 8 bits */
 alias uint    uInt;  /* 16 bits or more */
 alias uint   uLong;  /* 32 bits or more */

 alias byte GLbyte;
 alias short GLshort;
 alias int GLint;

 alias byte      Sint8;
 alias short     Sint16;
 alias int       Sint32;


 The first gut reaction is of course to
 change them, copy and paste them to the
 fixed-size types built into D instead.

 But that quickly gets rather tedious,
 multipled by X libraries and Y headers
 and Z lines of sample code and examples ?


 So I'm thinking to leave them in instead.
 That would make it much simpler to "port"
 the headers and the sample code, from C/C++.
 (like 95% of it being done by a Perl script)

 The new "pure" D code should of course just
 as well just use the built-in types instead.
 (for instance: "std.zlib" could use D types,
 while as "std.c.zlib" could use the C types)


 What do you think ? (thought it would be
 better to decide, before I sent zlib.d in
 - I updated it from the zlib-1.2.2: zlib.h)

 Walter copied/pasted the old copy of zlib,
 but I'm thinking that using the C types is
 the approach to take with the import modules...

 --anders


 PS. Fortunately, stdint.h / stdint.d should make
      these things easier in the future. Hopefully.
      (as one can use the same aliases on both...)
Apr 13 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
TechnoZeus wrote:


 Yes, I would also think it better to leave the C definitions as they
 are, and change things as they are ported over to D.  Anybody working
 on a program to port C to D, by the way?  Got me curious now, because
 I've been thinking since I first encountered the D language (which
 wasn't long ago) that it would be great if there was a way to port C
 code into D, even if only to see how it might look.  :)


Several are working on such tools, to D - both from C and from Java.
Check out http://www.dsource.org/projects/ for a project list ?

Although for C, it mostly focuses on porting the .h header files...

An old version of my own hack: http://www.algonet.se/~afb/d/h2d.pl
(I think that version does funny things to some #define constructs)

Note that D abhors "porting" C in general, since it is link-compatible.

--anders

PS. You have seen http://www.digitalmars.com/d/ctod.html, yes ?
Apr 13 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Yes, I know... not much sense in trying to port everything... but to be able to
look at something in both languages, side by side, sounds like an interesting
learning tool at the very least.   I love learning.  Can't get enough of it.  :)

TZ

"Anders F Björklund" <afb algonet.se> wrote in message
news:d3j624$1m18$1 digitaldaemon.com...

 TechnoZeus wrote:


 Yes, I would also think it better to leave the C definitions as they
 are, and change things as they are ported over to D.  Anybody working
 on a program to port C to D, by the way?  Got me curious now, because
 I've been thinking since I first encountered the D language (which
 wasn't long ago) that it would be great if there was a way to port C
 code into D, even if only to see how it might look.  :)


 Several are working on such tools, to D - both from C and from Java.
 Check out http://www.dsource.org/projects/ for a project list ?

 Although for C, it mostly focuses on porting the .h header files...

 An old version of my own hack: http://www.algonet.se/~afb/d/h2d.pl
 (I think that version does funny things to some #define constructs)

 Note that D abhors "porting" C in general, since it is link-compatible.

 --anders

 PS. You have seen http://www.digitalmars.com/d/ctod.html, yes ?
Apr 13 2005
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
news:d3j5hc$1lnm$1 digitaldaemon.com...

 Yes, I would also think it better to leave the C definitions as they are, 
 and change things as they are ported over to D.


I agree, as it's much easier to, say, follow documentation made for the 
C/C++ version of the library when using it in D, so when the docs refer to 
some type, you can just use it in D.
Apr 13 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Jarrett Billingsley wrote:


Yes, I would also think it better to leave the C definitions as they are, 
and change things as they are ported over to D.


 
 I agree, as it's much easier to, say, follow documentation made for the 
 C/C++ version of the library when using it in D, so when the docs refer to 
 some type, you can just use it in D. 


Thanks, everybody who offered their input...


Went with the C types, even it if contradicts "The D Style" :

http://www.digitalmars.com/d/dstyle.html:

"  Meaningless Type Aliases
    Things like:

	alias void VOID;
	alias int INT;
	alias int* pint;
	
    should be avoided.    "

Naturally, *new* D code doesn't have these. This was legacy...
(i.e. for linking with C libraries, so called "import modules")


And the samples did prove trivial to port, just as suspected...

1. #include <stdio.h> -> import std.c.stdio;
2. int main(int argc, char* argv[] -> int main(char[][] args);
3. Done (well, more or less ;-) )

The only tricky part is where macros in the header files
requires library object code to be linked, on the D side.


Emailed the new zlib.d off to Walter, let's see what *he* thinks ?

--anders
Apr 14 2005
prev sibling parent reply Dejan Lekic <leka entropy.tmok.com> writes:
I think _all standard_ types, namespaces, classes and methods should be
lowercased. Why? I would think of it as "diplomatic" decision... See, a lot
of JAVA developers (99% of them) and some young C++ developers too (who
follow their professor lead, or similar) would very much likely use your
naming scheme. Some other, that did years of C, lisp, BASH (...) coding for
years would inherently use everything lowercased.

much likely be very happy to see var_names, MethodNames, ClassNames,
NamespaceNames etc.
If my opinion counts - everything, standard, should be lowercased. That
would be pure democratic solution. Personally, it's very hard for someone
like me to switch from MethodNames to methodNames and variable_names to
variableNames ... Especially if I have to write code in N languages
everyday (that means another, different code-style for writing D code) .
Mixing my own style, and default D style is painfull.
-- 
...........
Dejan Lekic
  http://dejan.lekic.org
Apr 13 2005
parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dejan Lekic schrieb am Wed, 13 Apr 2005 22:33:32 +0200:

 If my opinion counts - everything, standard, should be lowercased. That
 would be pure democratic solution. Personally, it's very hard for someone
 like me to switch from MethodNames to methodNames and variable_names to
 variableNames ... Especially if I have to write code in N languages
 everyday (that means another, different code-style for writing D code) .








-----BEGIN PGP SIGNATURE-----

iD8DBQFCXYuK3w+/yD4P9tIRAnVAAJ9zTBVwpHS51FbrUI+9HYnoR/xwKwCfeRxa
kdhDkz7EnseavyQnpmcM314=
=vtI3
-----END PGP SIGNATURE-----
Apr 13 2005