In article <O8t2a.1947$3g1.209581@news20.bellglobal.com>, Philippe Mori
<philippe_mori@hotmail.com> wrote:
> For those cases, simply adding a function that returns
> the const object solve the problem and IMHO is better.
>
> class Directory {
> public:
>     const std::vector<Node> &GetContents() const {
>         return m_Contents;    // or *this is second case
>     }
> };

Yeah, I thought about that.  My implementation went:

class Directory {
public:
   Directory() : Contents(m_Contents) {}
   const std::vector<Node>& Contents;
private:
   std::vector<Node> m_Contents;
};

....but I like yours better.  More flexibility.  Thanks.

 -- A Cappella Guy

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

A Cappella Guy wrote:
>    using m_Impl.C;

Why not just inherit privately from Impl?

>    using const m_Contents;
> private:
>    std::vector<Node> m_Contents;

Why not just

     std::vector<Node> const &r_Contents;
     Foo() : r_Contents(m_Contents) ...

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Hyman Rosen" wrote:
> A Cappella Guy wrote:
> >    using m_Impl.C;
>
> Why not just inherit privately from Impl?

Because it may not be possible to make it exception safe.  Unnecessary
coupling.  Read More Exceptional C++ on the topic (IIRC).

WW


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

acappellaguy@hotmail.com (A Cappella Guy) wrote in message news:<110220031511499473%acappellaguy@hotmail.com>...
> I apologize that I do not have a specific, detailed proposal in mind,
> just a couple areas where I believe the language could help better
> model the IS_IMPLEMENTED_IN_TERMS_OF relationship.  I'm hoping to open
> up a dialogue.
>
> 1) Extend using.
>
> I would like to see the using keyword bring selected methods of
> privately-inherited or contained implementation classes into the main
> interface of a class.  Something like:
>
> class Foo : private Bar {
> public:
>    using Bar::A;
>    using Bar::B;
>    using m_Impl.C;
>    using m_Impl.D;
> private:
>    Impl m_Impl;
> };

Note that the part concerning private base classes is already part of
the language.

As to implement a form of syntactic short hand for delegation by means
of the using keyboard, I have to say that I already posted this same
proposal on the newsgroup some time ago, without receiving much
feedback.

In my intention you should be able to do the following (I'm rewriting
your example just to clarify what is meant by the A's, B's, etc.
above):

class A {
  public:
    int f();
    int g();
};

class B {
  public:
    int h();
};

class C {
  public:
    using a;     // exposes all of A's public member functions
    using a.f;   // exposes only the named member
    using b->g;
  private:
    A a;
    B * b;
};

Note that in case of overloads, all the overloaded functions would be
exposed.

[...]
> 2) Public const, private non-const
>
> Automatic support for publicizing the const members of an
> implementation class, keeping non-const members private.  Here I have
> an actual example:
>
> class Directory {
> public:
>    Directory(const std::string& path);
>    void Refresh();
>    using const m_Contents;
> private:
>    std::vector<Node> m_Contents;
> };

I think this is also reasonable, even though it's not as straight an
extension of the meaning of the using keyword as the above one. Note
however that this is just a special case of extending 'using' to allow
the selection of specific overloads, which is also an issue with the
current uses of the using keyword.

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

White Wolf wrote:
> Because it may not be possible to make it exception safe.

Herb's description of better exception safety assumes that
the object is held through a pointer, not by value. Anyway,
support for this request would immediately run into the issue
of having more than one subobject of the given type, and the
fact that writing the forwarding functions is just a small
inconvenience.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I apologize that I do not have a specific, detailed proposal in mind,
just a couple areas where I believe the language could help better
model the IS_IMPLEMENTED_IN_TERMS_OF relationship.  I'm hoping to open
up a dialogue.

1) Extend using.

I would like to see the using keyword bring selected methods of
privately-inherited or contained implementation classes into the main
interface of a class.  Something like:

class Foo : private Bar {
public:
   using Bar::A;
   using Bar::B;
   using m_Impl.C;
   using m_Impl.D;
private:
   Impl m_Impl;
};

So you could take helper classes and have the compiler write member
functions that patch through to the selected instance, keeping others
private for the class's own use.

I suppose the following would theoretically be possible too:

class Foo {
public:
   using m_impl->A;
   using m_Impl->B;
private:
   Impl* m_Impl;
};

Though there would obviously be the restriction that Impl be fully
defined prior to the using directive.  This wouldn't help users of
pimpl who want to hide the private details of the class.  Also there
could be complications involving overloaded operator-> and such.

2) Public const, private non-const

Automatic support for publicizing the const members of an
implementation class, keeping non-const members private.  Here I have
an actual example:

class Directory {
public:
   Directory(const std::string& path);
   void Refresh();
   using const m_Contents;
private:
   std::vector<Node> m_Contents;
};

This is a situation where the class has the authority to change the
vector of files/directories/symlinks/etc in the directory because it
should reflect reality and the Refresh command is a controlled way to
do it safely, but the user should be able only to read it.  I actually
have a similar class to this one, and ended up having to replicate and
manually pipe through all the const std::vector methods.  It wasn't a
huge deal, 12 member functions I think, but the typing was so automatic
it got me to thinking maybe the compiler could be directed to do this
for me.

Another way to phrase the above solution, for those who prefer private
inheritance, could be:

class Directory : private std::vector<Node> {
public:
   Directory(const std::string& path);
   void Refresh();
   using const std::vector<Node>;
}

Any thoughts?

 -- A Cappella Guy

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

[...]

>
> 2) Public const, private non-const
>
> Automatic support for publicizing the const members of an
> implementation class, keeping non-const members private.  Here I have
> an actual example:
>
> class Directory {
> public:
>    Directory(const std::string& path);
>    void Refresh();
>    using const m_Contents;
> private:
>    std::vector<Node> m_Contents;
> };
>

[...]

>
> class Directory : private std::vector<Node> {
> public:
>    Directory(const std::string& path);
>    void Refresh();
>    using const std::vector<Node>;
> }
>
> Any thoughts?
>
>  -- A Cappella Guy
>

For those cases, simply adding a function that returns
the const object solve the problem and IMHO is better.

class Directory {
public:
    const std::vector<Node> &GetContent() const {
        return m_Contents;    // or *this is second case
    };
};


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]