> While making dmgc.lib, I found this error ".size property is deprecated,
use
> .sizeof" here:
>
> testgc.d(304)
> gc.d(43)
> gcx.d(170)
> gcx.d(632)
> gcx.d(767)
> gcx.d(865)
> gcx.d(868)
> gcx.d(887)
> gcx.d(906)
> gcx.d(909)
> gcx.d(930)
> gcx.d(1169)
> gcx.d(1177)
> gcx.d(1187)
> gcx.d(1199)
> gcx.d(2020)
> gcx.d(2025)
> gcbits.d(38)
> gcbits.d(46)
> gcbits.d(118)
> gcbits.d(128)

Oops. I'll fix it.

Arcane Jill wrote:
> In article <cbc8jd$hbi$1@digitaldaemon.com>, Hauke Duden says...
> 
> 
>>lots of good stuff.
> 
> 
> Yeah, I guess I can't argue with any of that.
> 
> 
> 
>>Peter Wood suggested in another post to instead create a new property with a different name. What do you think about that? Something like "maxValid" perhaps?
> 
> 
> Well, it's possible, but on the whole I think I'd rather drop the idea
> altogether. The maximum Unicode codepoint is a manifest constant which could
> simply appear in an include file somewhere. (Er, I meant module). And the
> maximum legal value in a char is something you wouldn't ever really need to know
> unless you were writing UTF-8 translation routines (since anything else can rely
> on std.utf).
> 
> So - hey - it was a thought, but probably in the end not a very good one. I
> withdraw the suggestion.
> 
> Arcane Jill


Maybe this concept would be better suited for inclusion in a module (such as std.utf) as constants...

const char max_valid_char = 0xF8;
const dchar max_valid_dchar = 0x0010FFFF;
const wchar max_valid_wchar = 0xFFFF;


Just an idea.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Carlos Santander B. wrote:
<snip>
> [file t\a\m2.d]
> module t.a.m2;
> import t.a.m1;
> --
> 
> dmd -c m2
> Error: Error reading file 't\a\m1.d'

That's always been the case AFAIS.  Imports are relative to the current path, the path specified in a -I switch or (I think) in sc.ini or somewhere.

But yes, it would be handy if a module declaration climbed up the directory structure like that.  Logically, the module name indicates that the root of the hierarchy is a few levels up, and so this ought to be taken as the root of the hierarchy.

> (also notice no file or line number info)

Apparently this is part of the process of reading the imported module, rather than that of interpreting the import directive.  But yes, you have a point.

And if only the compiler were written in D, it would have a more specific error than "Error reading file"....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Walter wrote:

> "Sigbjørn Lund Olsen" <sigbjorn@lundolsen.net> wrote in message
> news:cbcu2i$1k0s$1@digitaldaemon.com...
> 
>>Matthew wrote:
>>
>>>fwiw, my (wasted) vote is that the bit type dies
>>
>>Agreed. Nice idea, but not quite the thing in real life. Kill bit, and
>>replace with a library implementation in Phobos. There, I've said my
>>bit, and shall forever stay silent.
> 
> 
> A bit drastic, don't you think?

I was feeling tarantinoesque; Kill Bit Vol. 2, and all that ;-)

Cheers,
Sigbjørn Lund Olsen

(This is getting rather bitiful)

How could I pass the arguments from one variadic function to another?  I think what I implemented for DLI is just about ideal engineering:

   // part of object.d
   struct generic
   {
       TypeInfo type;
       void *data;
   };

   void foo (generic [] args...);

   void bar (generic [] args...)
   {
       // pass on the arguments
       foo (args...);

       // create our own argument list
       int [1] arg;
       generic [1] arglist;

       arg [0] = 4;
       arglist [0].type = typeof (int);
       arglist [0].data = &arg [0];

       foo (arg...);
   }

This is also calling convention neutral.  The way you have it, you'd generate _arguments when the calling convention is D but not otherwise because there's no way to differentiate a safe variadic from an unsafe variadic based on the declaration.

You can implement this functionality using your style by pairing all variadic functions with a C-style "v" function and doing some painful array generation for argptr, but the questions remain: Which is cleaner?  Which modifies the language the least?  Which gives the most flexibility at the least complexity to the user?

Burton Radons wrote:

> How could I pass the arguments from one variadic function to another?  I think what I implemented for DLI is just about ideal engineering:
<snip>

You could define an alternative version of the function, which takes _argptr and _arguments as parameters.  Indeed, you might as well define the variadic function as a wrapper for the _argptr/_arguments version.

But this does seem a step back from C, which had only one thing to pass rather than two - a va_list.  I guess the (_argptr, _arguments) tuple ought to've been made a struct.

But D's variadicity support could be improved still, by allowing ... itself to be passed as a function parameter.  Then you could do:

	void qwert(int yuiop, ...) {
		asdfg(...);
	}

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <cbf00t$1ku9$1@digitaldaemon.com>, Burton Radons says...

>You can implement this functionality using your style by pairing all variadic functions with a C-style "v" function and doing some painful array generation for argptr, but the questions remain: Which is cleaner?
>  Which modifies the language the least?  Which gives the most
>flexibility at the least complexity to the user?

Since D is lacking this kind of functionality (unless I'm mistaken), you could simply use arrays to handle variable arguments instead.

>alias void*[TypeInfo] VarArgs;
>
>import someotherlib;
>void foo(VarArgs args){
>    someotherlib.bar(args);
>}

Granted, this would be better served by being able to create associative arrays on-the-fly, which isn't supported yet:

>foo([typeid(MyObj):new MyObj(),typeid(d_time):d_time.init]);

So to side-step this, you could just roll a single varadic helper function to create those arrays for you.

>foo(VarArgBuilder(new MyObj(),d_time.init));

"Burton Radons" <burton-radons@shaw.ca> wrote in message news:cbf00t$1ku9$1@digitaldaemon.com...
> How could I pass the arguments from one variadic function to another?

Pass the _arguments[] and _argptr.

> I think what I implemented for DLI is just about ideal engineering:
>
>     // part of object.d
>     struct generic
>     {
>         TypeInfo type;
>         void *data;
>     };
>
>     void foo (generic [] args...);
>
>     void bar (generic [] args...)
>     {
>         // pass on the arguments
>         foo (args...);
>
>         // create our own argument list
>         int [1] arg;
>         generic [1] arglist;
>
>         arg [0] = 4;
>         arglist [0].type = typeof (int);
>         arglist [0].data = &arg [0];
>
>         foo (arg...);
>     }
>
> This is also calling convention neutral.  The way you have it, you'd generate _arguments when the calling convention is D but not otherwise because there's no way to differentiate a safe variadic from an unsafe variadic based on the declaration.
>
> You can implement this functionality using your style by pairing all
> variadic functions with a C-style "v" function and doing some painful
> array generation for argptr, but the questions remain: Which is cleaner?
>   Which modifies the language the least?  Which gives the most
> flexibility at the least complexity to the user?

Your approach has a lot of merit. It consumes a little more space and runtime, though. It's also pretty simple to write a function to transform (_arguments, _argptr) into a generic array; Ivan Senji has done so in this thread. (It's not necessary to pair functions, the TypeInfo.tsize() will serve.) In fact, I should probably add that function to Phobos.