Valentin Bonnard <bonnardv@pratique.fr> wrote:
> The program is correct has it is, and is still correct with the
> explicit qualification, so SCpp behavior is incorrect.

Ok, I'll just have to continue qualify it then.

> Why does EOutOfRange inherit privatly from EKeyError ? It seems that
> public inheritance should be appropriate.

Because I have several (well, at least one) more classes deriving from
it (they are intended to be thrown as exceptions, obviously) and I do
not wish to make it possible to catch all errors referring to keys by
catching EKeyError. I suppose that EKeyError should be placed in the
private part of TAssociativeArray.

---
Christoffer Karlsson
Computer Science, Mathematics and Physics Student
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Valentin Bonnard <bonnardv@pratique.fr> wrote:
> The program is correct has it is, and is still correct with the
> explicit qualification, so SCpp behavior is incorrect.

Ok, I'll just have to continue qualify it then.

> Why does EOutOfRange inherit privatly from EKeyError ? It seems that
> public inheritance should be appropriate.

Because I have several (well, at least one) more classes deriving from
it (they are intended to be thrown as exceptions, obviously) and I do
not wish to make it possible to catch all errors referring to keys by
catching EKeyError. I suppose that EKeyError should be placed in the
private part of TAssociativeArray.

---
Christoffer Karlsson
Computer Science, Mathematics and Physics Student
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hi,

I have a question regarding the following code fragment:

template <class T, class K>
class TAssociativeArray {
  public:
     ...
     // Exceptions
     class EKeyError {
      public:
        // Constructors
        EKeyError(const K theKey) : fKey(theKey) { };
        // The Offending key
        K fKey;
     };

     class EOutOfRange : private EKeyError { // (1)
      public:
        // Constructors
        EOutOfRange(const K theKey) : EKeyError(theKey) { };
     }
     ...
};

This works fine with one compiler (namely MrCpp 4.0.1b) but makes
another (SCpp 8.1.0) choke at location (1) saying that it cannot find
EKeyError. If I instead say ... EOutOfRange : private
TAssociativeArray::EKeyError it works just fine.

Now which compiler does the right thing? If SCpp's behavior is incorrect
(in that it does not recognize EKeyError unqualified) is it then correct
(ie. also portable) to always qualify them?

Thank you for your help.
---
Christoffer Karlsson
Computer Science and Mathematics Student
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

(posted to comp.std.c++)

Christoffer Karlsson <c95chrka@und.ida.liu.se> writes:

> I have a question regarding the following code fragment:
>
> template <class T, class K>
> class TAssociativeArray {
>   public:
>      ...
>      // Exceptions
>      class EKeyError {

>
>      class EOutOfRange : private EKeyError { // (1)

> };
>
> This works fine with one compiler (namely MrCpp 4.0.1b) but makes
> another (SCpp 8.1.0) choke at location (1) saying that it cannot find
> EKeyError. If I instead say ... EOutOfRange : private
> TAssociativeArray::EKeyError it works just fine.
>
> Now which compiler does the right thing? If SCpp's behavior is incorrect
> (in that it does not recognize EKeyError unqualified) is it then correct
> (ie. also portable) to always qualify them?

The program is correct has it is, and is still correct with the
explicit qualification, so SCpp behavior is incorrect.

Why does EOutOfRange inherit privatly from EKeyError ? It seems that
public inheritance should be appropriate.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Christoffer Karlsson wrote:
>
> Hi,
>
> I have a question regarding the following code fragment:
>
> template <class T, class K>
> class TAssociativeArray {
>   public:
>      ...
>      // Exceptions
>      class EKeyError {
>       public:
>         // Constructors
>         EKeyError(const K theKey) : fKey(theKey) { };
>         // The Offending key
>         K fKey;
>      };
>
>      class EOutOfRange : private EKeyError { // (1)
>       public:
>         // Constructors
>         EOutOfRange(const K theKey) : EKeyError(theKey) { };
>      }
>      ...
> };
>
> This works fine with one compiler (namely MrCpp 4.0.1b) but makes
> another (SCpp 8.1.0) choke at location (1) saying that it cannot find
> EKeyError. If I instead say ... EOutOfRange : private
> TAssociativeArray::EKeyError it works just fine.

Because classes EOutOfRange and EKeyError are declare in the same class,
no explicit qualification is required. Probably, it is bug in Scpp 8.1.0

> Now which compiler does the right thing? If SCpp's behavior is incorrect
> (in that it does not recognize EKeyError unqualified) is it then correct
> (ie. also portable) to always qualify them?
>

If you want to explicitly qualify, qualify it as
TAssociativeArray<T,K>::EKeyError instead of just
TAssociativeArray::EKeyError. Even for portability, there is no need for
qualification at all. The error probably is due to a bug.


Srinivas
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]