View mode: basic / threaded / horizontal-split · Log in · Help
November 29, 2006
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
minwin unicode
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
Re: minwin
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.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home