__CLASS__

[dgutson .]

how many times a standard __CLASS__ macro has been proposed?

--

Who’s got the sweetest disposition?
One guess, that’s who?
Who’d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

[Corentin]

I made a proposal for something that may be similar to what you are after https://wg21.link/p0874r0 - It was not presented afaik.

Whatever you actually need, a non-macro-based solution would probably be preferable !

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-3AfOQyYZ2%3DGVGEkfjTjvLA54YgiOHVan6g1ye40tOfPg%40mail.gmail.com.

[Cleiton Santoia]

  Have you tried: 

  remove_reference<decltype(*this)>: type

[Nevin Liber]

On Fri, May 11, 2018 at 12:38 PM Cleiton Santoia <cleiton...@gmail.com> wrote:

  Have you tried: 

  remove_reference<decltype(*this)>: type

While I have no idea what he means by a __CLASS__ macro (it could be a human-readable name, current type, floor wax or a dessert topping. :-)), if he is trying to get the type, remove_reference won't work if you are in a static function.

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

[Nicol Bolas]

On Friday, May 11, 2018 at 12:46:38 PM UTC-4, dgutson wrote:

how many times a standard __CLASS__ macro has been proposed?

Well, I did a site-specific search of WG21's papers, and found that something like it had been proposed. In N1534. This macro resolved to a string containing the current class's name.

Is that what you were looking for?

[dgutson .]

absolutely exactly. Thanks for googling it for me, I didn't find it before.

I will ask the author about what happened with it.

 

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3ee215c-a98d-4151-9814-b61625e32f70%40isocpp.org.

[Thiago Macieira]

On Friday, 11 May 2018 11:34:36 PDT Nevin Liber wrote:
> On Fri, May 11, 2018 at 12:38 PM Cleiton Santoia <cleiton...@gmail.com>
>
> wrote:
> > Have you tried:
> >
> > remove_reference<decltype(*this)>: type
>
> While I have no idea what he means by a __CLASS__ macro (it could be a
> human-readable name, current type, floor wax or a dessert topping. :-)), if
> he is trying to get the type, remove_reference won't work if you are in a
> static function.

Or completely outside of a function:

struct S
{
decltype(this) next;
static const decltype(*this) shared;
};

With the corresponding implementation:

const auto S::shared = decltype(*this){};

It might be a lot easier to just have _ThisType or _This_t.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Corentin]

That exemple make less sense, if you know S you don't need anything else.  

const auto S::shared = decltype(S()){};

From within the class... I'd love feedback on my paper :) 

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1827054.BeU4cdH5qD%40tjmaciei-mobl1.

[Thiago Macieira]

On Saturday, 12 May 2018 00:51:11 PDT Corentin wrote:
> That exemple make less sense, if you know S you don't need anything else.
> const auto S::shared = decltype(S()){};
>
> From within the class... I'd love feedback on my paper :)

I'm not saying you'd use it in this case. This is an extreme.

But having a type instead of a macro may be useful. It would clearly prevent
someone trying to do STRINGIFY(__CLASS__).

[dgutson .]

El sáb., 12 de mayo de 2018 13:52, Thiago Macieira <thi...@macieira.org> escribió:

On Saturday, 12 May 2018 00:51:11 PDT Corentin wrote:
> That exemple make less sense, if you know S you don't need anything else.
> const auto S::shared = decltype(S()){};
>
> From within the class... I'd love feedback on my paper :)

I'm not saying you'd use it in this case. This is an extreme.

But having a type instead of a macro may be useful. It would clearly prevent
someone trying to do STRINGIFY(__CLASS__).

I was just asking for something simple and intuitive for people familiar with __FUNCTION__ or __LINE__, which is nothing more but the name of the class, for debugging and logging messages.

We should stop turning simple things unnecessarily complicated.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2181198.8Um9XG2qBb%40tjmaciei-mobl1.

[Nicol Bolas]

On Saturday, May 12, 2018 at 4:47:44 PM UTC-4, dgutson wrote:

El sáb., 12 de mayo de 2018 13:52, Thiago Macieira <thi...@macieira.org> escribió:

On Saturday, 12 May 2018 00:51:11 PDT Corentin wrote:
> That exemple make less sense, if you know S you don't need anything else.
> const auto S::shared = decltype(S()){};
>
> From within the class... I'd love feedback on my paper :)

I'm not saying you'd use it in this case. This is an extreme.

But having a type instead of a macro may be useful. It would clearly prevent
someone trying to do STRINGIFY(__CLASS__).

I was just asking for something simple and intuitive for people familiar with __FUNCTION__ or __LINE__, which is nothing more but the name of the class, for debugging and logging messages.

We should stop turning simple things unnecessarily complicated.

To be fair though, you didn't make that clear in your initial post. Several people in this thread thought that this macro would resolve to the class typename, not a string naming the type.

[dgutson .]

My bad. I thought it was obvious  (you in fact found the exact proposal indeed).

Anyways sorry everybody for the assumption and lack of clarification. 

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4938dd9a-aa72-48dc-876f-fbb21f7e1ff6%40isocpp.org.

[Thiago Macieira]

On Saturday, 12 May 2018 13:47:31 PDT dgutson . wrote:
> I was just asking for something simple and intuitive for people familiar
> with __FUNCTION__ or __LINE__, which is nothing more but the name of the
> class, for debugging and logging messages.
> We should stop turning simple things unnecessarily complicated.

If you want the class name inside member functions for logging, you already
have it: it's part of __FUNCTION__.

[dgutson .]

El dom., 13 de mayo de 2018 0:47, Thiago Macieira <thi...@macieira.org> escribió:

On Saturday, 12 May 2018 13:47:31 PDT dgutson . wrote:
> I was just asking for something simple and intuitive for people familiar
> with __FUNCTION__ or __LINE__, which is nothing more but the name of the
> class, for debugging and logging messages.
> We should stop turning simple things unnecessarily complicated.

If you want the class name inside member functions for logging, you already
have it: it's part of __FUNCTION__.

At least not in latest gcc. That's why it provides __PRETTY_FUNCTION__ .

Are you sure? Where in the std says so?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1544149.IVPBvGKrrZ%40tjmaciei-mobl1.

[Ville Voutilainen]

On 13 May 2018 at 13:43, dgutson . <daniel...@gmail.com> wrote:
>> If you want the class name inside member functions for logging, you
>> already
>> have it: it's part of __FUNCTION__.
>
>
> At least not in latest gcc. That's why it provides __PRETTY_FUNCTION__ .
>
> Are you sure? Where in the std says so?

Quite obviously nowhere, because the standard says nothing about __FUNCTION__.

[dgutson .]

That's because it is in the C std? And the C++ doesn't "override" that part?

In such a case there is no way that __FUNCTION__ can contain the scope as part of it as currently specified.

 

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.

To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUY0P%3DM_yBwr3d5u9%2Bpgu3XZtDibWQuuZJrDT1tB26dhKA%40mail.gmail.com.