1
struct mystruct
{
    using this_class = mystruct; 
    /* 
       old typedef such as: 
       typedef struct mystruct  this_class; 
       also does not work 
    */
    this_class(){}
};

This code works well in visual C++, but fails in gcc or clang. I suspect it may not be 100% C++ even with c++11, c++14 or c++17 switches.

But it is very useful to have a this_class typedef because it permits to change the name of a class by simply adjusting

using this_class = new_class_name

without having to change all the occurrences of the class name in the class definition.

Is there a switch in gcc and clang that would allow me to continue to use this useful statement (allowed in visual c) when I port my code from visual c++ ?

NOTE: This differs from a previous question: 'Can I implement an autonomous self member type in C++? ' as I want to know if there are switches in clang and gcc to allow the above statement allowed in visual c++. I am not interested in the complicated hacks shows in the other question, just on compatibility switches between compilers

programmer
  • 41
  • 6
  • For what it's worth, the code is technically incorrect. Section 12.1, "in a _member-declaration_ that belongs to the _member-specification_ of a class but is not a friend declaration, the _id-expression_ is the injected-class-name of the immediately-enclosing class" – aschepler Dec 09 '16 at 22:43
  • 1
    Possible duplicate of [Can I implement an autonomous \`self\` member type in C++?](http://stackoverflow.com/questions/21143835/can-i-implement-an-autonomous-self-member-type-in-c) – nrussell Dec 09 '16 at 22:47
  • to aschelper, but it does not rule out specifically the use of an alias – programmer Dec 10 '16 at 00:25
  • @programmer No, there are no such compiler flags. If you are really this concerned with trying to reduce the verbosity of your code, C++ may not be the best language for you. Although it has a lot of strong features, succinctness is not one of them. – nrussell Dec 10 '16 at 02:04
  • nrussell you've answered my question about compiler flags. Thanks. Question solved – programmer Dec 10 '16 at 03:15
  • Note that this code fails to compile with Visual C++ if you specifiy the `/Za`flag. – Christian Hackl Dec 10 '16 at 11:52
  • 1
    I don't think this feature would be very useful. It sacrifices readability for a very rare use case that is only concerned with easy writeability. It doesn't even account for all the uses of the class name in the rest of the code. – Christian Hackl Dec 10 '16 at 11:55

2 Answers2

1

I'll be violating a holy tenet, but you can do that with a simple macro.

#define THIS_CLASS mystruct

struct THIS_CLASS {

  THIS_CLASS (){}
};

#undef mystruct
StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
  • 1
    It is not an equivalent way for sure because with that method you would need to create as many #define as there are classes and the code itself would become pretty much unreadable with all the names of classes not immediately seen at the class definition line. – programmer Dec 09 '16 at 22:44
  • @programmer -- You don't win anything on the readability scale with either method. And I didn't propose placing the macro definition in any place either than right before the class or its methods are defined. – StoryTeller - Unslander Monica Dec 09 '16 at 22:52
  • So in effect your are answering the initial question by 'no, there isn't a compiler switch that would provide the porting of my c++ code from visual c++ to gcc or clang' I would need to rewrite every single class! That's distressing. I don't understand that after so many years of c++, this has not been settled with ease and intuitively with a native this_class just like we use a native this – programmer Dec 09 '16 at 23:43
  • @programmer, countless c++ programmers haven't seen value in such a feature. And so haven't proposed it. If you think it holds merit, you can sent a proposal to the standard committee that calls for this addition. But I don't see the appeal for it myself. to be honest. – StoryTeller - Unslander Monica Dec 09 '16 at 23:48
  • A) for merit of this_class vs #define: 1) the current guideline is to avoid using #define in code; 2) your solution requires 2 lines instead of 1 and remove the name of the class which is more than likely going to interfere with ide listing of class name – programmer Dec 09 '16 at 23:59
  • B) for merit of this_class vs using the original name everywhere in the class: this_class not only save typing but makes the code much more readable because it is generally dramatically shorter that the original descriptive class name and has an additional semantic value (by telling that this is the actual class) – programmer Dec 10 '16 at 00:01
  • @programmer -- A) macro's have their uses. Taking guidelines too far will paint yourself into a corner. My solution also requires only a single line changed if I want to rename the class. Wasn't it your purpose to being with? Plus, code should be easily understandable even without an IDE. Any `this_class` construct will interfere with *that*. – StoryTeller - Unslander Monica Dec 10 '16 at 00:03
  • 2 lines changes because you have also the #undef – programmer Dec 10 '16 at 00:05
  • B) It also produces a million hits for `this_class` in any decently sized code base. Making it an unmaintainable nightmare. And you can only go so far with "objective" readability, which `this_class` doesn't add to. Any way, comments aren't for extended discussion, so I'm signing of. If this answer isn't to your liking. Feel free to downovote and await another answer. – StoryTeller - Unslander Monica Dec 10 '16 at 00:05
  • @programmer --- I don't need to change the undef if I want to change what `THIS_CLASS` is... – StoryTeller - Unslander Monica Dec 10 '16 at 00:06
  • "this_class" *increases* the understandability, it does not interfere quite the opposite – programmer Dec 10 '16 at 00:07
  • @programmer -- You are wrong on that account, IMO. But I really am signing off this time. Cheers – StoryTeller - Unslander Monica Dec 10 '16 at 00:07
  • I think you don't understand that 'this_class' is used *inside* the class *only* – programmer Dec 10 '16 at 00:18
1

Conclusion

1) there are no flags in gcc and clang to mimmick the visual c++ behavior regarding internal class name alias

2) conversion is therefore laborious and requires at least 2 lines of codes for ALL classes using this_class

3) StoryTeller has a working way but may creates difficulty with IDE and readability

4) A better way is to put the #define macro inside the class, but this is similarly cumbersome:

struct class_name{
#define this_class class_name;

this_class(){}

/* other member functions here using this_class */

#undef this_class
};

5) Ideally a native this_class should be proposed for the next c++ standard to improve conciseness and portability. Since I have no clue where and how to propose that, if anyone who does know to do that is reading I would appreciate if they could submit it if possible

programmer
  • 41
  • 6