November 29, 2006
Anders F Björklund wrote:
> Chris Miller wrote:
> 
>> I like how D simplified this. It makes it much easier to do a general  parse of a source file without having to follow imports (which can be a  pain - e.g. several import dirs).
> 
> Simpler for the parser, I guess. But harder for the user, unfortunately.
> (since you have learn and make changes with more than one tool/language)
> But once one gets the build system in place, it should be all good...
> (i.e. instead of doing a config.h file, it can generate a commandline)

I believe it is harder for the initial programmer, but much simpler for the maintenance programmer. Have you ever been faced with maintaining a piece of C code with complicated #if statements, and you have no idea if FOO is defined or not, or what it is #define'd to? You've got to look at the module, the freakin' command line, the makefile, the #include path, every freakin' #include file, which of course use more #if's to optionally #include other freakin' files, and such #defines are even created using freakin' complicated token pasting!

Not allowing versions from one module to affect imports of it is a major boon to maintenance and discoverability of the code. It requires rethinking of how to organize building multiple versions from the same source. The best way I've found is to abstract the version differences into an API, and then have the different implementations of those APIs in different modules.
November 29, 2006
Anders F Björklund wrote:
> Walter Bright wrote:
> 
>>> So are you saying that we should *not* write
>>> "version(whatever) {} else" for D's #ifndef ?
>>
>> No, I'm saying one should not have properties that contain a negative, such as NOTMAIN or NOALIAS.
> 
> Agreed. It's better to pick the positive - if possible.

A couple of times I've been briefly stumped trying to come up with the right positive, but every time I was able to figure one out, and was pleasantly surprised to discover that it was worth it - the code is more readable.

Note that I mean positive in the logic sense, not in the "think good thoughts" sense.
November 29, 2006
Walter Bright wrote:

> I believe it is harder for the initial programmer, but much simpler for the maintenance programmer. Have you ever been faced with maintaining a piece of C code with complicated #if statements, and you have no idea if FOO is defined or not, or what it is #define'd to? You've got to look at the module, the freakin' command line, the makefile, the #include path, every freakin' #include file, which of course use more #if's to optionally #include other freakin' files, and such #defines are even created using freakin' complicated token pasting!

Yes I have, but it also allows for writing very portable code.
I've also done Java code that did not have macro facilities,
so even if it only ran on a handful setups it still had to use
code generators or force a very specific setup upon everybody.

I'm sure that things would be different if writing new D code,
and not just porting C/C++ stuff over - which is where I usually
run into wanting a #ifndef or other similar predefined versions.
I don't *want* to change the macros, since they're in the API...


BTW: For compatibility with Windows (of wxD) I had to rewrite the sh scripts as programs, so now it should be working on Windows and Unix.
They will check the current setup, and output the -version/-fversion.
(it writes a text file or config.mak, to include into the Makefiles)
Not sure if it's easier there (compared to a module), but it works OK.
Latest version will even write the library pragmas for Build to use...
Will be good if you don't want to use the GNU toolchain (i.e. MinGW) ?
(as the original version just used wx-config/pkg-config and backticks)

--anders
November 29, 2006
Anders F Björklund wrote:
> 
> I'm sure that things would be different if writing new D code,
> and not just porting C/C++ stuff over - which is where I usually
> run into wanting a #ifndef or other similar predefined versions.
> I don't *want* to change the macros, since they're in the API...

Doesn't 'static if' fit the bill here?  It supports full expression logic and is evaluated at compile-time, just like 'version'.  In instances where code is automatically translated to D, I'd probably just convert #defines to enum or const values and use 'static if' in place of #if.  For manual conversions though, I think a hybrid approach is best.  For example, in converting POSIX headers to D I've noticed that nearly all the #if blocks are for selecting features determined at an OS level--the presence of conditions that may vary within an OS is actually pretty rare.  That being the case, it seems reasonable to either version by OS name or set up more granular version identifiers and pre-select the appropriate ones in a makefile or global compiler parameter variable.


Sean
November 29, 2006
Sean Kelly wrote:

>> I'm sure that things would be different if writing new D code,
>> and not just porting C/C++ stuff over - which is where I usually
>> run into wanting a #ifndef or other similar predefined versions.
>> I don't *want* to change the macros, since they're in the API...
> 
> Doesn't 'static if' fit the bill here?

It probably does. Just wasn't around when I started with D,
so I haven't really gotten used to using it instead... :-)

--anders
November 30, 2006
Tomas Lindquist Olsen wrote:

> I have committed the version I posted to SVN with Anders's patch applied.
> 
> Lets get MinWin back on track :)

Great!

> If there's anything let me know. I wont be the most active developer from day 1, I still need to read alot of the source + understand it, etc, but I will do my best to administer the project. At least now it can move on...

DSource seems to be down at the moment, but I notice from the source I downloaded from your site that the implementation of MultiDelegate, used for notifications in the library, is ripe for Tuple-fication.  Lot's o templates there overloaded on number of arguments.

--bb
November 30, 2006
Bill Baxter wrote:
> DSource seems to be down at the moment, but I notice from the source I downloaded from your site that the implementation of MultiDelegate, used for notifications in the library, is ripe for Tuple-fication.  Lot's o templates there overloaded on number of arguments.
> 
> --bb

Yup I noticed that as well, and SVN trunk now uses variadic templates
December 01, 2006
Tomas Lindquist Olsen wrote:
> Bill Baxter wrote:
> 
>> DSource seems to be down at the moment, but I notice from the source I downloaded from your site that the implementation of MultiDelegate, used for notifications in the library, is ripe for Tuple-fication.  Lot's o templates there overloaded on number of arguments.
>>
>> --bb
> 
> 
> Yup I noticed that as well, and SVN trunk now uses variadic templates

Cool.

Probably worth discussing whether MultiDelegate is the right way to do it, considering how similar it is to std.signals.Signal.

It seems to lack the safe disconnection mechanism in Signal.
But it adds a boolean return value.

--bb
December 01, 2006
From minwin/todo:
* mswindows
 - A vs W for string inputs - convert to wchar

It seems that sticking with char[] and only doing the toUTF16z conversions under the hood is the most feasible.

I have attached a patch (made with tortoiseSVN) that makes minwin/button.d work with unicode. It adds a few W functions to minwin/mswindows.d as well.

Is there a better way?
Feedback is much appreciated, I think MinWin should support unicode
properly, and it's not that much work with this approach.

Does unicode work with GTK/Motif?

-- Tomas



December 01, 2006
Walter Bright wrote:
> Gregor Richards wrote:
>>>     version (NOTWINDOWS) => version (LINUX)
>> I hate to say this, but that example just plain stupid. All it will ever do is limit your code to work on only certain operating systems. That's hindering portability, and that's no good.
>>
>> As it turns out, it's often the case that such-and-such does work on every sane operating system, and therefore version (!Windows) makes sense.
> 
> I've seen a lot of code that did that, and it was nearly always broken. That's one motivation for operating system versions should be positives, not "this is for not windows" or "this is for not linux". Such fundamentally are wrong, and will bite you or the maintainer sooner or later.

There's a horrible effect in C++ Windows where there's lots of code which has #ifdef __MSVC__, even though it works on many other compilers.
So vendors like CodePlay and Metrowerks fraudulently define __MSVC__.
I hope we can avoid this in D.
I've already seen some uses of
DigitalMars_Inline_Asm
because GDC doesn't support the full set of x86 opcodes. I think failure to implement the spec should always be tested with a positive. Certainly code should never have a list of compilers which meet the spec!

And if a vendor knows that they're not implementing part of the spec, they should provide an identifier indicating that fact. That way, the vendor can fix the problem without breaking existing code.