What I don't like about C# so far, compared to C++ (managed or otherwise)

[raylopez99]

First in an occasional series.

I'm somewhat experienced in C++, and am using .NET Visual Studio 2005
as the IDE. I'm learning C#.

What I don't like about C#, compared to C++ (all flavors):

1/ no pointers or tracking pointers or handles--this is absurd. I
realise references are by and large like tracking pointers effectively
(does anybody know of any differences--other than pointer arithmetic,
which you cannot do anymore in managed C++ anyway, I don't see any big
differences so far), but why not leave pointers in? When porting code
it's a pain to have to convert to references.

2/ no read-only "const" modifier for objects; just for data members
(public const int wheel = 4 // is OK in C#). See below*** How to you
avoid accidentally changing an object passed to a function--unless
you're very careful with your coding?

3/ static classes not supported. A minor gripe but still

4/ Sparse to non-existant library. For example, no linked list (you
have to roll your own). I was pleasantly surprised that a dynamically
sized array exists in C#--whoo hoo!--progress.

5/ Iterrators are kind of primitive ("for each * in"); though today I
learned IEnumerable is supported in C#--more progress.

6/ No copy constructor, though with managed C++ that's pretty much
gone away.

7/ stupid "in-line" class definitions. Ridiculous. .h and .cpp files
work fine and are logical--why get rid of them?

8/ C# programmers seem more junior than C++ programmers (not that I'm
a code guru, but that seems to be true).

9/ stuff like ADO.NET only supported on C#.

10/ multiple class inheritances and interfaces not supported. Not
that I really am a big fan of multiple inherietance or interfaces
anyway, since I usually nest classes or use composite classes unless I
cannot avoid using inheritance, like with dynamic runtime binding of
objects, so it's a minor gripe for me, but others I'm sure are
bothered by it.

I'll think of more later. It seems C# is like Java or J++ but with
"smart pointers" (garbage collection).

RL

*** 2/ no "const" modifier for objects; just for data members (public
const int wheel = 4).

http://www.msnewsgroups.net/group/microsoft.public.dotnet.languages.csharp/topic29393.aspx

Hyun-jik Bae


Is there any way to prohibit writing values to an object A retrieved
from
another object B if B gives A for read only purpose?

For example,

public class B
{
public int xx;
}

public class A
{
public B aa=new B();
public B a
{
get
{
return aa;
}
}
}

class Program
{
static void Main(string[] args)
{
A q = new A();
int w=q.a.xx;
q.a.xx = 3; // STATEMENT X
}
}

where I want STATEMENT X be prohibited.

Please reply. Thanks in advance.
Hyun-jik Bae

11 Sep 2006 6:40 PMJon Skeet [C# MVP]

Is there any way to prohibit writing values to an object A retrieved from
another object B if B gives A for read only purpose?

Unfortunately not. (I disagree with Nick on this front - I think
there
are plenty of times when it would be useful to return something in a
read-only way.)

C++ has the idea of "const-correctness" and it's been put forward
many
times both for .NET and Java. The main difficulties as I understand
them are:

1) Making the syntax simple but expressive. For instance, if I return
an array of Foo, you might want to declare that the receiver can't
change the contents of the array, or can't change the Foo instances
referred to by the array, or both. We've seen how generics can make
for
some pretty long type declarations - const correctness would do the
same kind of thing.

2) Unless it's supported by the standard libraries, it's not nearly
as
much use - and making the standard libraries const-correct in
retrospect would quite possibly break a lot of things.

Now admittedly, your example code isn't ideal: B.xx would usually be
exposed as a property instead of a public field, and the property
could
be read-only, but I assume in real life other uses of B would need it
to be writable.

 

[Jon Skeet [C# MVP]]

First in an occasional series.

I'm somewhat experienced in C++, and am using .NET Visual Studio 2005
as the IDE. I'm learning C#.

What I don't like about C#, compared to C++ (all flavors):

1/ no pointers or tracking pointers or handles--this is absurd. I
realise references are by and large like tracking pointers effectively
(does anybody know of any differences--other than pointer arithmetic,
which you cannot do anymore in managed C++ anyway, I don't see any big
differences so far), but why not leave pointers in? When porting code
it's a pain to have to convert to references.

Pointers exist in unsafe code. Not sure what you'd want otherwise
though.

2/ no read-only "const" modifier for objects; just for data members
(public const int wheel = 4 // is OK in C#). See below*** How to you
avoid accidentally changing an object passed to a function--unless
you're very careful with your coding?

I agree that it would be desirable to have something like this.
However, it gets tricky quite quickly, I believe: "Here's a mutable
list of immutable objects" vs "Here's an immutable list of mutable
objects" etc - and that's just for *one* level of types.
There are other reasons, too. Anders talks about it here:
http://www.artima.com/intv/choicesP.html

The Java community has been going back and forth on this since well
before C# came along. In the case of both C# and Java I believe that
even if a solution were proposed now it would be too late to be useful
- it's the kind of thing which needs to be present right from the start
of a platform in order to be useful. Just MHO though.

3/ static classes not supported. A minor gripe but still

Static classes are part of C# 2. They may not be what you mean, but if
they aren't you should explain what you're actually after.

4/ Sparse to non-existant library. For example, no linked list (you
have to roll your own). I was pleasantly surprised that a dynamically
sized array exists in C#--whoo hoo!--progress.

Um, the .NET framework is pretty vast IMO, and .NET 2.0 has a linked
list type.

Arrays aren't dynamically sized though - the size is specified at
creation time, and can't change afterwards. The size can come from any
expression, of course - is that what you meant?

5/ Iterrators are kind of primitive ("for each * in"); though today I
learned IEnumerable is supported in C#--more progress.

Have you seen C# 2's iterator blocks? They're kinda nifty... The good
thing about IEnumerable and IEnumerable<T> being "primitive" is that it
makes them more widely applicable - there are less requirements in
order to support them.

What do you actually miss from C++ iterators?

6/ No copy constructor, though with managed C++ that's pretty much
gone away.

Can't say I have much of a problem with it personally. MemberwiseClone
is useful when you need cloning behaviour.

7/ stupid "in-line" class definitions. Ridiculous. .h and .cpp files
work fine and are logical--why get rid of them?

They were always a pain in the neck in my view - why specify something
twice when once will do?

8/ C# programmers seem more junior than C++ programmers (not that I'm
a code guru, but that seems to be true).

Not my experience, and also not really a statement about the language.

9/ stuff like ADO.NET only supported on C#.

Not sure what you mean here. I don't see why ADO.NET shouldn't work
with assemblies created in managed C++. Even if this is a problem, I
don't see why you should blame C# for it...

10/ multiple class inheritances and interfaces not supported. Not
that I really am a big fan of multiple inherietance or interfaces
anyway, since I usually nest classes or use composite classes unless I
cannot avoid using inheritance, like with dynamic runtime binding of
objects, so it's a minor gripe for me, but others I'm sure are
bothered by it.

In what way aren't interfaces supported? C# supports multiple
inheritance of interface and single inheritance of implementation.

I'll think of more later. It seems C# is like Java or J++ but with
"smart pointers" (garbage collection).

Um, Java has always had garbage collection.

Is there any way to prohibit writing values to an object A retrieved
from another object B if B gives A for read only purpose?

Making fields private instead of public is a good start...

<snip>

 

[Peter Duniho]

First in an occasional series.

And the last, I hope. IMHO, that sort of rant has no place here,
especially given the subjective nature of many of your complaints. It's
just trolling.

 

[Cor Ligthert[MVP]]

Ray,

You really should have a look at Intel assembler, that goes much more in
your direction than C#, you can do with that everything you cannot do with
C++.

Cor

First in an occasional series.

I'm somewhat experienced in C++, and am using .NET Visual Studio 2005
as the IDE. I'm learning C#.

What I don't like about C#, compared to C++ (all flavors):

1/ no pointers or tracking pointers or handles--this is absurd. I
realise references are by and large like tracking pointers effectively
(does anybody know of any differences--other than pointer arithmetic,
which you cannot do anymore in managed C++ anyway, I don't see any big
differences so far), but why not leave pointers in? When porting code
it's a pain to have to convert to references.

2/ no read-only "const" modifier for objects; just for data members
(public const int wheel = 4 // is OK in C#). See below*** How to you
avoid accidentally changing an object passed to a function--unless
you're very careful with your coding?

3/ static classes not supported. A minor gripe but still

4/ Sparse to non-existant library. For example, no linked list (you
have to roll your own). I was pleasantly surprised that a dynamically
sized array exists in C#--whoo hoo!--progress.

5/ Iterrators are kind of primitive ("for each * in"); though today I
learned IEnumerable is supported in C#--more progress.

6/ No copy constructor, though with managed C++ that's pretty much
gone away.

7/ stupid "in-line" class definitions. Ridiculous. .h and .cpp files
work fine and are logical--why get rid of them?

8/ C# programmers seem more junior than C++ programmers (not that I'm
a code guru, but that seems to be true).

9/ stuff like ADO.NET only supported on C#.

10/ multiple class inheritances and interfaces not supported. Not
that I really am a big fan of multiple inherietance or interfaces
anyway, since I usually nest classes or use composite classes unless I
cannot avoid using inheritance, like with dynamic runtime binding of
objects, so it's a minor gripe for me, but others I'm sure are
bothered by it.

I'll think of more later. It seems C# is like Java or J++ but with
"smart pointers" (garbage collection).

RL

*** 2/ no "const" modifier for objects; just for data members (public
const int wheel = 4).

http://www.msnewsgroups.net/group/microsoft.public.dotnet.languages.csharp/topic29393.aspx

Hyun-jik Bae


Is there any way to prohibit writing values to an object A retrieved
from
another object B if B gives A for read only purpose?

For example,

public class B
{
public int xx;
}

public class A
{
public B aa=new B();
public B a
{
get
{
return aa;
}
}
}

class Program
{
static void Main(string[] args)
{
A q = new A();
int w=q.a.xx;
q.a.xx = 3; // STATEMENT X
}
}

where I want STATEMENT X be prohibited.

Please reply. Thanks in advance.
Hyun-jik Bae

11 Sep 2006 6:40 PMJon Skeet [C# MVP]

Is there any way to prohibit writing values to an object A retrieved from
another object B if B gives A for read only purpose?

Unfortunately not. (I disagree with Nick on this front - I think
there
are plenty of times when it would be useful to return something in a
read-only way.)

C++ has the idea of "const-correctness" and it's been put forward
many
times both for .NET and Java. The main difficulties as I understand
them are:

1) Making the syntax simple but expressive. For instance, if I return
an array of Foo, you might want to declare that the receiver can't
change the contents of the array, or can't change the Foo instances
referred to by the array, or both. We've seen how generics can make
for
some pretty long type declarations - const correctness would do the
same kind of thing.

2) Unless it's supported by the standard libraries, it's not nearly
as
much use - and making the standard libraries const-correct in
retrospect would quite possibly break a lot of things.

Now admittedly, your example code isn't ideal: B.xx would usually be
exposed as a property instead of a public field, and the property
could
be read-only, but I assume in real life other uses of B would need it
to be writable.

 

[Larry Smith]

8/ C# programmers seem more junior than C++ programmers (not that I'm

Not my experience, and also not really a statement about the language.

That is true IMO (with no slight intended against C#) but it follows
naturally for two reasons:

1) C++ is a much more demanding language (read harder to learn and easier to
screw things up). It therefore forces programmers to think about what
they're doing more so than in C#. This will generally create programmers
whose heads are better wrapped around programming issues than those who work
in simpler languages. Unfortunately, the majority of C++ programmers are
marginal at best (a euphemism for other adjectives).

2) For obvious reasons, C++ programmers will normally have much better
OS/WinAPI experience than other programmers. Their mechanical understanding
of the OS gives them a huge edge over other programmers. In this area, a
grizzled C# programmer will simply not be in the same league as his C++
counterpart. Even on a supposedly neutral platform like .NET, the reality is
that you can and often do make better decisions based on sound knowledge of
the OS and WinAPI.

 

[Garfilone]

First in an occasional series.

I'm somewhat experienced in C++, and am using .NET Visual Studio 2005
as the IDE. I'm learning C#.

What I don't like about C#, compared to C++ (all flavors):

1/ no pointers or tracking pointers or handles--this is absurd. I
realise references are by and large like tracking pointers effectively
(does anybody know of any differences--other than pointer arithmetic,
which you cannot do anymore in managed C++ anyway, I don't see any big
differences so far), but why not leave pointers in? When porting code
it's a pain to have to convert to references.

2/ no read-only "const" modifier for objects; just for data members
(public const int wheel = 4 // is OK in C#). See below*** How to you
avoid accidentally changing an object passed to a function--unless
you're very careful with your coding?

3/ static classes not supported. A minor gripe but still

4/ Sparse to non-existant library. For example, no linked list (you
have to roll your own). I was pleasantly surprised that a dynamically
sized array exists in C#--whoo hoo!--progress.

5/ Iterrators are kind of primitive ("for each * in"); though today I
learned IEnumerable is supported in C#--more progress.

6/ No copy constructor, though with managed C++ that's pretty much
gone away.

7/ stupid "in-line" class definitions. Ridiculous. .h and .cpp files
work fine and are logical--why get rid of them?

8/ C# programmers seem more junior than C++ programmers (not that I'm
a code guru, but that seems to be true).

9/ stuff like ADO.NET only supported on C#.

10/ multiple class inheritances and interfaces not supported. Not
that I really am a big fan of multiple inherietance or interfaces
anyway, since I usually nest classes or use composite classes unless I
cannot avoid using inheritance, like with dynamic runtime binding of
objects, so it's a minor gripe for me, but others I'm sure are
bothered by it.

I'll think of more later. It seems C# is like Java or J++ but with
"smart pointers" (garbage collection).

RL

*** 2/ no "const" modifier for objects; just for data members (public
const int wheel = 4).

http://www.msnewsgroups.net/group/microsoft.public.dotnet.languages.c...

Hyun-jik Bae

Is there any way to prohibit writing values to an object A retrieved
from
another object B if B gives A for read only purpose?

For example,

public class B
{
public int xx;
}

public class A
{
public B aa=new B();
public B a
{
get
{
return aa;
}
}
}

class Program
{
static void Main(string[] args)
{
A q = new A();
int w=q.a.xx;
q.a.xx = 3; // STATEMENT X
}
}

where I want STATEMENT X be prohibited.

Please reply. Thanks in advance.
Hyun-jik Bae

11 Sep 2006 6:40 PMJon Skeet [C# MVP]

Is there any way to prohibit writing values to an object A retrieved from
another object B if B gives A for read only purpose?

Unfortunately not. (I disagree with Nick on this front - I think
there
are plenty of times when it would be useful to return something in a
read-only way.)

C++ has the idea of "const-correctness" and it's been put forward
many
times both for .NET and Java. The main difficulties as I understand
them are:

1) Making the syntax simple but expressive. For instance, if I return
an array of Foo, you might want to declare that the receiver can't
change the contents of the array, or can't change the Foo instances
referred to by the array, or both. We've seen how generics can make
for
some pretty long type declarations - const correctness would do the
same kind of thing.

2) Unless it's supported by the standard libraries, it's not nearly
as
much use - and making the standard libraries const-correct in
retrospect would quite possibly break a lot of things.

Now admittedly, your example code isn't ideal: B.xx would usually be
exposed as a property instead of a public field, and the property
could
be read-only, but I assume in real life other uses of B would need it
to be writable.

I think you'd better learn more about C# before you make some
conclusions about the language

 

[Cor Ligthert[MVP]]

Larry,

2) For obvious reasons, C++ programmers will normally have much better
OS/WinAPI experience than other programmers. Their mechanical
understanding of the OS gives them a huge edge over other programmers. In
this area, a grizzled C# programmer will simply not be in the same league
as his C++ counterpart. Even on a supposedly neutral platform like .NET,
the reality is that you can and often do make better decisions based on
sound knowledge of the OS and WinAPI.

In my idea is one of the reasons for Net to get rid of all those demanding
current Dos API's.

To say it simple, they are wrapped now in Net classes, which makes it
possible to do more than only the conversation with the API.

Cor

 

[Larry Smith]

2) For obvious reasons, C++ programmers will normally have much better

In my idea is one of the reasons for Net to get rid of all those demanding
current Dos API's.

To say it simple, they are wrapped now in Net classes, which makes it
possible to do more than only the conversation with the API.

I agree in theory but .NET isn't a replacement for the WinAPI. It's really
just a large class library wrapping much of the underlying OS functionality.
The transition to .NET is therefore much easier if you already have solid
WinAPI experience. A simple example: If you work with forms and threads then
it's very helpful if you already understand Windows message loops (and have
done raw WinAPI threading using functions like PostMessage()"). Your
conceptual understanding of functions like "Control.Invoke()" will therefore
be much better than someone who doesn't have any WinAPI experience at all.

 

[DeveloperX]

I agree in theory but .NET isn't a replacement for the WinAPI. It's really
just a large class library wrapping much of the underlying OS functionality.
The transition to .NET is therefore much easier if you already have solid
WinAPI experience. A simple example: If you work with forms and threads then
it's very helpful if you already understand Windows message loops (and have
done raw WinAPI threading using functions like PostMessage()"). Your
conceptual understanding of functions like "Control.Invoke()" will therefore
be much better than someone who doesn't have any WinAPI experience at all.

I think it's interesting that you think that. I don't strictly
disagree, and with the amount of P/invoke questions in this forum
alone this is probably a valid point. But given the points the OP
tried to make at the beginning I think we can see other areas that
mean a C++ programmer is not necessarily going to make a totally clean
transition. "Where are my pointers!!! Waaa!!!" being an example of a
fundamental conflict in mind sets.

I could make the point that a good VB6 developer will already be
pointer free, will be quite comfortable with p/invoke as he's probably
been doing it since day 2, well the VB style Declare Function
equivilent and would be more open to differences and learning because
the two languages are so different.

Ultimately, as long as the developer is capable I don't care what
their background is.

 

[Larry Smith]

I think it's interesting that you think that. I don't strictly

disagree, and with the amount of P/invoke questions in this forum
alone this is probably a valid point. But given the points the OP
tried to make at the beginning I think we can see other areas that
mean a C++ programmer is not necessarily going to make a totally clean
transition. "Where are my pointers!!! Waaa!!!" being an example of a
fundamental conflict in mind sets.

Seasoned C++ professionals won't cry over the lack of pointers. They might
(rightfully) point out weaknesses such as a lack of "const"
references/functions, no covariant return types (though MSFT has hinted it
might remedy this), etc., but a real professional will try to put his biases
aside. There are certainly things that C++ could learn from C# as well IMO.
Nevertheless, C++ programmers will move to C# much easier than anyone else.
This is based on my own experience and those of many others I've talked to.
It just makes sense given that C# is already syntactically very close to C++
(obviously its progenitor). Combine that with the (vastly) superior
knowledge of Windows itself and C++ programmers have a significant advantage
over all other programmers.

I could make the point that a good VB6 developer will already be
pointer free, will be quite comfortable with p/invoke as he's probably
been doing it since day 2,

Absolutely not. A VB programmer's exposure to the WinAPI is almost
non-existent. The WinAPI is in C itself so C/C++ programmers are in the best
position to deal with P/Invoke issues.

Ultimately, as long as the developer is capable I don't care what
their background is.

While many C++ programmers are arrogant about the skills of VB developers
(frequently malicious in fact), it is generally true that VB programmers are
weaker than C++ programmers (in my long experience). While you and others
might disagree with this, IMO you'll improve your odds of finding a more
skilled and talented programmer in the C++ pool (certainly much more
knowledgeable about Windows itself)

 

[Guest]

Agreed. Raised the signal to noise ratio, didn't contribute miuch content
other than more "me me".
--
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
bogMetaFinder: http://www.blogmetafinder.com

 

[DeveloperX]

Seasoned C++ professionals won't cry over the lack of pointers. They might
(rightfully) point out weaknesses such as a lack of "const"
references/functions, no covariant return types (though MSFT has hinted it
might remedy this), etc., but a real professional will try to put his biases
aside. There are certainly things that C++ could learn from C# as well IMO.
Nevertheless, C++ programmers will move to C# much easier than anyone else.
This is based on my own experience and those of many others I've talked to.
It just makes sense given that C# is already syntactically very close to C++
(obviously its progenitor). Combine that with the (vastly) superior
knowledge of Windows itself and C++ programmers have a significant advantage
over all other programmers.


Absolutely not. A VB programmer's exposure to the WinAPI is almost
non-existent. The WinAPI is in C itself so C/C++ programmers are in the best
position to deal with P/Invoke issues.


While many C++ programmers are arrogant about the skills of VB developers
(frequently malicious in fact), it is generally true that VB programmers are
weaker than C++ programmers (in my long experience). While you and others
might disagree with this, IMO you'll improve your odds of finding a more
skilled and talented programmer in the C++ pool (certainly much more
knowledgeable about Windows itself)

Well, I don't want to keep this thread alive longer than necessary, in
fact I've booked the abattoir and there will be a remembrance service
shortly.

My experience differs from yours. C++ developers I've worked with have
generally worked server side or in quant type positions. I've only
worked with one team who actively developed GUI's in C++ and it was a
nightmare. Partly down to the technology, mainly down to their severe
incompetence. Server side code was always about speed and looked
pretty much like C in wolves' clothing. OO was a smiley denoting their
blank eyed expressions rather than our anything oriented around
objects.

On the VB side, I've worked with developers working mainly on GUI's,
but also server side code and also similar quant type stuff.

On the GUI side the amount of knowledge you need to be a good GUI
developer in VB, to bypass the bottlenecks and restrictions VB imposed
required a significant understanding of what Windows was doing. I also
wasted lots of time interviewing alleged "programmers" with a VB
background who had actually just figured out that you could make
buttons... So in a way you're right, there's a high noise to sound
ratio with VB programmers, but that's no reason to dismiss them.

Both groups, and I make them distinct groups purely for this
discussion, had strong and weak members. I'm talking only about those
I've worked with/employed here, not the noise.

If I wanted a GUI developer or ASP developer to work in C# I would not
immediately look for C++ on their CV. I'd be after GUI oriented or web
based experience respectively. If I wanted a server guy I'd be looking
for that sort of related experience. In both cases I'd be open to
anyone who appeared to demonstrate skill and an ability to learn
regardless of their background, but also an understanding of the
technology they'll be using. So C# developers will need to show they
understand C# and the "modernity" that comes with it.

Then there's the question of business knowledge, related skills (SQL
as an example). That's just two for the trifecta.

I do understand where you're coming from, but spotting wheat in the
chaff is not directly related to previous language experience unless
you can almost directly map it to your current new world requirements
and don't need to engage your potential employee outside of that box.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Not my experience, and also not really a statement about the language.

I think that is true.

And COBOL and PL/I programmers are typical more senior than C++
programmers.

It is not particular surprising that the average age/experience
of developers in a new language are lower than for an older
language.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

That is true IMO (with no slight intended against C#) but it follows
naturally for two reasons:

1) C++ is a much more demanding language (read harder to learn and easier to
screw things up). It therefore forces programmers to think about what
they're doing more so than in C#. This will generally create programmers
whose heads are better wrapped around programming issues than those who work
in simpler languages. Unfortunately, the majority of C++ programmers are
marginal at best (a euphemism for other adjectives).

There are some merit to that argument.

But it does not really have any consequence. There are a limited
number of skilled people. It is obvious better to have 10 good C#
programmers than 1 good C++ programmer.

2) For obvious reasons, C++ programmers will normally have much better
OS/WinAPI experience than other programmers. Their mechanical understanding
of the OS gives them a huge edge over other programmers. In this area, a
grizzled C# programmer will simply not be in the same league as his C++
counterpart. Even on a supposedly neutral platform like .NET, the reality is
that you can and often do make better decisions based on sound knowledge of
the OS and WinAPI.

It is not obvious to me that users of Win32 API should get a better
understanding of OS's than users of .NET framework.

Arne

 

[Larry Smith]

2) For obvious reasons, C++ programmers will normally have much better

It is not obvious to me that users of Win32 API should get a better
understanding of OS's than users of .NET framework.

The WinAPI is the raw interface to the OS. Those who work with it directly
on a regular basis (normally C/C++ programmers) are working closer to the OS
than most other programmers (assembly developers not included). Ergo they
develop a much better understanding of the OS and how it works. If this
isn't obvious then you haven't spent any time with it.

 

[Michael C]

Absolutely not. A VB programmer's exposure to the WinAPI is almost
non-existent.

That is an incredibly ignorant statement, typical of most C developer's
understanding of VB. Usage of APIs is *huge* in VB, it has to be because VB
is so limited on it's own. To say it is non-existant is simply comical.
Although I do agree that generally C developers are on average stronger,
this is just an average and there are many VB developers who are very strong
developers.

Michael

 

[Michael C]

The WinAPI is the raw interface to the OS. Those who work with it directly
on a regular basis (normally C/C++ programmers) are working closer to the
OS than most other programmers (assembly developers not included). Ergo
they develop a much better understanding of the OS and how it works. If
this isn't obvious then you haven't spent any time with it.

A good example of this is developers who do not dispose of Pens or Brushes.
Anyone who has worked with the API knows this is critical.

Michael

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

The WinAPI is the raw interface to the OS. Those who work with it directly
on a regular basis (normally C/C++ programmers) are working closer to the OS
than most other programmers (assembly developers not included). Ergo they
develop a much better understanding of the OS and how it works. If this
isn't obvious then you haven't spent any time with it.

No. Win32 is *not* the raw interface to NT/2000/XP/2003/Vista.

It is a library provided by MS on multiple operating
systems (95/98/ME and NT/2000/XP/2003/Vista).

It is procedural not object oriented and therefore more low level
than .NET Framework.

But low level does not make it the raw interface to the operating
system.

Arne

 

[raylopez99]

tOn Aug 1, 8:02 am, Peter Bromberg [C# MVP]

Agreed. Raised the signal to noise ratio, didn't contribute miuch content
other than more "me me".
--
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
bogMetaFinder: http://www.blogmetafinder.com

You have a problem with trolling? I find trolls usually ask the best
questions myself. After all, if you know everything, there's no need
for a usenet group.

I thought this thread was interesting myself, and beats the usual post
of just solving some individual's particular bug of the moment. But
if you disagree feel free to killfile me or otherwise ignore.

BTW sorry for using some wrong terminology in the OP (meant multiple
inherietance from multiple classes, not multiple interfaces, which are
supported by C#).

RL

 

[raylopez99]

No. Win32 is *not* the raw interface to NT/2000/XP/2003/Vista.

It is a library provided by MS on multiple operating
systems (95/98/ME and NT/2000/XP/2003/Vista).

It is procedural not object oriented and therefore more low level
than .NET Framework.

But low level does not make it the raw interface to the operating
system.

Thanks I didn't know that. I'm tempted to ask what exactly is the raw
interface and how you would access it, but I have a suspicion it's
something like assembly language programming, and I would not be
surprised if MSFT has not made this interface publically available
(being paranoid about people understanding the innards of WIndows).

RL