> Christian >If banging your head against a wall hurts, my best advice is
> >to stop banging your head against the wall.

Perhaps I should take my own advice more often.

> Josh> The point of this part of the discussion was that there are
practical
> consequences to the lack of type safety in C++, for both "expert"
> and novices.  Your claim that one can avoid that by using containers,
> references, and no casts, is not true in theory or in practice.

I don't understand what you mean by "lack of type safety in C++" (which was
the statement that started this entire thread).

void foo(const std::string&) { cout << "foo(string)\n"; }
void foo(int) { cout << "foo(int); }

struct A { virtual ~A(); }
struct B : public A { };

void is_cpp_type_safe()
{
    // is this not static type safety?
    foo("bar");
    foo(42);
    // ooops, wrong type...
    foo(is_cpp_type_safe);

    // is this not dynamic type safety?
    A *p = new B;
    if (B *q = dynamic_cast<B *>(p))
        cout << "*p is of type B\n";
    else
        cout << "*p is not of type B\n";
}

Perhaps you mean the fact that by default objects dont carry around their
type? That is, I can certainly do the following:

void bar(const int& N)
    { cout << "please kill me " << *explicit_cast<const std::string *>(&N)
<< endl; }

Sure I can do this. That is called 'subverting the type system'. Are you
saying that this alone means that C++ is not "type safe"?

> >Just because they mention the word 'wrapper' in the context of MC++ means
> >little.
>
> It  means that you have to explicitly write something for each compiled
class
> and function that you want to use.

IFF the language is not one of MC++, C#, VisualBasic, Python, REXX, Java,
Javascript, or any other language that can be compiled to MSIL.

> We were talking about access to non .NET stuff from .NET

OIC. Well I never stated that .NET was magic. It can't know about the
argument passing conventions for an arbitrary language, now can it?

[snip basic use of partial specialisation]

> [..] all of your parameters that are
> used to build these structures need to be defined at compile
> time, and also this meta-language is very awkward to work
> with - it can't take strings or floats as first-class
> parameters, for example.

Of course they must be defined at compile time -- that's what
meta-programming means (at least in C++). I understand that this is not the
case for an interpreted language: you can build up code on the fly and
execute it. That is a very important and powerful technique, and arguably
stronger than C++'s more rigid form of meta-programming. Assuming you can
afford to loose the efficiency and safety of a static type system.

> >Post script. Perhaps you mean generating program source code from a
program?
> >That would qualify as 'meta-programming' as well, although it would seem
a
> >less elegant solution (if only because it requires two stages).
>
> In Ruby and other dynamic languages, there are not separate stages.
> In C++, if one wants to use the full power of the C++ language to
> do the meta-programming, then it would be a separate stage and it
> would involve a system call to a compiler, which is not part of
> the language.  Otherwise, one must work with unexpressive template
> meta language.

I take your point. I could argue that partial specialisation in C++ is not
'unexpressive', except it would be a weak argument. The syntax can become
obtuse to say the least.

> Josh

Christian.