Novice question about inherited constructors

[Oleg Subachev]

I am moving from Delphi to C# and hve encountered the problem:

I have the following classes and form Load event handler:

public class class1
{
public string S;
public class1( string aS )
{
S = aS;
}
}

public class class2 : class1
{
}

private void Form1_Load(obje ct sender, System.EventArg s e)
{
class2 C2 = new class2( "string" );
label1.Text = C2.S;
}

When I try to compile I get the following errors:

No overload for method 'class1' takes '0' arguments
No overload for method 'class2' takes '1' arguments

What does it mean ?
Why inherited constructors are not used (as in Delphi) ?

Oleg Subachev

[Peter Rilling]

That is just part of the design of .NET that constructors are not inherited.
If you have a non-default constructor in a base class, you must also define
that same constructor and then pass the value up to its base.

public class2(string aS) : base(aS){...}
"Oleg Subachev" <ol**@urvb.ru > wrote in message
news:e$******** ******@TK2MSFTN GP02.phx.gbl...

I am moving from Delphi to C# and hve encountered the problem:

I have the following classes and form Load event handler:

public class class1
{
public string S;
public class1( string aS )
{
S = aS;
}
}

public class class2 : class1
{
}

private void Form1_Load(obje ct sender, System.EventArg s e)
{
class2 C2 = new class2( "string" );
label1.Text = C2.S;
}

When I try to compile I get the following errors:

No overload for method 'class1' takes '0' arguments
No overload for method 'class2' takes '1' arguments

What does it mean ?
Why inherited constructors are not used (as in Delphi) ?

Oleg Subachev

[Jon Skeet [C# MVP]]

Oleg Subachev wrote:

I am moving from Delphi to C# and hve encountered the problem:
<snip>
When I try to compile I get the following errors:

No overload for method 'class1' takes '0' arguments
This is because the compiler is creating a default constructor for
class2, which tries to call a parameterless constructor in class1 - but
there isn't one.
No overload for method 'class2' takes '1' arguments
This is because there isn't a constructor in class2 taking a string,
because constructors aren't inherited.
Why inherited constructors are not used (as in Delphi) ?

If constructors were inherited, then *all* classes would have to have a
parameterless constructor, as System.Object does. I don't know how
Delphi gets around it, but personally I'm glad constructors aren't
inherited - it's good to be able to mandate that any instance of a
certain class *must* go through one of the constructors I've specified,
even if extra constructors have been added to the base class.

I view instance creation as somewhat different to instance use - things
which can be treated the same way after they've been created often have
very different creation requirements.

(Having said that, I *would* like some way of specifying what
constructors *must* be present in any type implementing a specific
interface, and possibly likewise for static methods. Extra syntax would
be necessary in order to call those constructors/static methods,
however - it does all get a bit complicated.)

Jon

[the.duckman]

Hey Jon,

(Having said that, I *would* like some way of specifying what
constructor s *must* be present in any type implementing a specific
interface, and possibly likewise for static methods. Extra syntax would
be necessary in order to call those constructors/static methods,
however - it does all get a bit complicated.)

I think that Idea causes some problems with the concept of an
interface. But I would like to a concept similar to an interface called
a "performa", the performa being what you described above. I feel some
tasks just don't relate to an interface and need something similar to
friend classes or something.

A classic example would be ISerializable. The concept of the interface
is not enought to encapuslate deserialisation (which requires a special
constructor).

It would be nice if the constructor often found when using
ISerializable was enforced. As such the serilaisation/deserialsation
requires a concept stronger than an interface.

So basicly Im with you, we need a way to enforce constructors... .

I do however recall an article "somewhere" that explains why this is
"might" not possible under the CLR.

-dm

[Joanna Carter [TeamB]]

<th*********@gm ail.com> a écrit dans le message de news:
11************* *********@i40g2 00...legr oups.com...

| It would be nice if the constructor often found when using
| ISerializable was enforced. As such the serilaisation/deserialsation
| requires a concept stronger than an interface.

How about a constraint like with generics ?

public interface ISerializable requires new()
{

}

....or perhaps a special method syntax, like the property declaration :

public interface ISerializable
{
.ctor();
}

What think you ???

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Jon Skeet [C# MVP]]

Joanna Carter [TeamB] wrote:

| It would be nice if the constructor often found when using
| ISerializable was enforced. As such the serilaisation/deserialsation
| requires a concept stronger than an interface.

How about a constraint like with generics ?

That would be fine, except the only constraint available is that
there's a public parameterless constructor. It would often be nice to
be able to specify constructors with parameters, and this ability
doesn't exist with generics.

In addition, serialization itself recommends using a protected or
private constructor, which quite reasonably can't be expressed as a
constraint. Serialization is a pretty specialised area - I wouldn't
want to bend the platform too much to aid it. However, various things
which are dynamically loaded would benefit from enforcing some way of
constructing an instance (whether by a factory method or a
constructor).

Jon

[David]

How is
public class A
{
public A(){}
}
different from
public class B : A
{
public B() : base()
{}
}
"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:11******** **************@ i39g2000cwa.goo glegroups.com.. .

Oleg Subachev wrote:

I am moving from Delphi to C# and hve encountered the problem:

<snip>

When I try to compile I get the following errors:

No overload for method 'class1' takes '0' arguments

This is because the compiler is creating a default constructor for
class2, which tries to call a parameterless constructor in class1 - but
there isn't one.

No overload for method 'class2' takes '1' arguments

This is because there isn't a constructor in class2 taking a string,
because constructors aren't inherited.

Why inherited constructors are not used (as in Delphi) ?

If constructors were inherited, then *all* classes would have to have a
parameterless constructor, as System.Object does. I don't know how
Delphi gets around it, but personally I'm glad constructors aren't
inherited - it's good to be able to mandate that any instance of a
certain class *must* go through one of the constructors I've specified,
even if extra constructors have been added to the base class.

I view instance creation as somewhat different to instance use - things
which can be treated the same way after they've been created often have
very different creation requirements.

(Having said that, I *would* like some way of specifying what
constructors *must* be present in any type implementing a specific
interface, and possibly likewise for static methods. Extra syntax would
be necessary in order to call those constructors/static methods,
however - it does all get a bit complicated.)

Jon

[Jon Skeet [C# MVP]]

David <Co*********@Ad sorptionProcess Modeling.com> wrote:

How is
public class A
{
public A(){}
}
different from
public class B : A
{
public B() : base()
{}
}

The first declares a type which derives from System.Object
(implicitly). The second declares a type which derives from A. Both
declare a public parameterless constructor which calls (implicitly in
the first case) the parameterless constructor in the base class.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[David]

Thank you. I am actually trying to figure out why a TreeView works when
nodes are constructed using the TreeNode class but do not work when using a
class derived from TreeNode.

What is the difference between

public class TreeNode
{
public TreeNode()
{
}

}

and

public class B : TreeNode
{
public B : base()
{}

}

?

Why does an index go out of range in LoadViewState with the later.
"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

David <Co*********@Ad sorptionProcess Modeling.com> wrote:

How is
public class A
{
public A(){}
}
different from
public class B : A
{
public B() : base()
{}
}

The first declares a type which derives from System.Object
(implicitly). The second declares a type which derives from A. Both
declare a public parameterless constructor which calls (implicitly in
the first case) the parameterless constructor in the base class.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

David <Co*********@Ad sorptionProcess Modeling.com> wrote:

Thank you. I am actually trying to figure out why a TreeView works when
nodes are constructed using the TreeNode class but do not work when using a
class derived from TreeNode.

What is the difference between

public class TreeNode
{
public TreeNode()
{
}

}

and

public class B : TreeNode
{
public B : base()
{}

}

?
Not a lot.
Why does an index go out of range in LoadViewState with the later.

I'm afraid I don't know.

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too