On Fri, 10 Jun 2005 00:06:21 -0700, Walter wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:15iyeaoc4m2un$.k32eg0afi011.dlg@40tude.net...
>> Personally I don't think there is a solution, so I'm resigned to using
> some
>> other tool to develop with from now on. If someone comes up with a great way of achieving the 'grand' aim of only maintaining one set of source files per application, just let us know. Currently, D alone is not enough; it falls short of ever being able to do this, unlike C and C++. In short,
> I
>> need an additional tool so I can reduce my development costs.
> 
> The C and C++ preprocessor cannot do this in the *general* case. The reason is because the preprocessor works on preprocessor tokens, not on text. If any new tokens were added, then the older preprocessors are obligated to fail, even on the false conditionals.

Yes, I understand this. I have a general macro processor that I've written and I'm currently porting it to D. It is able to handle the general case. Once I've completed the port I'll add it to DSource for review, etc...


-- 
Derek Parnell
Melbourne, Australia
10/06/2005 8:12:46 PM

Walter wrote:

>>Could we please at least have an answer about these?
>>
>>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170
>>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3173
> 
> The problem is I haven't spent the time thinking about those yet. Other
> stuff always intrudes.

The urgency depends on whether we want the people learning D now
to use readf/writef, or use the "good ole" scanf/printf instead ?

If we want them to stop using the C functions before there is
too much to clean up (there more or less is already), then it
should be addressed as soon as possible. Just move "printf" back
to std.c.stdio, where it belongs. Old code can just import that ?

If not, then we continue using implicit "printf" just like before...
Sooner or later the situation would need to get cleaned up, though.

--anders

Anders F Björklund wrote:
<snip>
> The urgency depends on whether we want the people learning D now
> to use readf/writef, or use the "good ole" scanf/printf instead ?
> 
> If we want them to stop using the C functions before there is
> too much to clean up (there more or less is already), then it
> should be addressed as soon as possible. Just move "printf" back
> to std.c.stdio, where it belongs. Old code can just import that ?
> 
> If not, then we continue using implicit "printf" just like before...
> Sooner or later the situation would need to get cleaned up, though.

Along with the claim on ctod.html that "printf rules", as if writef doesn't, and the similar statement in the FAQ.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David L  Davis schrieb am Wed, 8 Jun 2005 23:35:19 +0000 (UTC):
> In article <d87tom$2sap$2@digitaldaemon.com>, Walter says...
>>
>>
>>"David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:d87sok$2rff$1@digitaldaemon.com...
>>> In the dmd v0.126 changlog it states: "delete aa[key] is now deprecated,
>>use
>>> aa.remove(key) instead."
>>>
>>> It's a little thing, but the D compiler doesn't throw a "deprecated"
>>message for
>>> code that's using the "delete aa[key]" as it should when the "-d" switch
>>is not
>>> being used. Just thought you should know.
>>
>>I thought it did, and in fact it has on my usages of delete aa[key].
>>
>>
>
> Ok, "the proof is in the pudding." Here's the code I test compiled without an error message... so either I misunderstood the changlog, or the version of dmd v0.126 I've downloaded is different from yours. <g>
>
> # // assocarray.d
> # // Updated to changes done in D v0.126:
> # // "delete aa[key] is now deprecated, use aa.remove(key) instead"
> # private import std.stdio;
> #
> # alias char[] string;
> #
> #  void main()
> #  {
> #      string[ string ] arr;
> #
> #      // before adding "key"
> #      writefln( "With the associative array empty, does \"key\" exist? %s",
> #                ( isset( arr, "key" ) ? "yes" : "no" ) );
> #      writefln();
> #
> #      writefln( "Now adding entries \"key\" and \"key2\"" );
> #      arr[ "key"  ] = "added a key";
> #      arr[ "key2" ] = "added another key";
> #      writefln();
> #
> #      writefln( "The associative array now has %d entries listed below.",
> #                 arr.length );
> #      displayEntries( arr );
> #      writefln();
> #
> #      // after adding "keys"
> #      writefln( "After adding the keys, does \"key\" exist? %s",
> #                ( isset( arr, "key" ) ? "yes" : "no" ) );
> #      writefln();
> #
> #      writefln( "Now removing \"key2\"..." );
> #      remove( arr, "key2" );
> #      // after removing "key2"
> #      writefln( "After removing, does \"key2\" now exist? %s",
> #                ( isset( arr, "key2" ) ? "yes" : "no" ) );
> #      writefln( "The associative array now has %d entries.", arr.length );
> #      writefln();
> #
> #      writefln( "Before ending display all remaining keys..." );
> #      displayEntries( arr );
> #
> # } // end void main()
> #
> # bool isset( in string[ string ] arr, in char[] sKey )
> # {
> #     if ( ( sKey in arr ) != null )
> #         return true;
> #     else
> #         return false;
> # }
> #
> # void remove( inout string[ string ] arr, in char[] sKey )
> # {
> #     delete arr[ sKey ];
> #     //arr.remove( sKey );
> # }
> #
> # void removeall( inout string[ string ] arr )
> # {
> #     foreach( char[] sKey; arr.keys )
> #         delete arr[ sKey ];
> #         //arr.remove( sKey );
> # }
> #
> # void displayEntries( in string[ string ] arr )
> # {
> #     foreach( char[] sKey, char[] sValue; arr )
> #         writefln( "sKey=\"%s\", sValue=\"%s\"", sKey, sValue );
> # }

Added to DStress as http://dstress.kuehne.cn/nocompile/d/delete_09_A.d http://dstress.kuehne.cn/nocompile/d/delete_09_B.d http://dstress.kuehne.cn/nocompile/d/delete_09_C.d http://dstress.kuehne.cn/nocompile/d/delete_09_D.d

Thomas


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

iD8DBQFCqeZe3w+/yD4P9tIRAn6OAKC48V2uYmG+tgaJ6UhSW8MjDgb0EwCbB3ab
XHyFZiT19rrSfSR7H0uA9dw=
=YyNK
-----END PGP SIGNATURE-----

"Anders F Björklund" <afb@algonet.se> wrote in message news:d8bvps$12nq$1@digitaldaemon.com...
> The urgency depends on whether we want the people learning D now to use readf/writef, or use the "good ole" scanf/printf instead ?

I don't think it is urgent, for the simple reason that support for C functions, which include printf, is not going away in D.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:d8c66p$18cm$1@digitaldaemon.com...
> Along with the claim on ctod.html that "printf rules", as if writef doesn't, and the similar statement in the FAQ.

LOL. Thanks for pointing out the anachronisms in the doc, I keep stumbling across more myself.

"Derek Parnell" <derek@psych.ward> wrote in message news:1ug68xy67nop6$.4jufrs60obd0.dlg@40tude.net...
> Yes, I understand this. I have a general macro processor that I've written and I'm currently porting it to D. It is able to handle the general case. Once I've completed the port I'll add it to DSource for review, etc...

I think that'll be cool.

P.S. I never understood why the C preprocessor was redefined from being a text preprocessor to a token preprocessor. I see no advantage to the latter, and it makes for a lot of mess in the implementation.

These issues NEVER go away.  Unless this class of problem is dealt with cleanly, it will hang on forever.  There will always be features that are supported by one compiler, and not by another.  You can't even deal with it with a decree from the government.  (Ada tried.  It didn't work.)

Some people have gone as far as to write preprocessors just so that they only need to maintain one file of code for their program.

All that said, exactly HOW it should be dealt with isn't clear to me.  C/C++ handles it by not caring about what's in the paths through the code that are #ifdef'd out.  I understand the good reasons why this is not the preferred choice...but that doesn't say how it SHOULD be dealt with.  Particularly when something as linguistically basic as !is gets involved.  Up until that was defined, it was a clear grammatical error.

The only thing that occurred to me is to put a "not parseable" flag on a block.  I don't need to say why that's a bad idea, but it might be the best alternative.  (OTOH, it would need to be a distinctive flag, and not easily confused with something that might mean something else.  All that occurs to me is:
<unparseable>{....}</unparseable>
And it would be an error to omit the closing tag, or for the tag to be used outside a version statement.

clayasaurus wrote:
> These issues will go away once GDC is up to date and/or D reaches 1.0, so why worry and code work-arounds when you can just relax and wait it out?
> 
> 
> Derek Parnell wrote:
> 
>> On Wed, 8 Jun 2005 09:51:26 -0700, Walter wrote:
>>
>>
>>> "Derek Parnell" <derek@psych.ward> wrote in message
>>> news:zu8pxspfqpou$.j798zboqpqeo$.dlg@40tude.net...
>>>
>>>> WTF do I have to code so I only have to support one source file for
>>>> multiple compilers? I don't really want one version of the Build
>>>> application source for the GDC compiler and another set of source files
>>>
>>>
>>> for
>>>
>>>> the DigitalMars compiler. At this stage, I'm going to have to revert to a
>>>> macro preprocessor again! I'm sure that is not what Walter envisioned his
>>>> D-isciples doing.
>>>
>>>
>>> Compiling with -d will allow the use of deprecated features.
>>
>>
>>
>> That IS NOT the problem, Walter.
>> I don't want to use deprecated features.
>> I want to use the current features, not old ones that are going away
>> someday. Reasonable, no?
>>
>> The problem is, that not all compilers are at the same release level, or
>> will share the same features. So if one wants one's product to be to be
>> supported with multiple compilers, how does one code their source files?
>>
> 

Well, that's similar to how MySQL handles this.

Basically, they have you use a specially formatted comment, of this syntax:

/*!40001 ... */

Which means, only execute the code inside the ... if the version number is equal to or greater than the number in the comment.

The downside, of course, is that they neglected to add a way to do the opposite - include code for versions OLDER than that.

The advantage is that any D compiler will handle comments, so if dmd 0.125 sees:

if (abc /+(dmd_126) !is /* +/ !== /+(dmd_126) */ +/ xyz)

Well, I think you get my point.  The clear downsides to this are that it makes it a lot more complicated to parse, both for the compiler and much more importantly for code editing and analysis tools, and it just plain looks ugly.

I like version a lot myself.  It may not solve every possible problem, but nothing does.

-[Unknown]


> These issues NEVER go away.  Unless this class of problem is dealt with cleanly, it will hang on forever.  There will always be features that are supported by one compiler, and not by another.  You can't even deal with it with a decree from the government.  (Ada tried.  It didn't work.)
> 
> Some people have gone as far as to write preprocessors just so that they only need to maintain one file of code for their program.
> 
> All that said, exactly HOW it should be dealt with isn't clear to me.  C/C++ handles it by not caring about what's in the paths through the code that are #ifdef'd out.  I understand the good reasons why this is not the preferred choice...but that doesn't say how it SHOULD be dealt with.  Particularly when something as linguistically basic as !is gets involved.  Up until that was defined, it was a clear grammatical error.
> 
> The only thing that occurred to me is to put a "not parseable" flag on a block.  I don't need to say why that's a bad idea, but it might be the best alternative.  (OTOH, it would need to be a distinctive flag, and not easily confused with something that might mean something else.  All that occurs to me is:
> <unparseable>{....}</unparseable>
> And it would be an error to omit the closing tag, or for the tag to be used outside a version statement.

On Sun, 12 Jun 2005 22:55:20 -0700, Unknown W. Brackets wrote:

> Well, that's similar to how MySQL handles this.
> 
> Basically, they have you use a specially formatted comment, of this syntax:
> 
> /*!40001 ... */
> 
> Which means, only execute the code inside the ... if the version number is equal to or greater than the number in the comment.
> 
> The downside, of course, is that they neglected to add a way to do the opposite - include code for versions OLDER than that.
> 
> The advantage is that any D compiler will handle comments, so if dmd 0.125 sees:
> 
> if (abc /+(dmd_126) !is /* +/ !== /+(dmd_126) */ +/ xyz)

Well like I said, I no longer think that this problem is in the compiler's domain. I'm now going to handle it with an macro processor tool.

For example, in a file called dmdversion.mac I'll have something like ...

 @if [[$dmd]] >= "000.126"
 @set $aint = !is
 @else
 @set $aint = !==
 @endif

And in my source code file I'll have this sort of thing...
 @include dmdversion.mac
 . . .
 if (abc [[$aint]] xyz)

And then compile it with the command line ...

  build source.mac -set$dmd=000.126


-- 
Derek Parnell
Melbourne, Australia
13/06/2005 7:22:35 PM