Michiel.Salters@cmg.nl (Michiel Salters) wrote
> Allan_W@my-dejanews.com (Allan W) wrote
> > I'm not so clear on what form it should take... compile-time arrays
> > seems awkward.
>
> Even worse, the proposal demands type information during PREprocessing.
> That type information is generated during processing; implementing it
> demands a time machine.
>
> > I'd prefer to see compile-time operators, in just the same way that
> > sizeof() is often done at compile time. For instance, the ability
> > to say
> >     #if isDerivedFrom(T,U)
> >         // Code
> >     #else
> >         // Code
> >     #endif
> >
> > Other candidates would include isBuiltInType(T), hasDefaultCtor(T),
> > isCopyable(T), isAssignable(T), and so on.
>
> O joy. Now throw in a few exported templates for T, and even EDG
> won't be able to compile it.

Sorry -- next to the #if/#endif code, I should have added a comment
such as "for exposition only." I don't actually care if it's done in
the preprocessor or not -- and I think you've made your point that
it shouldn't be done in the preprocessor. But what I would like is
something with the same level of clarity.

Conditional compilation directives are easy to read and interpret.
Declaring and then specializing templates is not nearly as easy.
I long for a return to the simplicity that the preprocessor offers.

What I really want would be accomplished if there was a SIMPLE way
to say in code that a template parameter:
    Must be CopyConstructable
    Must be DefaultConstructable
    Must be Assignable
    Implements double bar(int)
    Implements bar(double) with any (or no) return type
and also a simple way to specialize a template if (and only if)
all of this is true. I think that Boost or Loki allow us to do
this now, but I'd like to see it become part of the language. I
don't care too much about the syntax, but I'd like to see it
become considerably simpler than it is now.

Maybe C#-style meta-tags? I know we don't want C++ to merge with C#,
but maybe the meta-tags are a good way of adding information to a
class that could be tested at compile time.

    // JUST FOR EXPOSITION!

    // Define a copiable, constructable, assignable class
    // that implements the HappyFeet interface:
    //   "double foo(int)" and "any bar(double)"
    meta("CopyConstructable")     // Meta() would have no
    meta("DefaultConstructable")  // run-time overhead
    meta("Assignable")
    meta("ImplementsHappyFeet")
    class Foo {
       /* ... */
    public:
       double foo(int);
       void * bar(double);
    };

    // A template function that requires copiable, constructable,
    // assignable classes with the HappyFeet interface:
    template<
       meta("CopyConstructable")
       meta("DefaultConstructable")
       meta("Assignable")
       meta("ImplementsHappyFeet")
       class T>
    void baz(T t) { /* ... */ }

Then, get the compiler to automatically generate some Meta tags for
certain predefined concepts, if they are true... for instance, no
need to explicitly declare meta("CopyConstructable") because if the
copy constructor is public, the compiler would assign the
metaproperty automatically.

> > That's why (it seems to me) this is one of the rare proposals where it
> > would be easier to implement in the compiler than in the library...
> > (Please correct me if I'm wrong.)
>
> You're absolutely right; is_pod<T> is a property only the compile knows.

Another great example.

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

Allan_W@my-dejanews.com (Allan W) wrote in message news:<23b84d65.0205211236.3516f0eb@posting.google.com>...
> "Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote in message news:<abvrru$36u$1@news7.svr.pol.co.uk>...
> > Hello
> >
> > The Loki library, and perhaps some others, have added the ability to have
> > features such as compile time typelists and compile time asserts. It would
> > be possible to make these features of the language itself, by adding some
> > elements of a meta language to C++. We already have preprocessor control
> > flow via the #IF and #ELSE etc, so arguably we already have a weak meta
> > language.
>
> I like this idea.
>
> > I would like to propose the concept of a preprocessor vector/array/list of
> > types, complete with the functionality and control necessary to make it
> > useful, such as ability to order classes in the list based upon inheritance
> > relationships etc, and indexing into the list based upon preprocessor
> > constants. This would also benefit from additions such as a preprocessor
> > #ASSERT().
>
> I'm not so clear on what form it should take... compile-time arrays
> seems awkward.

Even worse, the proposal demands type information during PREprocessing.
That type information is generated during processing; implementing it
demands a time machine.

> I'd prefer to see compile-time operators, in just the same way that
> sizeof() is often done at compile time. For instance, the ability
> to say
>     #if isDerivedFrom(T,U)
>         // Code
>     #else
>         // Code
>     #endif
>
> Other candidates would include isBuiltInType(T), hasDefaultCtor(T),
> isCopyable(T), isAssignable(T), and so on.

O joy. Now throw in a few exported templates for T, and even EDG
won't be able to compile it.

> My joy would be complete if I could ask if certain functions, including
> non-static member functions, had been defined... I leave the syntax of
> this to someone wiser than me (there must be many) -- but my main goal
> is to find out if a certain expression will be legal or not, so usual
> conversion rules should apply. (i.e. Foo(Der,Der) would return true if
> there was any Foo that could be unambiguously called with two Der's.)

UniqueType Foo(...);
template <class T> class test{ enum { result=true; } };
template < > class test<UniqueType>{ enum { result=false; } };
test<typeof(Foo(Der,Der)>::result -> compile-time constant

The C++98 version is slightly longer.

> I'm sure there are other useful predicates -- see the Boost library
> for more examples. However, I'd like to see them useful in the
> preprocessor! I know that we're trying to move away from preprocessor
> macros, but I hope we do not plan to move away from conditional
> compilation. If so, I'd like to see some replacement -- and for this
> one particular feature, I think it would make sense to allow the new
> predicates to be used only within a template definition.

Templates already have perfectly fine conditional instantiation;
the only thing needed are type traits - and many of these are
already in Boost. C++0x might add compiler support for them, though.

> > My principle arguments for this is that :
> >
> > ...sufficiently many people see these features as being useful as
> >  use the Loki library.
> > ...the synthax required to use these features would be simplified.
>
> Simple definitions might not matter much, because we're not supposed to
> look at the code anyway... but considering how difficult it is for so
> many compilers to work with the existing definitions, I think it makes
> sense to make them built-in parts of the language. Plus, it's likely to
> compile a lot quicker and result in the same code.

I think we should leave it to the compiler vendors to decide how they
implement these things. Adding them to the Core language is not going
to make compilation significantly faster - how can it really be faster
when the library version is implemented as a one-liner using a built-in?
IIRC Metroworks already does this for Boost typetraits.

> > ...as the compiler has more complete knowledge then the Loki library can
> > ascertain, it could generate better class structures.
>
> That's why (it seems to me) this is one of the rare proposals where it
> would be easier to implement in the compiler than in the library...
> (Please correct me if I'm wrong.)

You're absolutely right; is_pod<T> is a property only the compile knows.


Regards,
--
Michiel Salters

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

> The problem is that CPP happens before any actuall C++ code is touched.
The
> pre-processor doesn't understand the code. isDerivedFrom(T,U) couldn't
work
> until the definitions of T and U were seen by the compiler.

I am reminded that I must be more careful with my choice of wording when
posting. The preprocessor is clearly not the correct candidate for the type
of meta language additions I had in mind. I had in mind a synthax that
clearly differed from the 'code' language. As far as I am aware, the
template synthax was never designed for the uses that have been found for
it. Ingenious as they are, many are difficult for compilers to support (few
do correctly at present). Templates are currently being used to wring out of
the compiler the knowledge it has about the code at compile time. In essence
my suggestion was for a simpler, dedicated meta language layer, that offer
the abilities currently available through libraries like Loki and Boost, and
hopefully much more.

Thanks,

D   ire Stockdale



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

In article <ach2rt$5u9$1@news8.svr.pol.co.uk>, Solosnake
<solosnake@solosnake.without_this.freeserve.co.uk> writes
>> The problem is that CPP happens before any actuall C++ code is touched.
>The
>> pre-processor doesn't understand the code. isDerivedFrom(T,U) couldn't
>work
>> until the definitions of T and U were seen by the compiler.
>
>I am reminded that I must be more careful with my choice of wording when
>posting. The preprocessor is clearly not the correct candidate for the type
>of meta language additions I had in mind. I had in mind a synthax that
>clearly differed from the 'code' language. As far as I am aware, the
>template synthax was never designed for the uses that have been found for
>it. Ingenious as they are, many are difficult for compilers to support (few
>do correctly at present). Templates are currently being used to wring out of
>the compiler the knowledge it has about the code at compile time. In essence
>my suggestion was for a simpler, dedicated meta language layer, that offer
>the abilities currently available through libraries like Loki and Boost, and
>hopefully much more.

If carefully worked out and genuinely simpler to use than our current
tools I think a proposal in this area would be acceptable (at least for
serious consideration - though I am pretty sure I could give a short
list of people who would want to reject it sight unseen :-)


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

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

"Solosnake" <solosnake@solosnake.without_this.freeserve.co.uk> wrote in message news:<abvrru$36u$1@news7.svr.pol.co.uk>...
> Hello
>
> The Loki library, and perhaps some others, have added the ability to have
> features such as compile time typelists and compile time asserts. It would
> be possible to make these features of the language itself, by adding some
> elements of a meta language to C++. We already have preprocessor control
> flow via the #IF and #ELSE etc, so arguably we already have a weak meta
> language.

I like this idea.

> I would like to propose the concept of a preprocessor vector/array/list of
> types, complete with the functionality and control necessary to make it
> useful, such as ability to order classes in the list based upon inheritance
> relationships etc, and indexing into the list based upon preprocessor
> constants. This would also benefit from additions such as a preprocessor
> #ASSERT().

I'm not so clear on what form it should take... compile-time arrays
seems awkward.

I'd prefer to see compile-time operators, in just the same way that
sizeof() is often done at compile time. For instance, the ability
to say
    #if isDerivedFrom(T,U)
        // Code
    #else
        // Code
    #endif

Other candidates would include isBuiltInType(T), hasDefaultCtor(T),
isCopyable(T), isAssignable(T), and so on.

My joy would be complete if I could ask if certain functions, including
non-static member functions, had been defined... I leave the syntax of
this to someone wiser than me (there must be many) -- but my main goal
is to find out if a certain expression will be legal or not, so usual
conversion rules should apply. (i.e. Foo(Der,Der) would return true if
there was any Foo that could be unambiguously called with two Der's.)

I'm sure there are other useful predicates -- see the Boost library
for more examples. However, I'd like to see them useful in the
preprocessor! I know that we're trying to move away from preprocessor
macros, but I hope we do not plan to move away from conditional
compilation. If so, I'd like to see some replacement -- and for this
one particular feature, I think it would make sense to allow the new
predicates to be used only within a template definition.

> My principle arguments for this is that :
>
> ...sufficiently many people see these features as being useful as use the
> Loki library.
> ...the synthax required to use these features would be simplified.

Simple definitions might not matter much, because we're not supposed to
look at the code anyway... but considering how difficult it is for so
many compilers to work with the existing definitions, I think it makes
sense to make them built-in parts of the language. Plus, it's likely to
compile a lot quicker and result in the same code.

> ...as the compiler has more complete knowledge then the Loki library can
> ascertain, it could generate better class structures.

That's why (it seems to me) this is one of the rare proposals where it
would be easier to implement in the compiler than in the library...
(Please correct me if I'm wrong.)

> ...I do not believe it would be difficult to implement.
> ...C++ template synthax makes it a powerful code generation language. These
> features would greatly enhance that.

I think there's a potential to abuse them, but that's true with any
language feature. Besides, the current definitions can also be abused!
The libraries exist because so many people want to use them... so it
makes sense to make them part of the language.

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

> > The Loki library, and perhaps some others, have added the ability to
have
> > features such as compile time typelists and compile time asserts. It
would
> > be possible to make these features of the language itself, by adding
some
> > elements of a meta language to C++. We already have preprocessor control
> > flow via the #IF and #ELSE etc, so arguably we already have a weak meta
> > language.
>
> I like this idea.

I think in fact C++ templates are Turing powerful (please correct me if I am
wrong!), which means they are a meta-language: any computable function can
be written using templates... (despite the syntax being sometimes a bit
awkward)

Templates are in fact very close to functional languages like ML. Actually I
was hoping to write a book when I graduate on template meta-programming - ML
was going to be used to explain things like functional programming, lists
and recursion etc., but I guess Andrei beat me to it...

> I'd prefer to see compile-time operators, in just the same way that
> sizeof() is often done at compile time. For instance, the ability
> to say
>     #if isDerivedFrom(T,U)
>         // Code
>     #else
>         // Code
>     #endif
>
> Other candidates would include isBuiltInType(T), hasDefaultCtor(T),
> isCopyable(T), isAssignable(T), and so on.

The problem is that CPP happens before any actuall C++ code is touched. The
pre-processor doesn't understand the code. isDerivedFrom(T,U) couldn't work
until the definitions of T and U were seen by the compiler. So either:

    - you increase the complexity of CPP so that it understands C++
    - make another "preprocessing" pass after the code was compiled

I am sure you can see the problems with both of those.

Tom





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

Hello

The Loki library, and perhaps some others, have added the ability to have
features such as compile time typelists and compile time asserts. It would
be possible to make these features of the language itself, by adding some
elements of a meta language to C++. We already have preprocessor control
flow via the #IF and #ELSE etc, so arguably we already have a weak meta
language.

The Loki library is attempting to derive as much knowledge about the code
that it can from the compiler, through the use of templates and the
standard's template synthax rules. Its compile time assert makes use of the
fact that zero sized arrays are illegal, and forces the creation of one when
the assertion fails, which produces a compile time error. It would be much
nicer if the compiler and preprocessor combined co-operated with the
programmer much more. At compile time the compiler has a lot of knowledge
about classes and their hierarchy that is currently going unused. It is this
knowledge that the Loki library attempts to glean via templates, to allow
concepts such as typelists etc.

I would like to propose the concept of a preprocessor vector/array/list of
types, complete with the functionality and control necessary to make it
useful, such as ability to order classes in the list based upon inheritance
relationships etc, and indexing into the list based upon preprocessor
constants. This would also benefit from additions such as a preprocessor
#ASSERT().

My principle arguments for this is that :

...sufficiently many people see these features as being useful as use the
Loki library.
...the synthax required to use these features would be simplified.
...as the compiler has more complete knowledge then the Loki library can
ascertain, it could generate better class structures.
...I do not believe it would be difficult to implement.
...C++ template synthax makes it a powerful code generation language. These
features would greatly enhance that.

I would be interested in hearing the communities opinions.

Thanks,

D   ire Stockdale


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