From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Lawrence Crowl <crowl@googlers.com>
Cc: Richard Guenther <richard.guenther@gmail.com>,
Eric Botcazou <ebotcazou@adacore.com>,
gcc-patches@gcc.gnu.org, Jan Hubicka <hubicka@ucw.cz>,
Diego Novillo <dnovillo@google.com>
Subject: Re: Use conditional casting with symtab_node
Date: Wed, 19 Sep 2012 21:28:00 -0000 [thread overview]
Message-ID: <CAAiZkiBLyP7n8R3wwMC-T98wdpHtNFLJmpz7rN_uGiOncFcruQ@mail.gmail.com> (raw)
In-Reply-To: <CAGqM8fZ_0oxvpmbsUj3c371p7R9d49dOqrHTybxyrp9ArhZHuw@mail.gmail.com>
On Wed, Sep 19, 2012 at 1:39 PM, Lawrence Crowl <crowl@googlers.com> wrote:
> On 9/19/12, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>> On Sep 19, 2012 Richard Guenther <richard.guenther@gmail.com> wrote:
>> > Indeed. Btw, can we not provide a specialization for
>> > dynamic_cast <>? This ->try_... looks awkward to me compared
>> > to the more familiar
>> >
>> > vnode = dynamic_cast <varpool_node> (node)
>> >
>> > but yeah - dynamic_cast is not a template ... (but maybe there
>> > is some standard library piece that mimics it?).
>>
>> No, it is a language primitive.
>>
>> but we can define out own operation with similar syntax that allows
>> for specialization, whose generic implementation uses dynamic_cast.
>>
>> template<typename T, typename U>
>> T* is(U* u) {
>> return dynamic_cast<T*>(u);
>> }
>
> At this point, dynamic_cast is not available because we do not
> yet have polymorphic types. There has been some resistance to
> that notion.
Hmm, when did we rule that out?
We currently implement dynamic_cast using the poor man's simulation
based on tree_code checking. We can just as well give such
simulation the is<> notation.
> Absent dynamic cast, we need to specialize for various type
> combinations. Function template specialization would be handy,
> but C++ does not directly support that. We could work around
> that.
We can always use the standard workaround: call a static member
function of a class template that can be specialized at will.
> However, in the end, the fact that try_whatever is a member
> function means that we can use a notation that depends on context
> and so can be shorter. That is, we can write 'function' instead of
> 'cgraph_node *'.
>
> --
> Lawrence Crowl
next prev parent reply other threads:[~2012-09-19 21:15 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-18 18:02 Lawrence Crowl
2012-09-18 18:09 ` Eric Botcazou
2012-09-18 18:37 ` Lawrence Crowl
2012-09-19 7:31 ` Eric Botcazou
2012-09-19 9:17 ` Richard Guenther
2012-09-19 12:19 ` Gabriel Dos Reis
2012-09-19 19:04 ` Lawrence Crowl
2012-09-19 21:28 ` Gabriel Dos Reis [this message]
2012-09-19 22:03 ` Lawrence Crowl
2012-10-11 5:31 ` Xinliang David Li
2012-09-20 13:25 ` Michael Matz
2012-10-11 5:22 ` Xinliang David Li
2012-10-11 20:26 ` Lawrence Crowl
2012-10-11 20:41 ` Xinliang David Li
2012-10-12 8:24 ` Richard Biener
2012-10-12 19:43 ` Xinliang David Li
2012-10-13 17:56 ` Lawrence Crowl
2012-10-13 18:04 ` Gabriel Dos Reis
2012-10-14 17:08 ` Diego Novillo
2012-09-19 18:39 ` Lawrence Crowl
2012-09-20 13:26 ` Michael Matz
2012-09-20 20:01 ` Lawrence Crowl
2012-09-20 22:02 ` Gabriel Dos Reis
2012-09-20 22:06 ` Lawrence Crowl
2012-09-18 19:57 ` Richard Guenther
2012-09-18 20:32 ` Lawrence Crowl
2012-09-22 6:07 ` Lawrence Crowl
2012-09-25 21:25 ` Lawrence Crowl
2012-10-03 0:32 ` Lawrence Crowl
2012-10-03 12:07 ` Martin Jambor
2012-10-03 16:53 ` Lawrence Crowl
2012-10-04 8:00 ` Richard Guenther
2012-10-04 18:14 ` Lawrence Crowl
2012-10-04 18:17 ` Diego Novillo
2012-10-05 8:50 ` Richard Guenther
2012-10-05 9:52 ` Jan Hubicka
2012-10-10 0:58 ` Lawrence Crowl
2012-10-10 23:46 ` Diego Novillo
2012-10-05 10:50 ` Nathan Froyd
2012-10-05 11:05 ` Richard Guenther
2012-10-05 12:44 ` Diego Novillo
2012-10-05 13:58 ` Steven Bosscher
2012-10-05 14:07 ` Steven Bosscher
2012-10-05 21:50 ` Lawrence Crowl
2012-10-05 22:04 ` Steven Bosscher
2012-10-11 6:49 ` Xinliang David Li
2012-10-11 13:11 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAiZkiBLyP7n8R3wwMC-T98wdpHtNFLJmpz7rN_uGiOncFcruQ@mail.gmail.com \
--to=gdr@integrable-solutions.net \
--cc=crowl@googlers.com \
--cc=dnovillo@google.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).