Can someone help with my seg fault?

This is a discussion on Can someone help with my seg fault? within the C++ Programming forums, part of the General Programming Boards category; Yes absolutely! I've been through discussions on that before and been assured that it is fine by the standard. Okay, ...

  1. #16
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,954
    Yes absolutely! I've been through discussions on that before and been assured that it is fine by the standard.
    Okay, I went to read the standard again, and I think you are right.

    There is only one case afaik where you need "this->" apart from disambiguating locals from members (which you can avoid by renaming them), and it relates to some pretty extreme templated code. I've read about it, and I heard the wooshing sound as it flew over my head, and I'd expect to probably never come across it in my lifetime.
    Actually, I think it came up recently here (or maybe Codeguru, I get mixed up sometimes, especially with George2 around).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #17
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    Quote Originally Posted by laserlight View Post
    Actually, I think it came up recently here (or maybe Codeguru, I get mixed up sometimes, especially with George2 around).
    It happens when you try to access an inherited, non-dependent name in a derived class. Here we go:

    Code:
    #include <iostream>
    
    template <typename T>
    struct A
    {
       void hello()
       {
          std::cout << "A::hello()" << std::endl;
       }
    };
    
    template <typename T>
    struct B : public A<T>
    {
       B()
       {
          this->hello();
       }
    };
    You might think the part highlighted in red can be removed. It can't be.

  3. #18
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,954
    You might think the part highlighted in red can be removed. It can't be.
    In this case it can be removed and be replaced with B<T>:: since hello() is non-virtual.

    EDIT:
    Then again, this problem can only occur in the derived class template, so I think that it should be okay even if hello() was virtual and used in say, a member function of B rather than its constructor.
    Last edited by laserlight; 02-29-2008 at 01:29 PM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #19
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    Quote Originally Posted by laserlight View Post
    In this case it can be removed and be replaced with B<T>:: since hello() is non-virtual.
    True. I should have worded differently. There are several ways to make the call, but none of them are just "hello()."

  5. #20
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    Quote Originally Posted by laserlight View Post
    In this case it can be removed and be replaced with B<T>:: since hello() is non-virtual.
    By the way, the reason this occurs is that all names must unambiguously resolvable at the point of template declaration. That doesn't mean that all type information must be present, but you have to help the compiler a little bit.

    For one thing, there could possibly be a specialization of A which does not declare the hello() member function. In that case, B's lookup of the symbol "hello" would be unresolved at declaration time because it could possibly be referring to a global, non-templated function. But the compiler has no way of knowing that, because the declaration of the global hello() need not exist in the current translation unit. You have to clarify by specifying "this->" in order to say, "I really do intend for this name to refer to a member."

    You're right that you could have used A<T>:: or B<T>:: instead, but the pointer syntax guarantees that the lookup will be virtual if necessary.

    EDIT: My example was poor, because if hello() had been virtual, it would not have been valid to call it inside B's constructor.

  6. #21
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,261
    Quote Originally Posted by brewbuck View Post
    It happens when you try to access an inherited, non-dependent name in a derived class. Here we go:

    You might think the part highlighted in red can be removed. It can't be.
    Yes I think that's what I was referring to, and thanks to your description I think I actually understand it this time.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  7. #22
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,165
    Quote Originally Posted by brewbuck View Post
    I guess you've never used a language like Python where you are REQUIRED to write this-> (actually, "self.") before every member access. It is awful. It's not a taste thing, it's just ignorant.
    And just why is it ignorant? I can use it everywhere I want to help IntelliSense out a bit to bring up members of the class itself. There is absolutely nothing wrong with this-> unless there is really, really good reason that.
    Otherwise, all I can see is that it's a taste thing. You may not like it, but that doesn't mean it's bad.

    And just for clarification, no I never used Python...
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.
    For information on how to enable C++11 on your compiler, look here.
    よく聞くがいい!私は天才だからね! ^_^

  8. #23
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,261
    I know some people use that reasoning. If it ever made sense to pop up the intellisense upon typing the first alphabetic char then they would do that, but the problem is it would show everything, and would just annoy people. It is more feasible for when you type "this->" first and is consistent with the other times it appears. However it was never intended to suggest that people actually unnecessarily leave "this->" in a program.

    I too sometimes type "this->" just for the intellisense, but I'll definitely delete it as soon as I've gotten my answer out of intellisense.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  9. #24
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    Quote Originally Posted by Elysia View Post
    And just why is it ignorant? I can use it everywhere I want to help IntelliSense out a bit to bring up members of the class itself.
    Changing the way you write code just to take advantage of a feature of a particular IDE is silly.

    There is absolutely nothing wrong with this-> unless there is really, really good reason that.
    Otherwise, all I can see is that it's a taste thing. You may not like it, but that doesn't mean it's bad.
    And what if you change a member function to make it static? Now the this-> syntax is invalid and you get to go through all your code to change it.

    Not having to write this-> everywhere is one of the biggest advantages of OO.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Getting a seg fault
    By ammochck21 in forum C Programming
    Replies: 11
    Last Post: 01-23-2009, 04:27 AM
  2. Seg Fault in Compare Function
    By tytelizgal in forum C Programming
    Replies: 1
    Last Post: 10-25-2008, 03:06 PM
  3. seg fault at vectornew
    By tytelizgal in forum C Programming
    Replies: 2
    Last Post: 10-25-2008, 01:22 PM
  4. weird seg fault
    By Vermelho in forum C Programming
    Replies: 3
    Last Post: 05-10-2008, 08:27 PM
  5. Seg Fault Problem
    By ChazWest in forum C++ Programming
    Replies: 2
    Last Post: 04-18-2002, 03:24 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21