www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 0.93 release

reply "Walter" <newshound digitalmars.com> writes:
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
Jun 22 2004
next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"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
Jun 23 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 23 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"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.
Jun 23 2004
prev sibling next sibling parent reply Derek <derek psyc.ward> writes:
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
Jun 23 2004
parent "Walter" <newshound digitalmars.com> writes:
"Derek" <derek psyc.ward> wrote in message
news:1rjnyzcq4q0ih.11hscruppphwb.dlg 40tude.net...

 I assume that these optional arguments are passed as 'in' rather than


'out'

 or 'inout'?


_arguments[] is passed as 'in'. _argptr is actually a local variable.
Jun 23 2004
prev sibling next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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
Jun 23 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:cbbpce$2r7c$1 digitaldaemon.com...

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


Not only multiple, but also variable number of indexes!!

class IndexingClass
{
 int opIndex(...)
 {
  return 133;
 }
}

And this works great! This is what i call a consistency in a language :)


 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
Jun 23 2004
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jun 23 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 23 2004
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Arcane Jill wrote:

 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.


<snip>

 (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.


Yes, there's a trade-off between ABI consistency, semantic consistency 
and versatility.

(1) achieves ABI consistency, and some degree of semantic consistency 
only as far as the cases that work work consistently with other types.

(2) can be implemented as strict CBV, or as a superset of (1).  Either 
way, semantic consistency is lost, but in the second case only in what 
(1) can't do at all....

I suppose (3) would get my vote.  Full semantic consistency, full 
versatility.  Bit arrays are an inherently special type anyway, so I 
suppose we can get away with defining a special ABI for them.  Moreover, 
bit pointers would be consistent with other pointers - just as an int* 
can point to an arbitrary int, a bit* could point to an arbitrary bit.

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.
Jun 23 2004
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
fwiw, my (wasted) vote is that the bit type dies

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cbbtqr$59$1 digitaldaemon.com...

 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
Jun 23 2004
parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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.

Cheers,
Sigbjørn Lund Olsen
Jun 23 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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?
Jun 23 2004
parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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)
Jun 24 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:cbbr47$2tbk$1 digitaldaemon.com...

 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....


What matters most are issues (bugs or feature lack) that impact the most
projects. Lack of typesafe varargs prevented a redesign of printf that is
just a long standing open sore with D, affecting nearly every program
written in D.


 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....


It's nice to have the bit slicing, but it isn't an issue for many projects.
Jun 23 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:
<snip>

 What matters most are issues (bugs or feature lack) that impact the most
 projects.


I don't see how there manages to be quite so little overlap between the 
PendingPeeves, the bugs I've encountered and the bugs that the average 
project wants fixed.  OK, so there's quite a bit of overlap between the 
first two....

One of mine could certainly do with

http://www.digitalmars.com/drn-bin/wwwnews?D/25715 et seq....


 Lack of typesafe varargs prevented a redesign of printf that is
 just a long standing open sore with D, affecting nearly every program
 written in D.


Good to see one of them at least being thought about.  I shall wait to 
see what you come up with....

<snip>

 It's nice to have the bit slicing, but it isn't an issue for many projects.


Well, if there's anything precluding the ready-made fixes being put in, 
it ought to be made not yet implemented, rather than leaving in a 
completely non-functional implementation.

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.
Jun 23 2004
parent "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:cbccrk$oa8$1 digitaldaemon.com...

 Walter wrote:
 <snip>

 What matters most are issues (bugs or feature lack) that impact the most
 projects.


 I don't see how there manages to be quite so little overlap between the
 PendingPeeves, the bugs I've encountered and the bugs that the average
 project wants fixed.  OK, so there's quite a bit of overlap between the
 first two....


The thing is, everyone has a different list <g>.
Jun 23 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 23 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
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
Jun 23 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cbc0ii$4gr$1 digitaldaemon.com>, Hauke Duden says...

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


That is a good point. You may well be right,

That said, I think that your argument only holds true for char. I don't see it
holding true for dchar - that is, I don't see anyone crafting a lookup table
even with 0x110000 entries in it, because that would be a HUGE lookup table.
(And I *DEFINITELY* don't think that anyone would increase the size of their
lookup table to 0xFFFFFFFF just because that's the value of dchar.max). As you
and I both know because of our Unicode property lookup techniques, if the table
is sparse (which, for dchars, it will be) there are better representations than
a single humungous lookup table.

So how about a new, revised, suggestion:
char.max = 0xFF
wchar.max = 0xFFFF
dchar.max = 0x0010FFFF

(and this would mean that char.init <= char.max, which actually makes more sense
than my original suggestion).

If you're still not happy, I'll drop the suggestion altogether.

Arcane Jill
Jun 23 2004
next sibling parent Peter Wood <pwood iel.ie> writes:
How about proposing the addition of a new, character specific property (sorry I
have no suggestions for a name) and leave max to it's (IMHO) intuitive meaning.

On Wed, 23 Jun 2004 15:04:13 +0000 (UTC)
Arcane Jill <Arcane_member pathlink.com> wrote:


 In article <cbc0ii$4gr$1 digitaldaemon.com>, Hauke Duden says...

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


 
 That is a good point. You may well be right,
 
 That said, I think that your argument only holds true for char. I don't see it
 holding true for dchar - that is, I don't see anyone crafting a lookup table
 even with 0x110000 entries in it, because that would be a HUGE lookup table.
 (And I *DEFINITELY* don't think that anyone would increase the size of their
 lookup table to 0xFFFFFFFF just because that's the value of dchar.max). As you
 and I both know because of our Unicode property lookup techniques, if the table
 is sparse (which, for dchars, it will be) there are better representations than
 a single humungous lookup table.
 
 So how about a new, revised, suggestion:
 char.max = 0xFF
 wchar.max = 0xFFFF
 dchar.max = 0x0010FFFF
 
 (and this would mean that char.init <= char.max, which actually makes more
sense
 than my original suggestion).
 
 If you're still not happy, I'll drop the suggestion altogether.
 
 Arcane Jill
Jun 23 2004
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Arcane Jill wrote:

 In article <cbc0ii$4gr$1 digitaldaemon.com>, Hauke Duden says...
 

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


 
 
 That is a good point. You may well be right,
 
 That said, I think that your argument only holds true for char. I don't see it
 holding true for dchar - that is, I don't see anyone crafting a lookup table
 even with 0x110000 entries in it, because that would be a HUGE lookup table.
 (And I *DEFINITELY* don't think that anyone would increase the size of their
 lookup table to 0xFFFFFFFF just because that's the value of dchar.max). As you
 and I both know because of our Unicode property lookup techniques, if the table
 is sparse (which, for dchars, it will be) there are better representations than
 a single humungous lookup table.


I didn't mean a simple linear table - there are other possible data 
structures that can rely on the upper limit for the values.

For example, if you use the technique we use for the Unicode tables in a 
more generalized way you could end up with something like this:

class Foo(VALTYPE,INDEXTYPE)
{	
const int PAGESIZEBITS = 16;

//the following is the crucial line
const int PAGECOUNT = (INDEXTYPE.max+1) / (1<<PAGESIZEBITS);
	
VALTYPE** pages;

this()
{
pages = new VALTYPE*[PAGECOUNT];		
}

VALTYPE lookup(INDEXTYPE index)
{
//this will cause a crash if index > INDEXTYPE.max
return pages[index>>PAGESIZEBITS][index & (1<<PAGESIZEBITS)-1];
}
}

Of course this is only a simplified example, but it shows how container 
templates may use the max property to allocate the necessary space. It 
doesn't have to be a simple linear array.


 So how about a new, revised, suggestion:
 char.max = 0xFF
 wchar.max = 0xFFFF
 dchar.max = 0x0010FFFF
 
 (and this would mean that char.init <= char.max, which actually makes more
sense
 than my original suggestion).


This doesn't really solve the problem. My main concern is that the type 
can hold values that are bigger than the "max" value.


 If you're still not happy, I'll drop the suggestion altogether.


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?

Hauke
Jun 23 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
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
Jun 23 2004
parent J C Calvarese <jcc7 cox.net> writes:
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/
Jun 23 2004
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
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!


Here's a half-baked attempt that uses far too many templates for its own 
good:

http://andy.tadan.us/d/format.zip

  -- andy
Jun 23 2004
prev sibling next sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <cbb9sq$22qv$1 digitaldaemon.com>, Walter says...

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


This looks great!  A few questions:

1. Exactly how portable is _argptr?  Can we rely on the example working (i.e.
the += int.size operations)?  I.e. if va_arg is better, what does _argptr
provide?  (or is one in terms of the other?)

2. Is the example for FOO incorrect?  Does this really skip over the class, or a
pointer to the class, or what?
_argptr += FOO.sizeof;

3. Is there documentation for TypeInfo?

Kevin
Jun 23 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:cbctk0$1jcn$1 digitaldaemon.com...

 1. Exactly how portable is _argptr?  Can we rely on the example working


(i.e.

 the += int.size operations)?  I.e. if va_arg is better, what does _argptr
 provide?  (or is one in terms of the other?)


va_arg handles stack alignment issues, so you should do that instead of
incrementing _argptr yourself.


 2. Is the example for FOO incorrect?  Does this really skip over the


class, or a

 pointer to the class, or what?
 _argptr += FOO.sizeof;


FOO.sizeof is the size of a reference to a FOO object. The example is
correct.


 3. Is there documentation for TypeInfo?


It's in object.d in Phobos <g>.
Jun 23 2004
parent reply Kevin <Kevin_member pathlink.com> writes:
In article <cbcu4h$1k77$1 digitaldaemon.com>, Walter says...

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:cbctk0$1jcn$1 digitaldaemon.com...

 1. Exactly how portable is _argptr?  Can we rely on the example working


(i.e.

 the += int.size operations)?  I.e. if va_arg is better, what does _argptr
 provide?  (or is one in terms of the other?)


va_arg handles stack alignment issues, so you should do that instead of
incrementing _argptr yourself.


 2. Is the example for FOO incorrect?  Does this really skip over the


class, or a

 pointer to the class, or what?
 _argptr += FOO.sizeof;


FOO.sizeof is the size of a reference to a FOO object. The example is
correct.


 3. Is there documentation for TypeInfo?


It's in object.d in Phobos <g>.


Well the code matches the documentation anyway <g>.

Kevin
Jun 23 2004
parent "Walter" <newshound digitalmars.com> writes:
"Kevin" <Kevin_member pathlink.com> wrote in message
news:cbd0cm$1oc5$1 digitaldaemon.com...

 In article <cbcu4h$1k77$1 digitaldaemon.com>, Walter says...

 3. Is there documentation for TypeInfo?


It's in object.d in Phobos <g>.


 Well the code matches the documentation anyway <g>.


"Use the source, Luke" -- Obi Bin Coding
Jun 23 2004
prev sibling next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Walter" <newshound digitalmars.com> escribió en el mensaje
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!
|
| 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

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)

-----------------------
Carlos Santander Bernal
Jun 23 2004
parent "Walter" <newshound digitalmars.com> writes:
 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.
Jun 23 2004
prev sibling parent reply Burton Radons <burton-radons shaw.ca> writes:
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?
Jun 24 2004
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jun 24 2004
prev sibling next sibling parent pragma <EricAnderton at yahoo dot com> <pragma_member pathlink.com> writes:
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));
Jun 24 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"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.
Jun 24 2004