cdiggins@videotron.ca ("christopher diggins") wrote in message news:<Uv7jc.55234$2V6.523066@wagner.videotron.net>...

> > I believe I could write macros to allow you to generate baz with:
> >
> > DECLARE_INTERFACE(
> >     baz,
> >     ((int)(foo)(int))
> >     ((int)(bar)(char const*))
> > );
>
> I would very much like to see and use those macros.

If I get a few minutes maybe I'll hack them up for fun.

> > Rather than accept a language extension for this one feature, I hope
> > we will get metaprogramming facilities that allow programmers to more
> > easily build this sort of class without relying so heavily on
> > preprocessor magic
>
> Why do you suggest the interfaces proposal should be ignored?

That's really unfair.  Haven't I just spent many messages *not
ignoring* your ideas?

> It is clearly
> as good a candidate for a language extension as any, because it is a
> complete, self-contained, well-defined, well-understood concept.

It's not any of those things, yet, by the standards of the C++
standard.
Even if you disagree, those elements, in themselves, don't make it as
good a candidate as any.  There's also the question of how much "bang"
one gets for the cost of introducing a language feature.

> I am not
> saying that we shouldn't have better metaprogramming facilities, but should
> they usurp other language proposals?

If a metaprogramming facility would give us the potential to implement
proposals like yours as libraries instead of core language features,
it would make a great deal of sense to do so.  Then we can gain
experience with and tweak the design, and  specification becomes much
easier because you don't have to describe interactions with other core
language features, and it keeps the core language standard smaller,
and... <so many other benefits I can't list them all>.

If no such facility is going to come along, we shouldn't keep all
other proposals waiting.  It's just that thinking of your language
feature proposal as a library condenses so many of the problems we'd
already like to solve well for C++0x (forwarding, structure
introspection, type generation...) into one place that it'd be a real
shame if it weren't possible.  So, I really hope that we'll have a
language that'll let us build interface references as a library
(without macros), and that we don't have to accept a new language
feature just to get the capability.

--
David Abrahams
boost consulting
http://www.boost-consulting.com

---
[ 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                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:8a638f47.0404300919.f496961@posting.google.com...
> cdiggins@videotron.ca ("christopher diggins") wrote in message
news:<Uv7jc.55234$2V6.523066@wagner.videotron.net>...
>
> > > I believe I could write macros to allow you to generate baz with:
> > >
> > > DECLARE_INTERFACE(
> > >     baz,
> > >     ((int)(foo)(int))
> > >     ((int)(bar)(char const*))
> > > );
> >
> > I would very much like to see and use those macros.
>
> If I get a few minutes maybe I'll hack them up for fun.

Please do, they would be very useful for myself and others.

> > > Rather than accept a language extension for this one feature, I hope
> > > we will get metaprogramming facilities that allow programmers to more
> > > easily build this sort of class without relying so heavily on
> > > preprocessor magic
> >
> > Why do you suggest the interfaces proposal should be ignored?
>
> That's really unfair.  Haven't I just spent many messages *not
> ignoring* your ideas?

Yes you have been giving fair attention to my ideas, and I apologize for
having suggested that you hadn't. You stated that better metaprogramming
facilities would be preferable to the interface porposal, which I took,
perhaps unfairly so, as an implication that time and energy would be more
wisely spent if we ignored the interface proposal and instead worked on
metaprogramming. I apologize for having read between the lines too much.

I would really like to know more about the metaprogramming facilities
proposal that you refer to and learn how we could use them to build
interface references.

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ 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                       ]

On Mon, 26 Apr 2004 18:30:17 +0000 (UTC), cdiggins@videotron.ca
("christopher diggins") wrote:

>> Rather than accept a language extension for this one feature, I hope
>> we will get metaprogramming facilities that allow programmers to more
>> easily build this sort of class without relying so heavily on
>> preprocessor magic
>
>Why do you suggest the interfaces proposal should be ignored? It is clearly
>as good a candidate for a language extension as any, because it is a
>complete, self-contained, well-defined, well-understood concept. I am not
>saying that we shouldn't have better metaprogramming facilities, but should
>they usurp other language proposals?

If they allow you to turn language proposals into library proposals,
that doesn't really usurp those language proposals, rather makes them
more likely to be accepted.

However, I'm not sure any realistic amount of metaprogramming support
is going to give you nice syntax for this in a pure library based
implementation of "interfaces" or "signatures".

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

---
[ 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                       ]

cdiggins@videotron.ca ("christopher diggins") writes:

>> You misinterpreted my point.  I wasn't suggesting that interface
>> references have the same syntax as pointers.  My point was that even
>> if you don't like references, if you can apply operator* to an
>> interface pointer you have to say what type that is.  So your
>> interface pointers lead inevitably to interface references.
>
> I still miss your point then. The proposal is for a type (call it whatever
> you want) that can refer to any object that implements a particular set of
> function signatures. Calling it a pointer or a reference would be
> misleading. This type can not be dereferenced.
>
>> Incidentally, I believe that nothing prevents an implementation from
>> making an optimization like the one you desire for ABCs today, that
>> the "interface" keyword is probably unneeded, and that your proposal's
>> standard language is probably phrased way too much in terms of
>> low-level details that may not be appropriate to any particular
>> implementation and not enough in terms of the abstract C++ machine.
>
> What I am talking about has nothing to do with ABC's. It has nothing to do
> neither with virtual functions. I am sorry if I have made it sound that way.
> It is a way to refer to objects which implement a particular interface.

Let me see if I understand you.  You would like to be able to
generate something like baz below with much less syntax, right?

I believe I could write macros to allow you to generate baz with:

DECLARE_INTERFACE(
    baz,
    ((int)(foo)(int))
    ((int)(bar)(char const*))
);

Rather than accept a language extension for this one feature, I hope
we will get metaprogramming facilities that allow programmers to more
easily build this sort of class without relying so heavily on
preprocessor magic

[2. text/x-cplusplus; foo.cpp]

// a baz "interface"
class baz
{
 private: // forward declarations
    template <class T>
    struct functions;

 public: // interface
    template <class T>
    baz(T& x)
      : _m_a(&x), _m_t(&functions<T>::table)
    {}

    int foo(int x)
    { return _m_t->foo(const_cast<void*>(_m_a), x); }

    int bar(char const* x)
    { return _m_t->bar(const_cast<void*>(_m_a), x); }

 private:
    // Function table type for the baz interface
    struct table
    {
        int (*foo)(void*, int x);
        int (*bar)(void*, char const*);
    };

    // For a given referenced type T, generates functions for the
    // function table and a static instance of the table.
    template <class T>
    struct functions
    {
        static baz::table const table;

        static int foo(void* p, int x)
        { return static_cast<T*>(p)->foo(x); }

        static int bar(void* p, char const* x)
        { return static_cast<T*>(p)->bar(x); }
    };

    void const* _m_a;
    table const* _m_t;
};

template <class T>
baz::table const
baz::functions<T>::table = {
    &baz::functions<T>::foo
  , &baz::functions<T>::bar
};

#include <cstring>
#include <cstdio>

struct some_baz
{
    int foo(int x) { return x + 1; }
    int bar(char const* s) { return std::strlen(s); }
};

struct another_baz
{
    int foo(int x) { return x - 1; }
    int bar(char const* s) { return -std::strlen(s); }
};

int main()
{
    some_baz f;
    another_baz f2;

    baz p = f;

    std::printf("p.foo(3) = %d\n", p.foo(3));
    std::printf("p.bar(\"hi\") = %d\n", p.bar("hi"));

    p = f2;

    std::printf("p.foo(3) = %d\n", p.foo(3));
    std::printf("p.bar(\"hi\") = %d\n", p.bar("hi"));
}


--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ 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                       ]

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:8a638f47.0404250644.438ff224@posting.google.com...
> cdiggins@videotron.ca ("christopher diggins") writes:
>
> >> You misinterpreted my point.  I wasn't suggesting that interface
> >> references have the same syntax as pointers.  My point was that even
> >> if you don't like references, if you can apply operator* to an
> >> interface pointer you have to say what type that is.  So your
> >> interface pointers lead inevitably to interface references.
> >
> > I still miss your point then. The proposal is for a type (call it
whatever
> > you want) that can refer to any object that implements a particular set
of
> > function signatures. Calling it a pointer or a reference would be
> > misleading. This type can not be dereferenced.
> >
> >> Incidentally, I believe that nothing prevents an implementation from
> >> making an optimization like the one you desire for ABCs today, that
> >> the "interface" keyword is probably unneeded, and that your proposal's
> >> standard language is probably phrased way too much in terms of
> >> low-level details that may not be appropriate to any particular
> >> implementation and not enough in terms of the abstract C++ machine.
> >
> > What I am talking about has nothing to do with ABC's. It has nothing to
do
> > neither with virtual functions. I am sorry if I have made it sound that
way.
> > It is a way to refer to objects which implement a particular interface.
>
> Let me see if I understand you.  You would like to be able to
> generate something like baz below with much less syntax, right?

That is pretty close to what I want. BTW the proposal has been modified and
contains more detail at http://www.heron-language.com/cpp-iop.html

> I believe I could write macros to allow you to generate baz with:
>
> DECLARE_INTERFACE(
>     baz,
>     ((int)(foo)(int))
>     ((int)(bar)(char const*))
> );

I would very much like to see and use those macros.

> Rather than accept a language extension for this one feature, I hope
> we will get metaprogramming facilities that allow programmers to more
> easily build this sort of class without relying so heavily on
> preprocessor magic

Why do you suggest the interfaces proposal should be ignored? It is clearly
as good a candidate for a language extension as any, because it is a
complete, self-contained, well-defined, well-understood concept. I am not
saying that we shouldn't have better metaprogramming facilities, but should
they usurp other language proposals?

--
Christopher Diggins
http://www.cdiggins.com
http://www.heron-language.com

---
[ 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                       ]