Anders F Björklund wrote:
> Sean Kelly wrote:
> 
>>> And say 10% varies and 90% is the same as the standard, isn't it better
>>> then to "reuse" those parts that are the same and only conditionalize
>>> the parts that actually differ ? Instead of copy/paste the whole thing ?
>>
>> This is what I've been doing in Ares, though it remains to be seen whether this is the correct approach or not.  I've been sticking to the 'required' bits and any additional features needed for D and so far probably 50% of it is platform-specific. 
> 
> Does Ares use any auto-detection or auto-generation for the headers ?

Nope.  I've done everything manually so far (though Kashia submitted the darwin bits).  This is obviously a mainenance concern for long-term support, but if it comes to that I'll approach it as I've done for DMD updates: diff the new Linux include directory against the old one and determine what needs fixing.  Automated processing would be nice, but I haven't explored that option yet.  I'll also admit to being somewhat of a novice with things like 'configure' so it didn't occur to me to use them.


Sean

pragma wrote:

> Walter, I mean no disrespect here, but I simply must ask: Are you talking about
> a literal interpretation of version() and debug(), including the lack of an
> #ifndef equivalent?  
> 
> Like this:
> 
> #ifdef FOOBAR
> #else
> /*** code ***/
> #endif
> 
> Or like this (using ifndef):
> 
> #ifndef FOOBAR
> /*** code ***/
> #endif
> 
> I don't think that version() and debug() need to be tangled up with all kinds of
> boolean expressions, but maybe a short-and-sweet concession to allow an
> equivalent to #ifndef is in order?  Sure its just "one line more readable" but
> it *is* more readable after all. 

Consider another perspective: when a version of the code is being built, one thinks about a version being build, not a "not version". If you find that you're writing:

version (FOOBAR)
else
{
	...
}

I suggest that perhaps FOOBAR is the wrong name for the version being compiled. For example, I would red flag code that looked like:

version (Windows)
else
{
	...
}

I also have a particular dislike for the execrable double negative style often seen in C:

#ifndef NO_FOO
...
#endif

There is some psychobabble research on this, suggesting that people tend to skip nots, and even more often miss double negatives. I know that in airplane pilot jargon, considerable effort has been made to purge negations and replace them with positive statements, as they are less prone to misinterpretation.

Some more examples:

1) Don't build a "NOTFULL" version, build a "DEMO" version.
2) Don't build a "NOTDEMO" version, build a "FULL" version.
3) Don't build a "NOHARDTABS" version, build a "SOFTTABS" version.

etc. If there are some specifics cases you feel just don't fit with this, can you post them?

If you are writing a program that will only work on Windows, it would be necessary to use this...

version (Windows)
else
{
    static assert (0);
}

Same with any other requirements.

I do agree with you about the double negative style though.

> etc. If there are some specifics cases you feel just don't fit with this, can you post them?

Sean Kelly wrote:
> Walter Bright wrote:
>> <flame on>
>> C++ was supposed to reduce the use of the preprocessor. Boost is peer-reviewed and written by the best and the brightest C++ developers. So why does even the simplest Boost code *heavily* rely on complex, obtuse, layer after layer of preprocessor macros?
>> <flame off>
> 
> It's interesting to see how Boost components have evolved over time. For example, the implementation of shared_ptr used to be extremely straightforward--it comprised maybe 100 lines of code with nary a macro to be seen.  Now it's spread across multiple files, contains dense and complicated code, and has more features than I care to list.  In some respects this reminds me of what I call the "Microsoft Word" syndrome. That being that everyone wants a very small subset of features in a product, but all of those people want *different* features.

Frankly, I find boost to be unusable. If you're lucky, it works right out of the box. The slightest thing going wrong, however, and you're faced with an incomprehensible error message, #include's spread over several directories, the layers of macros, layers of templates, and no clue as to what is relevant and what is puffery.

> Another factor may be that while it's quite difficult to write an easily usable library, it's far more difficult to do so using simple, straightforward code or to maintain this simplicity across maintenance cycles.  shared_ptr started out clean and compact, but it certainly didn't stay that way.  Perhaps there's simply more pressure to get improvements done than to do so in a clearly readable manner, or perhaps it's an issue of too many fingers spoiling the soup?  I suppose it also doesn't help that the best and brightest may occasionally lack perspective on what's understandable to the average person, or perhaps there's simply no perceived need for users to be able to make sense of the code.

True genius is being able to find the underlying simplicity of something. Anyone can make something complicated. It takes a genius to make something so simple that everyone else says "of course, why didn't I think of that myself?" An airplane, for example, is a simple and obvious device. But it took a (pair) of geniuses to figure that out.

Walter Bright wrote:
[...]
> In C and C++, I often see:
> 
>     #if !WIN32
> 
> when what is really meant is:
> 
>     #if linux
> 
> i.e. the former is almost always a bug waiting to happen (when someone tries to compile for a third operating system). Versions should be "this build is for this configuration" rather than "this build is not for that configuration."
> 

what about the case where feature A is incompatible with configuration B (example: this feature is usually part of the config but doesn't work under win32)

but then again I'd do this instead

version(WIN32)
{
	pragma(msg,">"__FILE__":" ~ itoa!(__LINE__) ~
	"Sorry this doesn't work with win32");
}
else
{
	// win32 incompatible code
}

Ameer Armaly wrote:
> One situation I can see where this kind of functionality could be useful is where you want the default compiled behavior to execute a given block of code, but with a given version switch you want it taken out.  Rather than wrapping your prefered behavior in a version block, or putting in an empty version block which raises all sorts of questions, you could just say "Unless a given version specifier is defined, do this." 

I understand that point of view, but I suggest instead thinking about the "default compiled behavior" as a "Feature", rather than a not "NotFeature". You can make it the default by putting:

	version = Feature;

at the top of the module.

Anders F Björklund wrote:

> But if I understand you correctly, it is *better* to do an "assert(0);"
> on those other systems than to try the generic code and hope it works ?
> I must say I prefer autotools then, even if they have their wrinkles.

Shipping production code for an OS that has never been even tried on that OS is not a good idea. In that case, having an assert in it *is* better because it's a red flag for the maintainer of that OS that he's got some work to do folding in new capability, and most importantly testing it.

I know from long and bitter experience that if you ship code that isn't tested, it's *guaranteed* to not work.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:e40g2t$2r6h$1@digitaldaemon.com...
> Ameer Armaly wrote:
>> One situation I can see where this kind of functionality could be useful is where you want the default compiled behavior to execute a given block of code, but with a given version switch you want it taken out.  Rather than wrapping your prefered behavior in a version block, or putting in an empty version block which raises all sorts of questions, you could just say "Unless a given version specifier is defined, do this."
>
> I understand that point of view, but I suggest instead thinking about the "default compiled behavior" as a "Feature", rather than a not "NotFeature". You can make it the default by putting:
>
> version = Feature;
>
> at the top of the module.
What if it were across multiple files, or some other particularly large but modular project; I'm not saying it couldn't be done, only that it looks bloated.  I agree with you that multiple bool operators might be pushing things a bit, but a simple not operator would IMO make things efficient enough to where the rest of that wouldn't matter as much.

Ameer Armaly wrote:
> What if it were across multiple files, or some other particularly large but modular project; I'm not saying it couldn't be done, only that it looks bloated.  I agree with you that multiple bool operators might be pushing things a bit, but a simple not operator would IMO make things efficient enough to where the rest of that wouldn't matter as much. 

For multiple files, the idea is to abstract the feature out into its own module rather than embedding it.

Walter Bright escribió:
> Ameer Armaly wrote:
>> What if it were across multiple files, or some other particularly large but modular project; I'm not saying it couldn't be done, only that it looks bloated.  I agree with you that multiple bool operators might be pushing things a bit, but a simple not operator would IMO make things efficient enough to where the rest of that wouldn't matter as much. 
> 
> For multiple files, the idea is to abstract the feature out into its own module rather than embedding it.

My 2 cents: it's not about being a good programming practice, it's about enough flexibility. I'm for the "version (!VERSION)". It'll not kill anyone though you can discourage the misuse of it.

JMHO

--
Tom;