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

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

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 ?

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

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.
C++, Smalltalk, Modula-3, Pascal, C#, Ada, VisualBASIC developers will very
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

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

#       SET Tester TO 2
#         PERFORM UNTIL Tester >= TestValue
#           DIVIDE TestValue BY Tester GIVING A



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

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

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 ?

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