Compiles on OS X but not in Linux

This is a discussion on Compiles on OS X but not in Linux within the C++ Programming forums, part of the General Programming Boards category; This is a source I downloaded off the Internet, and the author explicitly stated that it would compile on Linux ...

  1. #1
    Registered User
    Join Date
    Oct 2005
    Posts
    271

    Compiles on OS X but not in Linux

    This is a source I downloaded off the Internet, and the author explicitly stated that it would compile on Linux and OS X. Well, he's only half right. It compiles on OS X, but not on Linux.

    Well, here's the offending line of code:

    Code:
    template<class T>
    class SmartPointer
    {
     protected:
      T* p;
     public:
      SmartPointer(T* _p=0) 
        : p(_p) {}
      inline T&operator*() const 
        {return *p;}
      inline T*operator->() const 
        {return p;}
      inline operator const bool() const 
        {return p!=0;}
      inline T*ptr() const
        { return p; }
    };
    
    .....
    
    template <class T> 
    class DELP : public SmartPointer<T>
    {
     private:
      DELP(const DELP<T> &x);
     public:
      const DELP<T> &operator=(DELP<T> &x)
      {
        delete p;           // FIRST ERROR of "p" was not declared in this scope
        p=x.p;x.p=0;
        return *this;
      }
    
      ~DELP()
        { delete p;p=0;} // SECOND ERROR of "p" was not declared in this scope
      DELP(T*_p=0) 
        : SmartPointer<T>(_p) {}
      void set(T*_p)
        {
          delete p;       // THIRD ERROR of "p" was not declared in this scope
          p=_p;
        }
    
    ......
    Could somebody tell me why this is throwing an error on Linux but not on OS X?

    I'm using g++ 4.0.3 and the make command for this particular section seems to be
    Code:
    g++   -Wall -W -Wno-deprecated -O2 -DNDEBUG -DWORDINDEX_WITH_4_BYTE  -c Parameter.cc -o optimized/Parameter.o
    Thanks.

  2. #2
    Registered User Noir's Avatar
    Join Date
    Mar 2007
    Posts
    218
    Maybe prefix p with SmartPointer<T>?
    Code:
    template <class T> 
    class DELP : public SmartPointer<T>
    {
     private:
      DELP(const DELP<T> &x);
     public:
      const DELP<T> &operator=(DELP<T> &x)
      {
        delete SmartPointer<T>::p;
        SmartPointer<T>::p=x.p;x.p=0;
        return *this;
      }
    
      ~DELP()
        { delete SmartPointer<T>::p;SmartPointer<T>::p=0;}
      DELP(T*_p=0) 
        : SmartPointer<T>(_p) {}
      void set(T*_p)
        {
          delete SmartPointer<T>::p;
          SmartPointer<T>::p=_p;
        }
    
    ......

  3. #3
    Registered User
    Join Date
    Oct 2005
    Posts
    271
    Thank you. That worked.

    I also discovered that
    Code:
    DELP<T>::p
    also worked.

    I always thought that if you declared a class member variable as protected, you could access it from any derived class without scoping (e.g. declaring "p" in SmartPointer as protected then referencing it as plain "p" in DELP).

    I guess I was wrong. But then, why did it compile without a hitch in my Mac?

  4. #4
    Registered User Noir's Avatar
    Join Date
    Mar 2007
    Posts
    218
    You can access anything if you call it the right name.
    But then, why did it compile without a hitch in my Mac?
    Ooh! I can do this with my new Salem impression:

    *Salem impression*
    Just because it works on one compiler doesn't mean it's portable. If you walk on broken glass, you shouldn't be surprised when you bleed to death.
    *end Salem impression*


  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,849
    Which compiler (and version) do you have on the Mac ?

    > why did it compile without a hitch in my Mac?
    Compilers are full of all sorts of bugs / extensions / implementation specifics which just frustrate writing good portable code.

    Just because a bit of C++ compiles on one compiler doesn't immediately guarantee that every other C++ compiler will do the same.

    I don't know whether what you've done is required by ANSI (g++ being strict and the Mac compiler just being "helpful") or whether it should be fine without it (possible bug in g++).

    Perhaps this will help
    http://gcc.gnu.org/onlinedocs/gcc-4....ml#Name-lookup
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    It works fine on my Linux machine, g++ version 3.2.3. I think you've probably run into a bug in 4.0.3 for Linux -- as far as I know, this code is valid and it shouldn't be complaining.

  7. #7
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    According to Salem's link, it is actually a bug of pre-3.4 versions of g++, so throwing an error is correct and your compiler is just not current enough.

  8. #8
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,274
    Quote Originally Posted by Daved View Post
    According to Salem's link, it is actually a bug of pre-3.4 versions of g++, so throwing an error is correct and your compiler is just not current enough.
    And yet g++ 4.x on Mac throws no such error. Weird. Wouldn't be the first inexplicable difference I've seen between Apple's version of the compiler and the official version.

  9. #9
    Registered User
    Join Date
    Oct 2005
    Posts
    271
    Thanks, guys.

    Hope I can fix every bug I find in the code with what I got here.

  10. #10
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    BTW, I would use this->p just to be consistent with when you have to do the same with a virtual member function since this->foo() would make sure to call the correct virtual overload versus DELP<T>::foo() or SmartPointer<T>::foo() which would bypass the virtual mechanism.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Thinking of upgrading to linux...
    By Yarin in forum General Discussions
    Replies: 37
    Last Post: 07-24-2009, 12:40 PM
  2. Dabbling with Linux.
    By Hunter2 in forum Tech Board
    Replies: 21
    Last Post: 04-21-2005, 05:17 PM
  3. Consulting/Long Term: C, Linux, OS
    By safarigirlnj in forum Projects and Job Recruitment
    Replies: 3
    Last Post: 02-12-2005, 12:20 PM
  4. Is Linux Really A Programmers OS?
    By SourceCode in forum A Brief History of Cprogramming.com
    Replies: 43
    Last Post: 04-07-2003, 10:24 PM
  5. question from linux board ( not os dependant )
    By crypto in forum C Programming
    Replies: 4
    Last Post: 11-15-2002, 02:09 AM

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