why need constraints?

[Ian Lazarus]

Why are constraints needed? In C++, an attempt to use a non-existing method
will cause a compiler error. Isn't that true in C# also?

[Lebesgue]

I am not sure to what constraints are you referring (maybe database
constraints?)

But the answer to your question is yes, C# compiler will not compile a code
that would be calling a nonexistent method.

"Ian Lazarus" <no****@nowhere.com> wrote in message
news:qW******************@bgtnsc05-news.ops.worldnet.att.net...

Why are constraints needed? In C++, an attempt to use a non-existing
method will cause a compiler error. Isn't that true in C# also?

[Arnaud Debaene]

"Ian Lazarus" <no****@nowhere.com> a écrit dans le message de news:
qW******************@bgtnsc05-news.ops.worldnet.att.net...

Why are constraints needed? In C++, an attempt to use a non-existing
method will cause a compiler error. Isn't that true in C# also?

If you're speaking about Generics constraints, there are IMHO 2 main reasons
for that :

- Generics syntax and semantic is checked before the generic is instanciated
(generics are instanciated at run time, not at compile time). Therefore,
when the compiler "sees" and checks a generic' source, it couldn't make any
diagnostics if it hadn't an idea on what the instanciation type will look
like.

- Many people claims that C++ templates are hard to use because the
"constraints" in the code (the instanciation type must provide such and such
method for example) are not clearly expressed, but are messed up inside the
template implementation. This make is very difficult to use templates as a
"black box" library because very often the library user must dive deep
inside the library source details to understand the requirements on the
instanciation types he provides to the library.
This is also what make the C++ template compiler error messages notoriously
very hard to read and understand.

Btw, there are several proposals for the next C++ standard (C++0x) to add
the notion of "Concepts", which are very similar to C# generics constraints.
See
http://www.cs.rice.edu/~jgs3847/pubs...epts_cpp0x.pdf
for an example of what it may looks like.

Arnaud
MVP - VC

[Barry Kelly]

"Ian Lazarus" <no****@nowhere.com> wrote:

Why are constraints needed? In C++, an attempt to use a non-existing method
will cause a compiler error. Isn't that true in C# also?

In C++, the constraints on the type arguments are implicit based on the
way the type is used in the body of the template, and don't get fully
validated until you instantiate them by passing type arguments to them
at compile time - because it's only then that the type argument can be
tested for all the constraints expected of it. (That can lead to
confusing errors.)

..NET generics aren't instantiated at compile time - instead they're
instantiated at runtime. Amongst other things, that means that the whole
bodies of generic classes and methods get fully compiled to MSIL object
code without the type arguments being known. In order to do that, there
must be some reference to (for example) the MethodRef or MethodDef for
method calls, and the FieldRef or FieldDef for field accesses (these are
the metadata tokens used in MSIL to refer to fields and methods). Where
are these methods and fields to come from if the type arguments aren't
known? They come from the generic type argument constraints, which can
specify an inheritance relationship, reference or value type, default
constructor and implemented interfaces.

-- Barry

[Bruce Wood]

The answer lies in the difference between C# generics and C++
templates. Although they appear similar on the surface, underneath
they're quite different.

C++ templates are, more or less, simply a matter of text expansion: the
compiler simply plugs the type(s) that you supply into the template and
then compiles the resulting text. (It's a bit more complex than that,
but that's the nut of it.) So, as you pointed out, any attempt to call
methods that don't exist _on the types you supplied_ results in a
compiler error during the template expansion.

C# generics are different. They're supported by the runtime. This has
several advantages, including that you can use Reflection to create new
types from generic types at runtime, whereas in C++ templates don't
actually exist at runtime: they're purely compiler constructs. As well,
it solves certain problems with versioning: if you use a C# generic
from another assembly, you get the version of that generic supplied by
the assembly that is loaded at runtime, not necessarily the version
with which you compiled the client assembly.

Anyway, C# generics are different. The generic itself is compiled into
the .NET assembly, and then the generic is expanded into (a) concrete
type(s) at runtime, on demand, by the JIT.

However, this means that the C# compiler can't let you call any method
you want to from a generic, and issue compiler errors if the method is
missing. Because the generic is built into a concrete type at runtime,
not at compile time, the compiler has no way of knowing for which
type(s) the generic will be built. So, it has no way of knowing which
method calls are legal and which are not.

This is where constraints come in. Constraints give the C# compiler
additional information about the type(s) with which the generic can be
built by placing restrictions upon the types that can be supplied at
runtime. The compiler can then check method calls and property
references, etc, against the generic constraints, knowing that the
runtime will not allow generic expansion on types that do not meet the
constraints.

BTW, take this babbling with a grain of salt since I'm not actually
using .NET 2.0 yet. :-)