Thread overview
Instead of a preprocessor...
Mar 04, 2005
Derek Parnell
March 04, 2005
First, I'll just give a bit of background on myself, so you can understand where I'm coming from.

I've only been programming since I was eleven - but, mind you, I'm nineteen now.  I started with QuickBASIC, and a bit later started linking in assembly code.

In any case, I've only worked with C for a few years; I'm not a "bigwig" like many of you are.  And, for the past couple years, I've been the lead developer of some open source PHP software which is growing (imho) quite well in popularity (recently mentioned in a popular UK magazine, but still fairly small...)

My point is, while I have submitted patches to Mozilla, I've never really been involved in a large scale C/C++ project... however, the main thing I dislike about many larger projects is simple:

I think the configure scripts most of them use are horribly inefficient.

As such, many of the things D is doing excite me; so many greatly reduce the need of such an annoying and, after a few compilations, very tedious step.

What I'm trying to ramble on to ask is simple: there are some aspects I *don't* see D completely replacing, and without a preprocessor this simply leaves holes.  Specifically:

  - modules/includes which don't exist on one platform or from one compiler vendor.
  - functions or similar not made available as above.
  - more specifically, differences and variations between the many Unix, Linux, and similar distributions.

Now, I know I've seen responses to these, so let me cover what I think might be the response, and please read these as questions not assertions:

  - versioning, in its current state, doesn't allow for this and it seems impractical to add a version for every little thing.
  - as specific as a specification may be, compilers will still have bugs and this will fall upon the developers to handle and support.
  - if D were more popular, phobos might not be totally in-sync between vendors, etc.

Basically, what I'm looking for is something like HAVE_TEMPNAM.  More specifically, a way to (most desirable with "version") check if a function is defined at compile time.  I know, a simple question, but I'm horribly long winded.

One possible syntax, I suppose, would be:

version (function tempnam)

But that has all sorts of problems, and I'm sure better syntax could be thought up.  Regardless, it wouldn't be logical for this to affect the current file; rather, in anything imported.

Furthermore, I worry about the "version (Linux)" I see everywhere - but I know this has been mentioned.

I hope *someone* bothered to read at least more than half of this,
-[Unknown]
March 04, 2005
Unknown W. Brackets wrote:

> I think the configure scripts most of them use are horribly inefficient.

Autocrud isn't really meant to be effecient, but to be portable...

See http://sources.redhat.com/autobook/

>   - more specifically, differences and variations between the many Unix, Linux, and similar distributions.

This was why a POSIX® version was suggested, instead of making 5:

* std.c.linux.linux
* std.c.darwin.darwin
* std.c.cygwin.cygwin
* std.c.freebsd.freebsd
* std.c.solaris.solaris

But so far it hasn't been all that popular, except for with a few?

> Basically, what I'm looking for is something like HAVE_TEMPNAM.  More specifically, a way to (most desirable with "version") check if a function is defined at compile time.  I know, a simple question, but I'm horribly long winded.

The approach that autoconf/configure uses is to make a small sample
program that includes the header, and try to compile and link it.

If that works, it is available. If it doesn't, activate workaround...
In C, this is config.h with #define. In D, could be a version= module?

> Furthermore, I worry about the "version (Linux)" I see everywhere - but I know this has been mentioned.

It's "version(linux)", to boot. With a lower case. :-P

The current version of the "reference" compiler, DMD, does not make
any attempts to support other platforms than Win32 and Linux X86...


I'll try to whip up what std/c/posix/posix.d would look like.
(probably by doing a merge of linux/linux.d and darwin/darwin.d,
and factor out the bits that they have in common and import the rest)

"-version=Posix" can be set on command-line meanwhile, like in Mango.
http://svn.dsource.org/svn/projects/mango/trunk/

--anders
March 04, 2005
Anders F Björklund,

As much as it may not be written to be efficient, that doesn't stop it from bothering me; it just seems like there are so many better ways...

I've looked at autoconf's methods, and they are what appaul me.  The amount of piping that goes on there is similar to the CGI method of Perl, PHP, and other web scripting - slow.  The other method, SAPI, is several times more efficient and can make things so much more possible.

With modules instead of hacky-feeling includes, D already makes this so much better and makes it possible to make compilation so much faster..

It just seems like there's a better way.... even than having an import config; that defines versions...

-[Unknown]


> Autocrud isn't really meant to be effecient, but to be portable...
> 
> See http://sources.redhat.com/autobook/


> The approach that autoconf/configure uses is to make a small sample
> program that includes the header, and try to compile and link it.
> 
> If that works, it is available. If it doesn't, activate workaround...
> In C, this is config.h with #define. In D, could be a version= module?
March 04, 2005
On Fri, 04 Mar 2005 08:56:14 +0100, Anders F Björklund wrote:


[snip]

> "-version=Posix" can be set on command-line meanwhile, like in Mango.

And for what its worth, my Build tool automatically sets -version=Posix if 'linux', 'darwin', 'Unix', or 'unix' is already set.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
4/03/2005 7:11:12 PM
March 04, 2005
Unknown W. Brackets wrote:

> With modules instead of hacky-feeling includes, D already makes this so much better and makes it possible to make compilation so much faster..
> 
> It just seems like there's a better way.... even than having an import config; that defines versions...

No argument there, and if it can replace the current workarounds : Yay!

mango.io.FileConduit:
>         version(linux) {
>         private import std.c.linux.linux;
>         alias std.c.linux.linux posix;
>         }
>         version(darwin) {
>         private import std.c.darwin.darwin;
>         alias std.c.darwin.darwin posix;
>         }

You'll probably see how it gets tedious to add 3 new platforms here ?

--anders