On Fri, 11 Mar 2005 10:22:54 +1100, Matthew wrote:

> "Walter" <newshound@digitalmars.com> wrote in message news:d0q1vg$2m2t$1@digitaldaemon.com...
>>
>> "Roberto Mariottini" <Roberto_member@pathlink.com> wrote in message news:d0p053$1jav$1@digitaldaemon.com...
>>> In article <d0o6v7$mir$1@digitaldaemon.com>, Walter says...
>>> >
>>> >I remember when static_cast came out, I had to read the spec several times to figure out what it did. 'static' has no reliable meaning in C++.
>>>
>>> Isn't 'static' the opposite of 'dynamic'? :-)
>>>
>>> >Suppose I propose:
>>> >
>>> >    extern_cast<B*>(a);
>>> >
>>> >for C++. What does it do?
>>>
>>> The opposite of 'static'. :-)
>>
>> Yup <g>. The point being that it's clear what it does only after
>> carefully
>> reading the documentation.
>>
>> The double cast way of doing static casts in D is an idiom. There are
>> idioms
>> in D just like there are well-known idioms in C++. I suggest that the
>> double
>> cast idiom will become one of those well recognized ones and it's
>> meaning
>> will be clear because people will be used to seeing it and using it.
> 
> Sorry to get all unprofessional, but when I read you saying things like this I wonder whether the world is made of chocolate, and Homer's eaten out my brain.
> 
> That double cast is a freakish bit of code, that will be fantastic fodder for D-etractors. I'm just stunned that you think that it's reasonable, in a language with all the intentions D makes, to propose such hacks, instead of addressing real needs within the (pre-1.0) language itself.
> 
[snip]

> It's just bonkers.
> 
> I put it to everyone who's managed to get to stick with the rant to this point to select which of the following is more discoverable, maintainable, amenable to automated code searching tools, indicative of considered design, attractive, etc.:
> 
>     b = cast(B)cast(void*)a;
> 
>     b = type_cast(B)(a);
> 
> (Note: type_cast is just a name I conjured for the example. Naturally we'd go through a collegial process for coming up with good and sensible names for any/all specific cast operators.)


Matthew has a good point. The double cast idiom is just asking to be picked on as a "stupid idea" when a much more expressive one could have be implemented.


-- 
Derek Parnell
Melbourne, Australia
11/03/2005 10:57:51 PM

On Thu, 10 Mar 2005 21:48:56 -0800, kris wrote:

> Ben Hinkle wrote:
> <snip>
>> ack - I really hope D doesn't end up with a bazillion (or even, say, three)casting options. Casting is so rare and the performance hit of a dynamic cast vs static cast hasn't ever been a problem in my Java coding experience that it would be a pity to burden future D coder with all the esoteric casts. Why bother? Casting is evil - so why obsess over it.

But still necessary sometimes.

  void Foo(char[] x){};
  void Foo(wchar[] x){};

  Foo(cast(wchar[])"abcdef"); // Cast required else the compiles fails.


-- 
Derek Parnell
Melbourne, Australia
11/03/2005 11:06:16 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:1l04rq800km3a.16v19z9iovqpy$.dlg@40tude.net...
> On Thu, 10 Mar 2005 21:48:56 -0800, kris wrote:
>
>> Ben Hinkle wrote:
>> <snip>
>>> ack - I really hope D doesn't end up with a bazillion (or even, say,
>>> three)casting options. Casting is so rare and the performance hit of a
>>> dynamic
>>> cast vs static cast hasn't ever been a problem in my Java coding
>>> experience that
>>> it would be a pity to burden future D coder with all the esoteric casts.
>>> Why
>>> bother? Casting is evil - so why obsess over it.
>
> But still necessary sometimes.
>
>  void Foo(char[] x){};
>  void Foo(wchar[] x){};
>
>  Foo(cast(wchar[])"abcdef"); // Cast required else the compiles fails.

Agreed. And I argue the existing D cast does just fine with 99.9% of cast situations. I actually am curious why Walter thinks the double-cast will become an idiom. The only "legit" one that comes to mind is wanting to do a static cast on object references instead of a dynamic cast for performance.

>> >> simplified const handling (storage instead of type),
>> >
>> >As has been debated here many times <g>, const as a type modifier in C++
>is
>> >so semantically weak it is fairly useless. (Many disagree.) C and C++ are the only languages I've ever heard of that use const as a type modifier. Java and C# show no signs of adopting it. The C++ community has not convinced the larger programmer community that const as a type modifier
>has
>> >a place.
>>
>> Most languages don't have destructors. So the C++ community has not
>convinced
>> the larger programmer community that destructores have a place. But are
>> destructors bad just because of that?
>> I know you don't think so, otherwise D wouldn't have auto classes.
>
>Of course. It should be of strong interest to any language designer what other language designers do. Both Java and C# came from C++. What C++ features did they pick, what did they leave out, and most importantly, why? I believe many of the choices they made are excellent, and many are mistakes. It's important that I be able to justify the decisions for D, and if it diverges from what other C++ based language designers chose, I think the bar is at least a little higher for justifying it.

I see.

>> >> etc, and I guess I'd have more examples if I had been using C++ more...
>> >> And this makes C++ more "complete" in that you can do more things,
>> >> but is also makes a lot harder and complex - at least at the start ?
>> >
>> >I'd argue that C++ is less complete, since it relies so heavilly on STL
>to
>> >do things that are built in to most languages.
>>
>> I know a lot of languages that have built in linked lists (Lisp, SML,
>O'Caml,
>> Haskell, Clean, ... to name just a few popular languages). D does not.
>Why?
>
>Because the UDT facilities in D are good enough that it's trivial to do a linked list.

In SML a user defined type that represents a linkd list would look like this: # datatype 't MyList = EmptyList | ListNode of 't * 't MyList

The type MyList parameterised with 't is eigther an EmptyList or a ListNode,
which consists of an object of type 't and another list of type MyList
parameterisd with 't.
I think you can't beat this shortness and expressiveness in D, but SML still has
a built in list type.

But you are right. D isn't 'functional' enough for a built in list-type.


Anyway, C++ dosn't have built-in quques, stacks, 'dictoranrys', ... but using them is almost as simple as the built-in counter-parts of other languages that have such structures built in.

# stack<int> foo;
#
# foo.push(42);
# int value = foo.top();
# foo.pop();

Could it be easier?

In article <d0s3nj$1s5q$1@digitaldaemon.com>, Ben Hinkle says...
>"Derek Parnell" <derek@psych.ward> wrote in message news:1l04rq800km3a.16v19z9iovqpy$.dlg@40tude.net...
>> On Thu, 10 Mar 2005 21:48:56 -0800, kris wrote:
>>
>>> Ben Hinkle wrote:
>>> <snip>
>>>> ack - I really hope D doesn't end up with a bazillion (or even, say,
>>>> three)casting options. Casting is so rare and the performance hit of a
>>>> dynamic
>>>> cast vs static cast hasn't ever been a problem in my Java coding
>>>> experience that
>>>> it would be a pity to burden future D coder with all the esoteric casts.
>>>> Why
>>>> bother? Casting is evil - so why obsess over it.
>>
>> But still necessary sometimes.
>>
>>  void Foo(char[] x){};
>>  void Foo(wchar[] x){};
>>
>>  Foo(cast(wchar[])"abcdef"); // Cast required else the compiles fails.
>
>Agreed. And I argue the existing D cast does just fine with 99.9% of cast situations. I actually am curious why Walter thinks the double-cast will become an idiom. The only "legit" one that comes to mind is wanting to do a static cast on object references instead of a dynamic cast for performance.

Well, working with varargs is rife with casting through "void**" to get the actual argument's pointer.  The suggested template in the docs helps some, but its still there, under the hood.

>The only "legit" one that comes to mind is wanting to do a static cast on object references instead of a dynamic cast for performance.

That's an interesting concept, but probably ill-adivsed in D (more so than in C++).  It would work great class-to-class, but will fail if an interface is involved in the cast.

- EricAnderton at yahoo

pragma wrote:

> Well, working with varargs is rife with casting through "void**" to get the
> actual argument's pointer.  The suggested template in the docs helps some, but
> its still there, under the hood.

The suggested template is the only way that works in GDC since _argptr
is not a "void*" everywhere, but a "va_list" type that *might* be one...

Hopefully the void*/cast section of the D specification can be removed,
in favor of std.stdarg, to stop people from writing non-portable code ?

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


Kinda like writing to D's string literals, which only works on Windows.

--anders

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0qksf$9im$1@digitaldaemon.com...
> Users from other languages in which these issues have already been sensibly addressed will naturally seek to avoid the too-coarse-grained cast() operator. You've recognised that, and demonstrated a technique whereby they might do so. But what you're telling them is that, to do so, they must use pointers in a language that specifically eschews pointers.

The cast(B)a will work perfectly fine, and avoids pointer manipulation. It'll do upcasting and downcasting for class objects in a safe manner. The cast(B)cast(void*)a is a technique for people who want to *go around* the typing rules because they "know" that 'a' can be downcast to a B without a runtime check. As such, it qualifies as a technique for more advanced programmers, and pointers are well supported in D expressly for use by more advanced programmers who understand them.

"Walter" <newshound@digitalmars.com> wrote in message news:d0tobv$1999$1@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0qksf$9im$1@digitaldaemon.com...
>> Users from other languages in which these issues have already been
>> sensibly addressed will naturally seek to avoid the
>> too-coarse-grained
>> cast() operator. You've recognised that, and demonstrated a technique
>> whereby they might do so. But what you're telling them is that, to do
>> so, they must use pointers in a language that specifically eschews
>> pointers.
>
> The cast(B)a will work perfectly fine, and avoids pointer
> manipulation.
> It'll do upcasting and downcasting for class objects in a safe manner.
> The
> cast(B)cast(void*)a is a technique for people who want to *go around*
> the
> typing rules because they "know" that 'a' can be downcast to a B
> without a
> runtime check. As such, it qualifies as a technique for more advanced
> programmers, and pointers are well supported in D expressly for use by
> more
> advanced programmers who understand them.

Well, I have to say I find that attitude quite depressing. I am quite sure that it will make D look like a hackers delight. You're equally sure it won't. Impasse. I can do nothing useful further, other than take the brick from my hand and not bash my head with it any further.

However, you have not addressed the far less equivocal point that

    cast(X)cast(void*)y

is manifestly less amenable to code analysis tools as

    static_cast(X)y

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d0tsll$1d22$1@digitaldaemon.com...
> However, you have not addressed the far less equivocal point that
>
>     cast(X)cast(void*)y
>
> is manifestly less amenable to code analysis tools as
>
>     static_cast(X)y

If grep is the extent of it, perhaps. I think cast(void*) is eminently greppable; you'll get some false positives just like you will with grepping for static_cast.

On the other hand, D is far more amenable to real code analysis tools because D is parseable at several levels without requiring a full blown compiler to do it. Even if you are using a code analysis tool that needs to do semantic analysis, it's just a lot easier to do with D than with C++. Once you have that, it isn't hard at all to look for a double cast on a class reference.

If that still isn't enough, you can always write a template to do it, and grep on the template name.