TOTAL RETARDATION in C++

[looseont...@gmail.com]

Hi,

template <class X> void f() {}

template <> void f<int>() {}

COMPILES

struct S {

    template <class X> void f() {}

    template <> void f<int>() {}

};

--> error: explicit specialization of 'f' in class scope

FUCKING RETARDED

WOW IT REALLY MAKES SENSE THAT THIS WORKS AT GLOBAL SCOPE BUT NOT IN-CLASS

struct S {

    template <class X> struct Inner {};

    template <> struct Inner<int> {};

};

--> error: explicit specialization of 'Inner' in class scope

FUCKING RETARDED

struct S {

    template <class X, class = void> struct Inner {};

    template <class bullshit> struct Inner<int, bullshit> {};

};

WOW, RETARDS, WORKS WITH A STUPID-RETARDED WORKAROUND

struct S {

    template <class X, class=void> void f() {}

    template <class bullshit> void f<int, bullshit>() {}

};

--> function template partial specialization is not allowed

FUCKING RETARDED

WOW THE RETARDED WORKAROUND DOESN'T WORK FOR FUNCTIONS

template <class X> void f(X x) {}

template <class X> void f(X* x) {}

OH, OK THIS GOOD

template <class X, class Y> void f() {}

template <class Y> void f<int, Y>() {}

--> function template partial specialization is not allowed

FUCKING RETARDED.

I don't even want to hear 1 piece of bullshit out of a single one of you people's mouths about this one.

If you give me one piece of bullshit, you're a fucking n00b.

Every one of these things is used for metaprogramming.

After 15 years of awareness about these problems, nothing was fixed.

And now with C++14, yet another oversight release, we're heading for 20 years of fucking retardation.

Thank you standards body people for your retarded level of awareness, you fucking retards.

Can you fix the holes you fucking retards?

[DeadMG]

I seem to have missed your paper about changing these things.

[Ville Voutilainen]

On 12 June 2013 11:39, DeadMG <wolfei...@gmail.com> wrote:

I seem to have missed your paper about changing these things.

Luckily, there have been proposals by sane people to change some of those things.

Such changes have thus far been of low priority. I don't expect lunatic raving to have
an improving effect on that.

[looseont...@gmail.com]

BESIDES THE FACT THAT IT'S SO FUCKING RETARDED THAT C++ CAN'T DO **ALL** OF THIS SHIT,

ONE OF THEM,

IN-CLASS-EXPLICIT-SPECIAL,

*WORKS* ON FUCKING MICROSOFT VISUAL STUDIO

FOR A LONG-ASSED TIME NOW.

SO WE HAVE A BUNCH OF FUCKING INCONSISTENT CODE

BECAUSE PEOPLE USE THE SHIT IN VISUAL STUDIO

AND IT DOESN'T GIVE A SINGLE FUCKING WARNING

AND IT DOESN'T WORK ON GCC OR CLANG

CAN YOU GUYS FUCKING VOTE ON IT AND FIX IT?

DUH?

ARE YOU RETARDED?

[looseont...@gmail.com]

And by the way

Just because I brought up Microsoft

Doesn't mean you can fix fucking 1 of them

You need to fix all of them

[Jonathan Wakely]

Got it.  I'll start right away.

Anything else I can do for you, since you asked so nicely?

 

[Ville Voutilainen]

On 12 June 2013 13:53, Jonathan Wakely <c...@kayari.org> wrote:

Got it.  I'll start right away.

Indeed. This was an excellent heads-up. It's not like volunteers were already working their asses off for
no compensation, spending massive amounts of their waking hours on the committee work.

We could also, of course, take the things mentioned and put them at the very end of the queue, just
out of spite, since it seems people don't deserve those to be fixed. Just a thought.

[looseont...@gmail.com]

YOU WANT ME TO WRITE THE PROPOSAL?

I'M NOT EVEN FUCKING SANE

YOU THINK I KNOW HOW TO WRITE A PROPOSAL

YOU PEOPLE ARE SUPPOSEDLY SANE

AND YOU CAN'T EVEN DO IT

WHY DO YOU HAVE TO WASTE SO MUCH TIME ON THE RETARDED PROPOSALS WITH ALL THE PRETTY PRINT?

DO YOU THINK I HAVE FUCKING TIME FOR A BUNCH OF FUCKING PRETTY PRINT

WHY DONT YOU READ MY FUCKING POST WHERE I SAID IT'S FUCKING RETARDED AND BE HAPPY WITH THAT AS THE PROPOSAL

AND THEN WRITE THE GODDAMN STANDARD WORDING TO IT AND USE WHAT I SAID ABOUT RETARDATION AS THE LITERAL PRESENTATION

YOU DON'T NEED A BUNCH OF FUCKING HIGH-WORDING LITERARY C++ DOCUMENTARIAN TPS-REPORT MAGIC FOR WEIRD FUCKING FREAK BEARDED MEN WHO ARE GONNA VOTE NO BECAUSE IT WASNT WORDED RIGHT TO FIGURE THIS SHIT OUT, OK?

WHY YOU THINK C++ IS SO FUCKING SLOW? BECAUSE ALL YOU FUCKING RETARDS NEED A BUNCH OF FUCKING POWERPOINT DIAGRAMS TO UNDERSTAND ANYTHING

FIX THE GODDAMN WORDING AND THEN JUST DO IT, WHO HAS TIME TO FUCK AROUND WITH DOCUMENT INDENTATION BULL-CRAP AND A BIG FUCKING PRETEXT WHERE I TRY TO SOUND ALL NICE AND SANE FOR CRAZY PEOPLE JUST TO MAKE YOU UNDERSTAND THE CONCEPT

THAT YOU NEED TO FIX THE BASIC FUCKING TEMPLATE FEATURES

[Ville Voutilainen]

On 12 June 2013 13:59, <looseont...@gmail.com> wrote:

YOU WANT ME TO WRITE THE PROPOSAL?

No thanks, we're fine without your proposals.

THAT YOU NEED TO FIX THE BASIC FUCKING TEMPLATE FEATURES

Interesting. I knew we had class templates and function templates, and alias templates (since c++11), and

as of late, variable templates (as of c++14, likely), but I have completely missed these fucking templates.

[DeadMG]

Oh, yeah. You can instantiate them to fuck a class, a function, or even some kinds of values.

[Fernando Cacciola]

Wow, this thread totally beats me.

I always thought, and maybe I still think, that there was something about being a programmer, and a C++ one more specially, that highly relates with having very effective comunication skills and focused problem solving skills applied to comunciation (i.e. don't complain, as it does nothing, but point and colaborate, etc). After all, a program boils down to a written expression of intent very carefully crafted out to produce a precise result. So I find it very very unusual to see a programmer failing so misserably at comunication something that is intended to have a specific, positive outcome.

His approach is of a totally unproductive, comunicationally ignorant and socially broken kind. One that I often see in other "technical" areas, most notably in physics, where everyone seems to believe is a genious and all others are retarded, just as in this case.

I know there are lots of forums with equally uneducated programmers, but IME they are often much, much less "sophisticated" than std-proposals.  So like I said, I still can't believe I'm really reading this here.



--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

[louf...@gmail.com]

I thought partial function specialization was added already? 

[Daniel Krügler]

2013/6/12 <louf...@gmail.com>:

> Le mercredi 12 juin 2013 11:07:28 UTC+2, Ville Voutilainen a écrit :
> I thought partial function specialization was added already?

You are misinformed.

- Daniel

[VinceRev]

With type_traits and SFINAE you can easily emulate partial specialization with no fundamental problem :
-------------------------------------------------------
#include <iostream>
#include <type_traits>
struct S {
    template <class X, class = typename std::enable_if<!std::is_same<X, int>::value>::type> void f()
    {std::cout<<"not int"<<std::endl;}
    template <class X, class = typename std::enable_if<std::is_same<X, int>::value>::type, class = void> void f()
    {std::cout<<"int"<<std::endl;}
};

int main()
{
    S s;
    s.f<double>();
    s.f<int>();
    return 0;
}
-------------------------------------------------------

But as it was already said, standardization is a long peer-review process to satisfy hundreds of thousands of programmers. So if you have a proposition to make, write a clear proposal in order to have a basis for further discussions.

Vincent

[Nicol Bolas]

In an attempt to salvage something of value from this thread, what exactly is the problem with doing explicit, full specialization of types and functions that are declared within a class? Was this just an oversight, or was there some real problem with just allowing it to work as expected?

[Faisal Vali]

I can not comment on whether it was originally an oversight, but having proposed it to be changed, and being in the room when EWG approved the change this past meeting - (and assuming my memory is serving me well), I can tell you no one who was present had a good reason for why it was as it was.  Let us see what happens in core.

Faisal Vali

On Wed, Jun 12, 2013 at 1:35 PM, Nicol Bolas <jmck...@gmail.com> wrote:

In an attempt to salvage something of value from this thread, what exactly is the problem with doing explicit, full specialization of types and functions that are declared within a class? Was this just an oversight, or was there some real problem with just allowing it to work as expected?

--
 
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
 
 

[Richard Smith]

On Wed, Jun 12, 2013 at 11:43 AM, Faisal Vali <fai...@gmail.com> wrote:
> I can not comment on whether it was originally an oversight, but having
> proposed it to be changed, and being in the room when EWG approved the
> change this past meeting - (and assuming my memory is serving me well), I
> can tell you no one who was present had a good reason for why it was as it
> was. Let us see what happens in core.

For those following along at home, the "explicit class template
specialization at class scope" part is core issue 727, and was
proposed in
c++std-ext-13746.

[Nicol Bolas]

On Wednesday, June 12, 2013 11:43:22 AM UTC-7, faisalv wrote:

I can not comment on whether it was originally an oversight, but having proposed it to be changed, and being in the room when EWG approved the change this past meeting - (and assuming my memory is serving me well), I can tell you no one who was present had a good reason for why it was as it was.  Let us see what happens in core.

Faisal Vali

So... this has already been fixed for C++14 (modulo not being able to do partial specialization on functions, which would be a far less trivial request).

That's my fault for assuming a guy who named his thread "TOTAL RETARDATION" knew what he was talking about.

[stevenaw...@gmail.com]

I'm usually against trolling but aside from the shocking verbal abuse this guy has leveled at a bunch of hard-working and well-meaning people, I think he has some good arguments which should be considered separately from the ravings that accompanied them.

Also, you spelled "genius" wrong.

[pho...@gmail.com]

On Sunday, August 11, 2013 at 5:52:18 PM UTC-6, stevenaw...@gmail.com wrote:

I'm usually against trolling but aside from the shocking verbal abuse this guy has leveled at a bunch of hard-working and well-meaning people, I think he has some good arguments which should be considered separately from the ravings that accompanied them.

Also, you spelled "genius" wrong.

 
Not to mention "miserably" only has one 's'.

Sorry. These things just stand out while I'm reading.  Spell-checkers are available.

[looseont...@gmail.com]

Is even ANY of this retardation fixed in C++17?

[Ville Voutilainen]

On 11 August 2016 at 16:02, <looseont...@gmail.com> wrote:
> Is even ANY of this retardation fixed in C++17?

No.

[D. B.]

Get a load of this guy, who somehow thinks repeatedly insulting people somehow makes them more likely to listen to him.

Recommend immediate address and IP block. No point even responding.

[Faisal Vali]

I can't speak for when the specification will be updated, but I've
been meaning to merge (refactor and clean up) my patch of the agreed
upon resolutions for cwg727 & cwg1755 (https://reviews.llvm.org/D3445
- which should address the OP's frustrations) into clang trunk - but
sadly I haven't gotten around to it (given that it's been hard finding
time to get caught up on some of the more pressing issues).

And I'm not entirely sure that the OP's insulting tone is the right
way to motivate us (I tend to find that it usually has the opposite
effect on me - but I could be wrong ;)

Also please don't view the act of my response as accepting of the
notion that such abusive language on these reflectors should be
rewarded by any sort of response - but rather view it as seizing an
opportunity to inform the wider community that progress might be just
around the corner ...(especially if given the right push)

>
> --
> 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/CAFk2RUZcVMJzVOY-dU5wQKorzDPRjXrwsjK9tC_uBPG0sB6nVQ%40mail.gmail.com.

[Victor Dyachenko]

And one more confusing thing for me.

In C++98 local classes can't be used as template arguments. But with emergence of lambdas in C++11 this was fixed. In C++14 we got generic lambdas but member templates in local classes still aren't allowed? WTF? Is it just mistake( like "nobody has proposed this") or there are some real difficulties to implement this as compared to generic lambdas?

(I am invoking the spirits of compiler writers ;-)

[Richard Smith]

There are real difficulties here, particularly if the member template is inside a local class in a function template. In the implementation I'm familiar with, a key problem is that the lexical scopes used while processing a function definition are fundamentally transient, which means that delaying instantiation of some portion of a function template definition is hard to support. Generic lambdas don't suffer from a problem here, because the body of the generic lambda is instantiated with the enclosing function template, but presumably the instantiation model for a member template within a local class of a function template would be that the member template is not instantiated at all until a complete set of template arguments for it are known, which may not happen until after the instantiation of the enclosing template has finished and the lexical scope information is gone.

[Victor Dyachenko]

On Friday, August 12, 2016 at 9:45:19 PM UTC+3, Richard Smith wrote:

Generic lambdas don't suffer from a problem here, because the body of the generic lambda is instantiated with the enclosing function template, but presumably the instantiation model for a member template within a local class of a function template would be that the member template is not instantiated at all until a complete set of template arguments for it are known, which may not happen until after the instantiation of the enclosing template has finished and the lexical scope information is gone.

Richard, thank you for your response. But could you, please, clarify what is the difference between this particular code snippets:

void f(const std::variant<int, char, double> &v)
{
    std::visit([](auto &v) { std::cout << v; }, v);
}

and

void f(const std::variant<int, char, double> &v)
{
    struct visitor
    {
        template<class T>
        void operator()(const T &v) const { std::cout << v; }
    };
    std::visit(visitor{} , v);
}

Why the former doesn't compile?

[Faisal Vali]

Richard is right as usual - local templates and member templates of
local classes are not necessarily trivial to implement in (or add to)
an implementation - just because that implementation has generic
lambdas already implemented - but that doesn't mean they can't be
reasonably implemented - or that they should never be considered for a
future C++.

So if you have a compelling use case and well thought out design for
local templates that enough seasoned folks are willing to rally around
- commit to the cause, be brave and co-author a paper with those folks
-- and following an EWG presentation, you might just arrive at the
pleasant (or tragic ;) realization that the only reason C++ lacked
local templates was because you hadn't chosen to articulate a well
reasoned case for their design sooner ...

> --
> 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/b146c590-1782-48e3-9c8e-30a1549e04e9%40isocpp.org.

[Faisal Vali]

The latter doesn't compile for the simple reason that the standard
prohibits member templates in local classes.

And if you're asking why would it be hard for a compiler to compile
the latter when it has no problem compiling the former - it wouldn't
(if the standard allowed it) - but then again this is not the
'partial-instantiation' case Richard was referring to above.

> --
> 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/c18e8d92-4650-43b9-9e24-826a154a8e28%40isocpp.org.

[Victor Dyachenko]

Here is use case of the latter that explains why it can't replaced by generic lambda:

void f(const std::variant<T1, T2, ...> &v)
{
    struct visitor
    {
        context ctx;
        visitor(...) : ctx(...) {}

        void operator()(const T1 &v) const; // some specific action for T1
        void operator()(const T2 &v) const; // some specific action for T2
        template<class T>
        void operator()(const T &v) const; // some 'default' action for all other types
    };
    std::visit(visitor{...} , v);
}

One can argue that in this case you can build the visitor using lambdas + overload(). But in this case context must be embedded to each lambda.

[Matthew Woehlke]

On 2016-08-11 10:03, Faisal Vali wrote:
> On 11 August 2016 at 16:02, <looseont...@gmail.com> wrote:
>> Is even ANY of this retardation fixed in C++17?
>

> And I'm not entirely sure that the OP's insulting tone is the right
> way to motivate us (I tend to find that it usually has the opposite
> effect on me - but I could be wrong ;)

I found the OP's tone *extremely* motivating. It motivated me to not
even attempt to read whatever he was trying to say ;-).

If someone can't be bothered to be at least marginally polite, I can't
be bothered to listen to them. I'm sure I'm not the only person that
feels that way.

> Also please don't view the act of my response as accepting of the
> notion that such abusive language on these reflectors should be
> rewarded by any sort of response

PDNFTT? ;-)

(It's also interesting to note that on a forum where many people use
their real names, the OP only uses a screen name...)

--
Matthew

[Patrice Roy]

I, for one, absolutely loved Ville's clear, concise answer. Could not be more appropriate.

--
Matthew

--
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/noi1e5%24hbk%241%40blaine.gmane.org.

[Casey Carter]

On Monday, August 15, 2016 at 1:12:53 AM UTC-7, Victor Dyachenko wrote:

Here is use case of the latter that explains why it can't replaced by generic lambda:

void f(const std::variant<T1, T2, ...> &v)
{
    struct visitor
    {
        context ctx;
        visitor(...) : ctx(...) {}

        void operator()(const T1 &v) const; // some specific action for T1
        void operator()(const T2 &v) const; // some specific action for T2
        template<class T>
        void operator()(const T &v) const; // some 'default' action for all other types
    };
    std::visit(visitor{...} , v);
}

One can argue that in this case you can build the visitor using lambdas + overload(). But in this case context must be embedded to each lambda.

void f(const std::variant<T1, T2, ...> &v)
{
    struct visitor

    {
        context ctx;
        visitor(...) : ctx(...) {}

        void operator()(const T1 &v) const; // some specific action for T1
        void operator()(const T2 &v) const; // some specific action for T2
        template<class T>
        void operator()(const T &v) const; // some 'default' action for all other types
    };

    std::visit([ctx = context{...}](const auto& v) {

        if constexpr(is_same_v<const T1&, decltype(v)>) {

        } else if constexpr(is_same_v<const T2&, decltype(v)>) {

        } else {

        }

    }, v);
}

[Casey Carter]

*sigh* Sorry, early post. but the idea is fairly clear: "some specific action for T1" in the first branch, etc.

Althought it's not precisely equivalent, since e.g. the struct version is ill-formed if T1 and T2 are the same type, whereas the if constexpr version is not.