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.

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;
    }

......

---

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?

You can access anything if you call it the right name. :D

Quote:

---

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*

;)

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

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.

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.

Quote:

---

Originally Posted by Daved

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.

Thanks, guys.

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

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.