The big change here is the revamping of the typeinfo system, and the addition of typesafe variadic functions. At last, we can now write a proper successor to printf!

Doing that is next on my list, as well as addressing the large backlog of phobos work and compiler bugs.

Barring a very, very, compelling case, this is it for 1.0 language features. There are a lot more things I want to do, but this has got to be enough for 1.0.

http://www.digitalmars.com/d/changelog.html

"Walter" <newshound@digitalmars.com> wrote in message news:cbb9sq$22qv$1@digitaldaemon.com...
> The big change here is the revamping of the typeinfo system, and the addition of typesafe variadic functions. At last, we can now write a
proper
> successor to printf!
>

Cool! But isn't this a little too messy?
It would be nice if _arguments were a struct and we could do:

if (_arguments[i].type == typeid(int))

{

printf("\t%d\n", *cast(int*)_arguments[i].value);

}

and avoid _argptr.

But even the way it is now it is GREAT :)


> Doing that is next on my list, as well as addressing the large backlog of phobos work and compiler bugs.
>
> Barring a very, very, compelling case, this is it for 1.0 language
features.
> There are a lot more things I want to do, but this has got to be enough
for
> 1.0.
>
> http://www.digitalmars.com/d/changelog.html
>
>
>

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cbbe11$2a32$1@digitaldaemon.com...
> Cool! But isn't this a little too messy?
> It would be nice if _arguments were a struct and we could do:
>
> if (_arguments[i].type == typeid(int))
>
> {
>
> printf("\t%d\n", *cast(int*)_arguments[i].value);
>
> }
>
> and avoid _argptr.
>
> But even the way it is now it is GREAT :)

You could write a function that would get the ith argument from _argptr given _arguments[], that'll give you most of what you want.

While _arguments[] won't work for C linkage functions, _argptr does, and even just having that makes doing C varargs significantly easier.

On Tue, 22 Jun 2004 23:54:21 -0700, Walter wrote:

> The big change here is the revamping of the typeinfo system, and the addition of typesafe variadic functions. At last, we can now write a proper successor to printf!
> 
> Doing that is next on my list, as well as addressing the large backlog of phobos work and compiler bugs.
> 
> Barring a very, very, compelling case, this is it for 1.0 language features. There are a lot more things I want to do, but this has got to be enough for 1.0.
> 
> http://www.digitalmars.com/d/changelog.html

I assume that these optional arguments are passed as 'in' rather than 'out' or 'inout'?

-- 
Derek
Melbourne, Australia

"Walter" <newshound@digitalmars.com> wrote in message news:cbbg9c$2dce$1@digitaldaemon.com...
>
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cbbe11$2a32$1@digitaldaemon.com...
> > Cool! But isn't this a little too messy?
> > It would be nice if _arguments were a struct and we could do:
> >
> > if (_arguments[i].type == typeid(int))
> >
> > {
> >
> > printf("\t%d\n", *cast(int*)_arguments[i].value);
> >
> > }
> >
> > and avoid _argptr.
> >
> > But even the way it is now it is GREAT :)
>
> You could write a function that would get the ith argument from _argptr given _arguments[], that'll give you most of what you want.

I did write it (actually a class, not a function) and using it looks really
nice;

 Arguments arg = new Arguments(_arguments,_argptr);
 for(int i=0; i<arg.length; i++)
 {
  if(arg.type(i)==typeid(int))
  {
   printf("Broj %d = %d\n",i,*cast(int*)arg.value(i));
  }
 }

> While _arguments[] won't work for C linkage functions, _argptr does, and even just having that makes doing C varargs significantly easier.

Yes i understand, but isn't most of the functions people write in D
D-functions
so having a standard way to help avoid having to calculate the adresses
manually
would be really nice.

Nice to see that multiple indices have already found their way into the language! Thanks!

There is a small typo in the changelog:
        http://www.digitalmars.com/d/changelog.html#new093
In the second point, it should 'opIndexAssign' instead of 'opIndexArray'

B.t.w: Maybe it should be noted very clearly that the changes may break existing code without clear warning: If you used the now deprecated opIndex(idx,value) for overloading the assignment, the compiler will complain only on usage of 'A[i] = b;' which might be very confusing to anyone who did not read the changelog carefully.




Walter wrote:

> The big change here is the revamping of the typeinfo system, and the addition of typesafe variadic functions. At last, we can now write a proper successor to printf!
> 
> Doing that is next on my list, as well as addressing the large backlog of phobos work and compiler bugs.
> 
> Barring a very, very, compelling case, this is it for 1.0 language features. There are a lot more things I want to do, but this has got to be enough for 1.0.
> 
> http://www.digitalmars.com/d/changelog.html

Walter wrote:

> The big change here is the revamping of the typeinfo system, and the
> addition of typesafe variadic functions. At last, we can now write a proper
> successor to printf!

Hmm....

> Doing that is next on my list, as well as addressing the large backlog of
> phobos work and compiler bugs.
<snip>

Addressing bugs tends to come first on my lists....

And would I be right to assume you're still trying to make up your mind which bit slicing approach to go for?  Maybe we should have a vote....

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 <cbbr47$2tbk$1@digitaldaemon.com>, Stewart Gordon says...
>
>And would I be right to assume you're still trying to make up your mind which bit slicing approach to go for?  Maybe we should have a vote....

My vote would go to (1) ABI consistency with other types. That necessarily implies copy-by-reference, and (therefore) bit-slicing only on byte boundaries. Exceptions should be thrown for bit-slicing on non-byte boundaries; Taking the address of an element of a bit-array should be a compile-time error.

But there are other alternatives, any of which I could be happy with. These include (but are probably not limited to):

(2) Copy-by-value slicing - this would allow you to maintain the ABI for slices
(but not for bit-pointers).

(3) Complete linguistic consistency with other types - this would require special structures for bit-slices and bit-pointers, thereby violating ABI consistency.

Either (2) or (3) would allow slicing on non-byte boundaries, and only (3) would
allow you to take the address of an element of a bit-array.

Arcane Jill

Hey, cool - you liked my char/wchar/dchar .init idea.

Well then, here's another mad idea, along the same lines:

char.max should be 0xF8, since any value above this is illegal in a valid UTF-8 stream.

dchar.max should be 0x0010FFFF, since any value above this is illegal in a valid UTF-32 stream (and is also not a valid Unicode codepoint).

wchar.max is fine where it is, since the upper limit of UTF-16 is, in fact, 0xFFFF.

Particuluarly for char, implementing these would strongly reinforce the idea that the character types store UTF-encodings ONLY. Anyone wondering why their Latin-1 character code is greater than char.max will be forced to conclude that chars are not intended to store Latin-1 (which is true - they should only store UTF-8).

Arcane Jill

Arcane Jill wrote:
> Hey, cool - you liked my char/wchar/dchar .init idea.
> 
> Well then, here's another mad idea, along the same lines:
> 
> char.max should be 0xF8, since any value above this is illegal in a valid UTF-8
> stream.
> 
> dchar.max should be 0x0010FFFF, since any value above this is illegal in a valid
> UTF-32 stream (and is also not a valid Unicode codepoint).
> 
> wchar.max is fine where it is, since the upper limit of UTF-16 is, in fact,
> 0xFFFF.

Hmmm. This is a bit problematic because even though values above those limits are not legal characters, they are still possible values of the type.

This can be dangerous, since you often check TYPE.max if you want to know the upper limit of the possible values (perhaps because you want to create a lookup structure or something of the kind). If max defines only the legal range then any other value is likely to result in "bad" behaviour like program crashes. It could also be a potential security risk, as it creates an opportunity for buffer overflow attacks.

Hauke