TOTAL RETARDATION in C++

4478 views
Skip to first unread message
Message has been deleted
Message has been deleted

looseont...@gmail.com

unread,
Jun 12, 2013, 4:10:52 AM6/12/13
to std-pr...@isocpp.org
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

unread,
Jun 12, 2013, 4:39:46 AM6/12/13
to std-pr...@isocpp.org, looseont...@gmail.com
I seem to have missed your paper about changing these things.

Ville Voutilainen

unread,
Jun 12, 2013, 5:07:28 AM6/12/13
to std-pr...@isocpp.org
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

unread,
Jun 12, 2013, 6:09:28 AM6/12/13
to std-pr...@isocpp.org, 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

unread,
Jun 12, 2013, 6:23:50 AM6/12/13
to std-pr...@isocpp.org, 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

unread,
Jun 12, 2013, 6:53:21 AM6/12/13
to std-pr...@isocpp.org, looseont...@gmail.com

Got it.  I'll start right away.

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

 

Ville Voutilainen

unread,
Jun 12, 2013, 6:57:04 AM6/12/13
to std-pr...@isocpp.org
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

unread,
Jun 12, 2013, 6:59:21 AM6/12/13
to std-pr...@isocpp.org, 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

unread,
Jun 12, 2013, 7:35:25 AM6/12/13
to std-pr...@isocpp.org
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

unread,
Jun 12, 2013, 7:36:16 AM6/12/13
to std-pr...@isocpp.org
Oh, yeah. You can instantiate them to fuck a class, a function, or even some kinds of values.

Fernando Cacciola

unread,
Jun 12, 2013, 8:31:06 AM6/12/13
to std-pr...@isocpp.org
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

unread,
Jun 12, 2013, 9:26:25 AM6/12/13
to std-pr...@isocpp.org
I thought partial function specialization was added already? 

Daniel Krügler

unread,
Jun 12, 2013, 9:29:15 AM6/12/13
to std-pr...@isocpp.org
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

unread,
Jun 12, 2013, 12:37:04 PM6/12/13
to std-pr...@isocpp.org, louf...@gmail.com
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

unread,
Jun 12, 2013, 2:35:48 PM6/12/13
to std-pr...@isocpp.org, looseont...@gmail.com
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

unread,
Jun 12, 2013, 2:43:22 PM6/12/13
to std-pr...@isocpp.org
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

unread,
Jun 12, 2013, 2:54:05 PM6/12/13
to std-pr...@isocpp.org
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

unread,
Jun 12, 2013, 3:13:17 PM6/12/13
to std-pr...@isocpp.org, fai...@gmail.com
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

unread,
Aug 11, 2013, 7:52:18 PM8/11/13
to std-pr...@isocpp.org
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

unread,
Mar 8, 2015, 3:20:11 AM3/8/15
to std-pr...@isocpp.org, stevenaw...@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

unread,
Aug 11, 2016, 9:02:24 AM8/11/16
to ISO C++ Standard - Future Proposals, looseont...@gmail.com
Is even ANY of this retardation fixed in C++17?

Ville Voutilainen

unread,
Aug 11, 2016, 9:08:34 AM8/11/16
to ISO C++ Standard - Future Proposals
On 11 August 2016 at 16:02, <looseont...@gmail.com> wrote:
> Is even ANY of this retardation fixed in C++17?

No.

D. B.

unread,
Aug 11, 2016, 9:09:26 AM8/11/16
to std-pr...@isocpp.org
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

unread,
Aug 11, 2016, 10:03:44 AM8/11/16
to <std-proposals@isocpp.org>
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

unread,
Aug 12, 2016, 3:54:22 AM8/12/16
to ISO C++ Standard - Future Proposals, looseont...@gmail.com
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

unread,
Aug 12, 2016, 2:45:19 PM8/12/16
to std-pr...@isocpp.org, looseont...@gmail.com
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

unread,
Aug 12, 2016, 3:34:29 PM8/12/16
to ISO C++ Standard - Future Proposals, looseont...@gmail.com
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

unread,
Aug 12, 2016, 11:14:42 PM8/12/16
to <std-proposals@isocpp.org>, looseont...@gmail.com
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

unread,
Aug 12, 2016, 11:30:11 PM8/12/16
to <std-proposals@isocpp.org>
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

unread,
Aug 15, 2016, 4:12:53 AM8/15/16
to ISO C++ Standard - Future Proposals, looseont...@gmail.com
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

unread,
Aug 15, 2016, 12:06:39 PM8/15/16
to std-pr...@isocpp.org
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

unread,
Aug 15, 2016, 9:10:08 PM8/15/16
to std-pr...@isocpp.org
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.

Casey Carter

unread,
Aug 16, 2016, 2:13:44 AM8/16/16
to ISO C++ Standard - Future Proposals, looseont...@gmail.com
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

unread,
Aug 16, 2016, 2:17:37 AM8/16/16
to ISO C++ Standard - Future Proposals, looseont...@gmail.com
*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.

Victor Dyachenko

unread,
Aug 16, 2016, 3:30:53 AM8/16/16
to ISO C++ Standard - Future Proposals, looseont...@gmail.com
On Tuesday, August 16, 2016 at 9:13:44 AM UTC+3, Casey Carter wrote:
void f(const std::variant