So I started tinkering with C# and found it to be pretty easy to pick up.
Now I have never worked with any of the C languages before, but I was able
to figure out how to inherit a class and make use of it. Ok so now I have a
little test project that does exactly what my VB.NET test project did. I
can inherit one base class. However, will C# let me take it to the next
level and inherit more than one base class? I have tried using a comma to
separate classes (it looks like thats how you do it in C++), but I get an
error saying that the interface was not found or something like that. So I
have been reading and so far have not found anywhere where it says I can do
what I want to do. Is it possible? I did read that you can use multiple
inheritance with C# if you are just using the interface inheritance. But
thats not what I want to do. I actually want to have 2 base classes that
contain code, that I can then inherit and make use of that code in my
derived class.
Can anyone tell me if this is possible using C# and if so, the syntax to do
so? Or would I be better off just moving to C++ (I hope not). Thanks a
lot.
Dave Zehner
--
Mario G. Contreras, MS MVP - VB LatAm
Universidad del Valle de Atemajac
Database administrator
marioc at mvps dot org
http://www.mvps.org/marioc/
"Dave Zehner" <dze...@verticalscreen.com> wrote in message
news:#WxR15CoBHA.2440@tkmsftngp05...
| ...
--
/Per
______________________________
Per Hultqvist, MCP
> "Dave Zehner" <dze...@verticalscreen.com> wrote in message
news:#WxR15CoBHA.2440@tkmsftngp05...
> Can anyone tell me if this is possible using C# and if so, the syntax to
do
> so? Or would I be better off just moving to C++ (I hope not). Thanks a
> lot.
you can inherit from one base class and multiple interfaces. Instead of
moving to C++ you should redesign your concept. If you remember, MFC doesn't
use multiple inheritance either.
There are so many disadvantages of multiple inheritance, that it was removed
from the languages since Java.
Joachim
Ok so now lets suppose I redesign my model and now I have to decide to use
VB.NET or C#. Which one do I use? All I'm trying to do is build some
classes that can load and save data from the DB. So for instance a Person
class that has properties on it like, Name, Addres, etc .... and methods
like Load and Save. Pretty straight-forward stuff.
Whichever language I decide to go with there will be a learning curve with.
However, I would assume VB.NET would be easier since I've been using VB for
5 years now. But I also like the idea of learning something new and I have
the time to learn it. Does C# give me anything really special over VB.NET
that would encourage me to use it, other than I want to learn something new?
Keeping in mind what I'm going to be building some opinions would be
helpful. Thanks.
DZ
"Joachim Fuchs" <nospam....@fuechse-online.de> wrote in message
news:umrH#EDoBHA.2024@tkmsftngp03...
I don't know of a lot of differences, but to name a few :
* C# does have operator overloading (not used very often, and you can live
without it)
* C# is case sensitive
* C# is in MY OPINION much clearer and more consistent in its design (for
obvious reasons).
* VB.Net has the WITH-statement, C# does not have an equal statement
* VB.Net is NOT case sensitive
...and there are, I'm sure, many more differences (feel free to complete the
list anyone). I found myself thinking about the exact same questions a while
back, C# or VB.Net? VB.Net or C#?
Here is what I did. At work I use VB, so I figured that we will soon use
VB.Net for new projects. Therefor I started using C# at home, when I'm doing
my own research, and soon I will know both languages AND the framework.
Sounds like a plan?
Basically, learning the keywords in VB.Net or C# takes a couple of days or
weeks. It's the framework, class library and everything else that takes the
most time to learn anyway...Learn both, and if you MUST choose, I would
choose C#.
--
/Per
_______________
Per Hultqvist, MCP
"Dave Zehner" <dze...@verticalscreen.com> wrote in message
news:#WxR15CoBHA.2440@tkmsftngp05...
Though, as others have said, you can always redesign your app. to use single
rather than multiple inheritance. Even in C++ most developers use the .Net
and Java approach of single implementation and multiple interface
inheritance.
Kevin
"Dave Zehner" <dze...@verticalscreen.com> wrote in message
news:#WxR15CoBHA.2440@tkmsftngp05...
"Per Hultqvist" <per.hu...@hogia.se> wrote in message
news:eb424EDoBHA.2456@tkmsftngp03...
It may also depend on what type of applications you intend to work on. C#
can make use of unmanaged code - pointers, etc. - but VB .NET can't. This
may be important for interoperability with legacy COM components for
example.
If you're just going to be writing pure .Net applications then there's not
much in it and it's largely a matter of taste. Many VB developers don't like
C-style syntax. Others are more relaxed about it.
For the *specific* application you describe below it certainly makes no
difference whether you go with C# or VB.NET.
Kevin
"Dave Zehner" <dze...@verticalscreen.com> wrote in message
news:OBIqiLDoBHA.1684@tkmsftngp03...
ask that question in another NG and it will become one of those nerver
ending threads. Here, you will probably hear, why people like me, have moved
from VB to C#.
Comparing the syntax of control statements (with, while, select ...) is
really irrelevant. That doesn't make a language better or worse. But there
are a couple of disadvantages in the VB syntax:
the multiple usage of ( ) for arrays, function indexers...
the multiple usage of the "=" operator.
That can become very ugly and ambiguous sometimes.
In C# you are forced to do your coding as the framework expects it to be. In
Vb you can often use old VB programming styles. But that covers the
framework functionality, which is the main part to learn. You may need 10%
for learning the language and 90% for understanding the framework and its
concepts.
If you browse through the newsgroups, you will find a lot of differences,
while mostly C# has the advantages on its side. However, most of my code I
write in C# and some, like calling COM objects, I write in VB. The advantage
of .net is, that you can combine both, not only in theory.
Joachim
Jake
"Dave Zehner" <dze...@verticalscreen.com> wrote in message
news:OBIqiLDoBHA.1684@tkmsftngp03...
i'm learning c#. i hope that vb.net will be easier to learn as a result.
"Per Hultqvist" <per.hu...@hogia.se> wrote in message
news:ODVDfXDoBHA.2168@tkmsftngp05...
I tried using VB.Net and it felt like someone tried their hardest to make
the old syntax work in a new world only to fail miserably in the end. Like
you said, it just didn't "feel" right.
Mike
"Jake the Carpet" <gha...@mediaone.net> wrote in message
news:uLZxOKPoBHA.1592@tkmsftngp05...
There is nothing wrong with multiple inheritance. Just because C++
completely screws up the implementation of MI is no reason to dismiss the
whole notion of MI. Eiffel handles MI in a very elegant manner, and is
available on .NET:
www.eiffel.com
--
Mickey Williams
www.DotNetExperts.com
Why do you say C++ screws up the implementation of MI ?
I know that many people either dislike or abhor MI in C++
but I look at it as any other tool. If it solves a problem, fine, else
don't use it. At the risk of starting up an old flame war I would like
to hear your rationale on this topic. Maybe I can finally see what so
many others are complaining about.
Ed.
You should not be so defensive. If you paid more attention, you would have
noticed that we wasn't attacking C++ MI. Rather, he was explaining how other
people's opinion of it has made them think that any MI language is
unworkable.
--
Jonathan Allen
.Net Wish List Site: http://jonathan.cloverlink.com/
"eck" <nospam-...@adelphia.net> wrote in message
news:ecqLBVgoBHA.2528@tkmsftngp04...
I can't agree with you on that, as I have yet to see an instance where I
would want MI. And it isn't because the C++ version has left a bad taste in
my mouth. I always knew it was available, but never saw a use for it.
--
Jonathan Allen
.Net Wish List Site: http://jonathan.cloverlink.com/
"mickey williams" <m...@codevtech.com> wrote in message
news:urmqqiXoBHA.2340@tkmsftngp03...
I have: Mixins and default implementations of orthogonal interfaces. Those
two cases make it quite worthwhile by themselves, imho.
--
Tomas Restrepo
tom...@mvps.org
Please elaborate
--
Jonathan Allen
.Net Wish List Site: http://jonathan.cloverlink.com/
"Tomas Restrepo" <tom...@mvps.org> wrote in message
news:#AsoUFioBHA.1644@tkmsftngp05...
Yeah yeah yeah, whatever...tired of that discussion... :-)
--
/Per
I do not doubt that you are correct, but another person just wrote : "No
multiple inheritance of implementation in C# - this is actually a
limitation/feature of the CLR." and that is exactly what I have heard. Is
the above statement incorrect (i e CLR DOES support MI) or?
/Per Hultqvist
What I don't know...
How they managed to port Eiffel onto the CLR, and how close it is the
original.
--
Jonathan Allen
.Net Wish List Site: http://jonathan.cloverlink.com/
"Per Hultqvist" <per.hu...@hogia.se> wrote in message
news:eANyxXkoBHA.1864@tkmsftngp04...
>What I know...
> The CLR does not support MI.
> Eiffel does support MI.
>
>What I don't know...
> How they managed to port Eiffel onto the CLR, and how close it is the
>original.
It all has to be done in the Eiffel compiler.
I believe that they made second and subsequent super classes look like
Interfaces to which the compiler provides an implementation by copying
the super-clases implementation. That's one way, anyway.
--
Simon
www.quintuslink.com
A mixin class is esentially a (usually abstract) class that implements some
behavior or capability. When you are developing a class, you can choose from
available behaviors (mixins) to add to your class by simply inheriting from
the respective mixin classes, and possibly overriding a couple of methods.
As for default implementation of interfaces, assume you have interfaces IA
and IB, with default implementations in classes A and B respectively. With
single inheritance, you can only inherit from one of thw two, and you need
to do a full implementation of the other interface, or add another level of
inheritance do do so. With MI, you can simply derive from both A and B to
take advantage of the default implmentations.
--
Tomas Restrepo
tom...@mvps.org
The CLR can't refuse to support what it doesn't know about ;)
> What I don't know...
> How they managed to port Eiffel onto the CLR, and how close it is the
> original.
The original CLR or the original Eiffel? Actually, I think the upcoming
Eiffel 5.2 for .NET will be full Eiffel. Given a class that has multiple
Eiffel base classes, it's not conceptually difficult to see how the compiler
hoists the implementation for each base class into a single implementation
class for the CLR's benefit, with multiple base interfaces provided for
non-Eiffel CLR clients. Multiple Inheritance in Eiffel 5.1 is primarily done
so that the Eiffel libraries can be ported to the CLR. Otherwise, Eiffelists
(who tend to use MI quite a bit) could not port existing code to .NET.
--
Mickey Williams
www.DotNetExperts.com
> I do not doubt that you are correct, but another person just wrote : "No
> multiple inheritance of implementation in C# - this is actually a
> limitation/feature of the CLR." and that is exactly what I have heard. Is
> the above statement incorrect (i e CLR DOES support MI) or?
The CLR does not support MI. Eiffel 5.1 provides multiple inheritance for
Eiffel source code, with more complete support coming later in 5.2. The CLR
does not realize that there's any MI hanky-panky going on - in the compiled
IL, the final class appears to be a single implementation with multiple
interfaces. The multiple interfaces are just for interaction with non-Eiffel
code. The plan is to compile into CLR MI whenever that is available.
--
Mickey Williams
www.DotNetExperts.com
> Why do you say C++ screws up the implementation of MI ?
> I know that many people either dislike or abhor MI in C++
> but I look at it as any other tool. If it solves a problem, fine, else
> don't use it. At the risk of starting up an old flame war I would like
> to hear your rationale on this topic. Maybe I can finally see what so
> many others are complaining about.
What Jonathan said.
For background: Besides consulting and training for .NET Experts, I own a
software company (codev technologies) and we've developed tons of C++ code.
I've written eight books on C++ and Windows programming, and I've used C++
since the Zortech compiler in ~1988. I'm currently writing a C# book. And I
keep getting into these Eiffel threads - mainly because .NET Experts is
part of ISE and we develop the Eiffel compiler for .NET. And I use Eiffel
quite a bit, although I'm probably the worst Eiffelist at ISE; most of my
work currently revolves around teaching people about the CLR and framework
and consulting on C#.
So with that off my chest - In my opinion MI is a problem in C++. At codev
technologies, we've developed lots of components and systems written in C++,
with one commercial product we sell ourselves, also written in C++. I
consider myself an extremely good C++ programmer. But we almost never use MI
in our non-ATL C++ work. Not because it's not useful, not because we can't
figure it out, but for three main reasons:
- The average C++ programmer can't use MI consistently and correctly. When
we develop components, frankly it's a support problem if we use MI. Why does
my this pointer change when I'm debugging? Why do I need to cast my pointer
when I'm returning a reference here? How do I resolve this name clash? Why
can't I mixin these other two classes? etc.
- Clients don't want us to use it. I've developed large systems that could
have used MI to reduce the amount of code written for a project by
flattening the design's static model. But the "MI is bad" mantra from people
who have only used C++ for object-oriented design and programming means that
MI can usually not be used. Actually we consulted on one C++ project a
couple of years ago that used MI quite a bit, but that was on a small team
of much-better than average developers and managers.
- MFC can't handle MI. We have done a lot of work with MFC, and since MFC
was developed with a single-inheritance model, it's just really difficult to
use any sort of significant MI with MFC. You can't have two subclasses of
CObject in your inheritance tree - although you can use lightweight mixins
in some cases, but then you have problems with serialization - the whole MFC
architecture was built on what the MSDN docs call "A Safe Subset of C++".
Hmmf.
If you like MI in C++, use it by all means. But all I'm saying is that MI is
not bad. Every negative issue I've ever seen raised about MI applies to the
C++ version of MI, not to MI in general. MI is a great design tool if you're
using a language that supports it correctly. If you're using it in C++, it's
my opinion that it works, but has lots of sharp edges that you need to be
aware of.
--
Mickey Williams
www.DotNetExperts.com
Class Test
Implements IA
Implements IB
Private m_oA as A
Private m_oB as B
Exposes m_oA.* As IA
Exposes m_oB.* As IB
End Class
The exposes keyword would be used for encapsulation, It would expose the
methods of a contained type as if you had taken the time and effort to
manually write all the wrapper methods.
When polymorphism is not needed, this will also allow you to pseudo-inherit
sealed classes.
--
Jonathan Allen
.Net Wish List Site: http://jonathan.cloverlink.com/
"Tomas Restrepo" <tom...@mvps.org> wrote in message
news:uSp0h3ooBHA.2184@tkmsftngp02...
Well, I guess that would work, but you'd loose two important features: 1-
Interfaces, and 2- OIverridability. Both would take more work than your
exposes proposal (more in the first than in the second).
--
Tomas Restrepo
tom...@mvps.org
They are covered. The below line means "expose all the methods of m_oA and
wire them to the interface IA. (Yea, I know the syntax needs work.)
> > Exposes m_oA.* As IA
If you wanted to expose it without wiring it to an interface you would use
one of these...
Public Exposes m_oA.* //all of them
Public Exposes m_oA.Run(*) //all of Run methods
Public Exposes m_oA.Run(String) //just the run method that takes a string
> 2- OIverridability. Both would take more work than your
> exposes proposal (more in the first than in the second).
That can be handled by putting the appropriate modifier in front of Exposes.
For example...
Public Overridable Exposes m_oA.Run(String)
--
Jonathan Allen
.Net Wish List Site: http://jonathan.cloverlink.com/
"Tomas Restrepo" <tom...@mvps.org> wrote in message
news:O$l7oTtoBHA.2080@tkmsftngp07...
"Dave Zehner" <dze...@verticalscreen.com> wrote in message
news:#WxR15CoBHA.2440@tkmsftngp05...
> I was recently dissapointed when I installed VB.ET and found that I could
> only inherit one base class. Yes, yes, I know that I can implement more
> than one, but what I really wanted to do was inherit more than one.
>
> So I started tinkering with C# and found it to be pretty easy to pick up.
> Now I have never worked with any of the C languages before, but I was able
> to figure out how to inherit a class and make use of it. Ok so now I have
a
> little test project that does exactly what my VB.NET test project did. I
> can inherit one base class. However, will C# let me take it to the next
> level and inherit more than one base class? I have tried using a comma to
> separate classes (it looks like thats how you do it in C++), but I get an
> error saying that the interface was not found or something like that. So
I
> have been reading and so far have not found anywhere where it says I can
do
> what I want to do. Is it possible? I did read that you can use multiple
> inheritance with C# if you are just using the interface inheritance. But
> thats not what I want to do. I actually want to have 2 base classes that
> contain code, that I can then inherit and make use of that code in my
> derived class.
>
> Can anyone tell me if this is possible using C# and if so, the syntax to
do
> so? Or would I be better off just moving to C++ (I hope not). Thanks a
> lot.
>
> Dave Zehner
>
>
I've been programming in VB for the past five years and I haven't had much
difficulty learning C#. I then went and bought the '.NET quick translation
guide (ISBN 1893115488)' and learning VB.net has been a seamless
experience... since both languages are surprisingly similar in a non
syntactical sense... So my advice is even as a VB programmer go for C#.
Cheers
Jean
"Joachim Fuchs" <nospam....@fuechse-online.de> wrote in message
news:uuenL8DoBHA.1620@tkmsftngp02...
"Jake the Carpet" <gha...@mediaone.net> wrote in message
news:uLZxOKPoBHA.1592@tkmsftngp05...