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

[Larry Smith]

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

The precise architecture of Windows is a very deep subject. For all intents
and purposes however, the WinAPI is the de facto core set of APIs for
controllling the OS. It's not just another ordinary library as you would
have yourself believe. Things are somewhat different if you require true
low-level access to the OS but this applies almost exclusively to the world
of device drivers. For the vast majority of the world's development
community however, the WinAPI is what you deal with either directly (mostly
by C/C++ programmers) or indirectly via higher-level languages or interfaces
(which includes both VB and C#). Note that this does not mean that these or
other languages can't access the WinAPI at a lower-level with or without
restrictions (depending on the language), but they don't normally (usually)
do so directly. C/C++ programmers do. They regularly access the WinAPI via
the raw set of interfaces it provides unlike all other high-level languages.
Their understanding of the OS's behaviour and subtle nuances will therefore
be superior most of the time. If you honestly think that a C# or VB
programmer really understand the WinAPI at the same level as a comparable
(experienced) C/C++ programmer, I can easily think of many programming
exercises that would quickly prove otherwise.

 

[AlexS]

I believe "superiority" is not defined by language you use but more by
experience in working with Win API. In VB you have to use some special
tricks to get to runtime functions which C guys get for granted. Some stuff,
which is a breeze in C/C++, requires a lot of digging when must be re-done
in VB. So in some cases VB guy doing heavy duty Win32 stuff might understand
much better what is where than the other "guru". Same for C#.

Using your logic you must conclude that C/C++ programmers by definition are
inferior to assembler programmers, who access internals of OS kernel at much
lower level

Yes, we can't code drivers for Windows in VB or C#, however this is saying
more about technical limitations of these languages implementations than
about skills of people coding in these languages. If I do 99% of my work in
C# and 1% in C/C++, would you say that I know 100 times less than 100% C/C++
coder about Windows?

It's apples to oranges comparison. And very snobbish and prejudiced to my
taste

 

[raylopez99]

I appreciate the insights from this thread; I code for fun. It's new
to me; others might think this issue played out, but I don't see it
that way.

IMO, because of the frequent updates to the languages, every language
out there is still "new" and full of bugs.

For example, just the other day I found that a 'bug' of sorts exists
in C# that necessitates you "keep alive" a thread in a multi-threaded
project before the "}" curly end brace, to prevent premature garbage
collection, even though the garbage collected object will never be
used again before the "}". And how a structure is not considered the
same as a class (even a class with all public members) Stuff like that
shows me the language is still new.

Now, onto some more demo projects. Today I went through somebody's
code on an n-ary tree, and compared it to my code, which I had done
independently, and noted the striking similarities--showing great
minds think alike, or sometimes parallel evolution yields the same
animals due to environmental constraints. I then perfected
IEnumerable/IEnumerator on my class (interesting how you can customize
these to 'step through' your class in a variety of manners, since an n-
ary tree can be traversed either "level-by-level" or "node-by-node").
Now onto figuring out what IComparable is all about.

RL

 

[Jon Skeet [C# MVP]]

For example, just the other day I found that a 'bug' of sorts exists
in C# that necessitates you "keep alive" a thread in a multi-threaded
project before the "}" curly end brace, to prevent premature garbage
collection, even though the garbage collected object will never be
used again before the "}".

That's not the case. Sample code please?
(If you're talking about a Mutex, then I think I know what you mean -
although it's certainly not a bug, and is very unlikely to change
however old the language becomes.)

And how a structure is not considered the
same as a class (even a class with all public members) Stuff like that
shows me the language is still new.

That doesn't mean the language is new - it just means you don't
understand the terms of the language, and have tried applying the
terminology from another language.

Structs and classes in C# will always be different, however old the
language becomes.

Jon

 

[Larry Smith]

I believe "superiority" is not defined by language you use but more by

experience in working with Win API. In VB you have to use some special
tricks to get to runtime functions which C guys get for granted. Some
stuff, which is a breeze in C/C++, requires a lot of digging when must be
re-done in VB. So in some cases VB guy doing heavy duty Win32 stuff might
understand much better what is where than the other "guru". Same for C#.

Are you really suggesting that the deviation of any rule which applies 1% of
the time means that what happens 99% of the time doesn't (still) constitute
the norm.

Using your logic you must conclude that C/C++ programmers by definition
are inferior to assembler programmers, who access internals of OS kernel
at much lower level

Terms like "inferior" and "superior" elicit a charged emotional response.
Your conclusion is essentially correct however. For someone doing even
lower-level work with assembly, device drivers, etc., their breadth of
technical knowledge in that area will be superior to a C/C++ programmer.
This issue has little to do with C/C++ as a language however though it
obvously has an impact because the WinAPI itself is in C. The issue is that
C/C++ programmers are the ones who are dealing most directly with the WinAPI
most of the time. Their knowledge of the OS will therefore be "superior" to
most VB or C# programmers by necessity (most of the time). If the opposite
were true then I'd be arguing the same for VB or C# programmers instead.

Yes, we can't code drivers for Windows in VB or C#, however this is saying
more about technical limitations of these languages implementations than
about skills of people coding in these languages. If I do 99% of my work
in C# and 1% in C/C++, would you say that I know 100 times less than 100%
C/C++ coder about Windows?

It's apples to oranges comparison. And very snobbish and prejudiced to my
taste

This has nothing to with snobbery on my part (I don't speak for others)
though you and others often jump to that simplisitc/knee-jerk conclusion.
The issue is very clear. For any piece of machinery that exits, those who
work closer with the mechanics of that machine will know more about the
machine than those who don't. It's that simple.

 

[Jon Skeet [C# MVP]]

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.

Trolls are out to be provocative. Occasionally they happen to say
useful things, but I'd always rather start with someone who's trying to
form meaningful dialogue rather than just angering people.

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.

Discussions of the shortcomings of C# are certainly informative, but
not when they're based on erroneous starting points. Likewise, bashing
the language or framework with little reasoning (such as calling the
inline nature of class definitions "ridiculous" with no supporting
arguments) doesn't really help.

 

[raylopez99]

raylopez99 <[email protected]> wrote:

Discussions of the shortcomings of C# are certainly informative, but
not when they're based on erroneous starting points. Likewise, bashing
the language or framework with little reasoning (such as calling the
inline nature of class definitions "ridiculous" with no supporting
arguments) doesn't really help.

Then tell us what you don't like about C# Jon.

BTW, inline class definitions really *are* ridiculous. I'm going
through a mess of such a class definition right now, with lots of line
breaks and nested classes--hard to tell what the member variables are
from the class functions/methods, and the use of "properties" blurs
the member variables from functions/methods. Better to have split the
header file definitions from the declarations, like in C++.

RL

 

[Jon Skeet [C# MVP]]

Then tell us what you don't like about C# Jon.

I've done so several times in the past, but briefly:

1) The "lock" statement should have been "using" with an appropriate
locking type. See
http://pobox.com/~skeet/csharp/miscutil/usage/locking.html

2) Switch needs to be brought into the 21st century - even if the
current behaviour is appropriate, the syntax and scoping could be
significantly improved

3) I'd like object-oriented enums, similar to Java's:
http://msmvps.com/blogs/jon.skeet/archive/2006/01/05/classenum.aspx

4) I'd like "private-to-property-code" variables which can't be
accessed by the rest of the class, like those introduced with automatic
properties in C# 3, but available for non-trivial properties too

5) I'd like non-nullable reference types which can be used as
parameters etc, eg: "void Foo (string! x)". Ideally the compiler should
deal with this at compile time, but at the very least it could generate
code to throw ArgumentNullException where appropriate

6) I'd like named indexers

7) I'd like extension properties like C# 3's extension methods - handy
for writing fluent interfaces

BTW, inline class definitions really *are* ridiculous. I'm going
through a mess of such a class definition right now, with lots of line
breaks and nested classes--hard to tell what the member variables are
from the class functions/methods, and the use of "properties" blurs
the member variables from functions/methods. Better to have split the
header file definitions from the declarations, like in C++.

Sounds like you're dealing with a badly written class - which can
happen in any language.

In C++ you need to keep two bits of identical information in sync -
practically the definition of redundancy. If you want that behaviour,
however, you could always create an interface for every single class
you write.

I used to write C and C++, then moved to Java and then to C#. I've
never looked back with *any* fondness at the .c/.h split, and any time
I've had to work with C or C++ since I've found that to be one of the
pain points.

 

[raylopez99]

I've done so several times in the past, but briefly:

1) The "lock" statement should have been "using" with an appropriate
locking type. Seehttp://pobox.com/~skeet/csharp/miscutil/usage/locking.html

That's some advanced MoJo there, Jon. Multithreading. I'm a little
less advanced--for example today I found out that C# has a neat and
compact "forward reference" that means you don't have to declare the
forward referenced class as a composite member in your class--but can
actually simply define/use it for the first time in a method parameter
list (assuming it's part of the same namespace). A little different
from traditional C++.

2) Switch needs to be brought into the 21st century - even if the
current behaviour is appropriate, the syntax and scoping could be
significantly improved

Yes, I agree--I've never actually used Switch in any of my programs--
seems so limited, using integers/char for control statements. I use If/
then (nested) instead, same thing. I'm still trying to figure out
(and will experiment today) with identifying objects in C# dynamically
at run-time (do you use "if(object_passed_to_your_function is
MyClass)"?? Seems that way. I thought it might be MyClass.GetType(),
but that just gives you the general (too general) Type of the object
it seems, thought that might be the same thing (another demo project
for today). At some point I'll give in and actually buy a book on C#
(I have on preordered, a nutshell guide due to be published this fall,
by O'Reilly). In the meantime I'll ask this group, which is faster
and easier than looking it up. Forget about "Help" function in Visual
Studio 2005--too much information, usually too generic also.

3) I'd like object-oriented enums, similar to Java's:http://msmvps.com/blogs/jon.skeet/archive/2006/01/05/classenum.aspx

Same thing I suppose.

4) I'd like "private-to-property-code" variables which can't be
accessed by the rest of the class, like those introduced with automatic
properties in C# 3, but available for non-trivial properties too

Yes, somewhere I saw that "properties" are the new "global variables".

5) I'd like non-nullable reference types which can be used as
parameters etc, eg: "void Foo (string! x)". Ideally the compiler should
deal with this at compile time, but at the very least it could generate
code to throw ArgumentNullException where appropriate

Why? I have no idea why non-nullable is important. Must be a multi-
thread thing.

6) I'd like named indexers

Instead of the named IEnumerator class (which you can rename) I take
it? A small point for code clarity I presume.

7) I'd like extension properties like C# 3's extension methods - handy
for writing fluent interfaces

No idea what you're saying here. A quick look at Wiki "http://
en.wikipedia.org/wiki/Fluent_interface" shows a rather confusing
example, that's not at all easy to read, especially since no main()
program "using" the interface is show (hate it when that happens).
Looks too obscure to me--I vote with the people that say "fluent
interfaces" are too hard to read. As for IConfiguration, I'll
probably never use it ("The IConfiguration interface defines
properties and methods used to access configuration information for
Collaboration Data Objects (CDO) objects.) http://en.wikipedia.org/wiki/Collaboration_Data_Objects
(obscure Server stuff--too specialised for my taste)

Sounds like you're dealing with a badly written class - which can
happen in any language.

In C++ you need to keep two bits of identical information in sync -
practically the definition of redundancy. If you want that behaviour,
however, you could always create an interface for every single class
you write.

I used to write C and C++, then moved to Java and then to C#. I've
never looked back with *any* fondness at the .c/.h split, and any time
I've had to work with C or C++ since I've found that to be one of the
pain points.

You're way ahead of me of course. I code as a hobby when I have spare
time from my real job. Right now I'm awaiting some projects so I'm
building an N-ary tree to prove some geneology stuff (see here:
http://tinyurl.com/2rh987). Amazing that my home grown tree is
similar to the C# cookbook's tree, independently derived.

RL

 

[Jon Skeet [C# MVP]]

That's some advanced MoJo there, Jon. Multithreading.

The time is coming when pretty much all developers - at least
professionals - will need to understand multithreading. There are very
few situations where you shouldn't at least be considering the impact
of threading.

I'm a little
less advanced--for example today I found out that C# has a neat and
compact "forward reference" that means you don't have to declare the
forward referenced class as a composite member in your class--but can
actually simply define/use it for the first time in a method parameter
list (assuming it's part of the same namespace). A little different
from traditional C++.

It's not that C# has a compact forward reference - it just doesn't have
forward references at all. I don't regard that as a C# feature so much
as a C/C++ anti-feature

Yes, I agree--I've never actually used Switch in any of my programs--
seems so limited, using integers/char for control statements. I use If/
then (nested) instead, same thing.

Well, if you've got multiple options there then switch can give
readability improvements (and it works for strings as well in C#).
However, it could be better than it is.

I'm still trying to figure out
(and will experiment today) with identifying objects in C# dynamically
at run-time (do you use "if(object_passed_to_your_function is
MyClass)"?? Seems that way. I thought it might be MyClass.GetType(),
but that just gives you the general (too general) Type of the object
it seems, thought that might be the same thing (another demo project
for today).

You can use the "is" or "as" operators, but ideally they should be
relatively rare - if the behaviour of some code depends on the type of
another object, polymorphism is usually a nicer way to specialise that
behaviour. It doesn't always work that way, admittedly.

At some point I'll give in and actually buy a book on C#
(I have on preordered, a nutshell guide due to be published this fall,
by O'Reilly). In the meantime I'll ask this group, which is faster
and easier than looking it up. Forget about "Help" function in Visual
Studio 2005--too much information, usually too generic also.

I'd recommend the book I'm writing, but it's really aimed at those who
already know C# 1.

MSDN is very good though, and it's *really* lazy just to ask on the
group without at least *trying* to look up the information first. If
you ask lots of questions which are easily answered either through
looking in MSDN or just using a search engine, people will stop
replying.

Same thing I suppose.

Not sure what you mean.

Yes, somewhere I saw that "properties" are the new "global variables".

No, that's not true at all. However, they don't provide quite as much
encapsulation as they could, that's all. They shield the rest of the
world from direct access to the variables, but not code within the same
class (or nested classes).

Why? I have no idea why non-nullable is important. Must be a multi-
thread thing.

That's a pretty remarkable conclusion to come to. It's got *nothing* to
do with multi-threading. It's got everything to do with making things
as safe as possible at compile time, or at least simplifying the code
by removing the manual parameter checking. It also indicates intention
more clearly than just documenting that a method can't be null.

Instead of the named IEnumerator class (which you can rename) I take
it? A small point for code clarity I presume.

Um, no, somewhat different to that.

Suppose I have a class like this:

public class Foo
{
byte[] imageData;
byte[] otherData;
}

If I want to allow random access to both data arrays for read-only
purposes, that's relatively tricky today. If I could do this:

public class Foo
{
byte[] imageData;
byte[] otherData;

public byte ImageData[int index]
{
get { return imageData[index]; }
}

public byte OtherData[int index]
{
get { return otherData[index]; }
}
}

that would be much neater.

No idea what you're saying here. A quick look at Wiki "http://
en.wikipedia.org/wiki/Fluent_interface" shows a rather confusing
example, that's not at all easy to read, especially since no main()
program "using" the interface is show (hate it when that happens).
Looks too obscure to me--I vote with the people that say "fluent
interfaces" are too hard to read.

If you've only seen a single (non-ideal) example, it's a bit early to
say, don't you think?

An example from Groovy using Google's data library is:

Date reminder = 1.week.from.now

I challenge you to claim that the meaning of that code is obscure

Also I don't see how you can complain about no examples with "main"
being given: there are three on the wikipedia page!

As for IConfiguration, I'll
probably never use it ("The IConfiguration interface defines
properties and methods used to access configuration information for
Collaboration Data Objects (CDO) objects.)
http://en.wikipedia.org/wiki/Collaboration_Data_Objects
(obscure Server stuff--too specialised for my taste)

The IConfiguration interface in the fluent interface wikipedia entry
has *nothing* to do with CDO, nor do fluent interfaces in general have
anything to do with CDO.

You're way ahead of me of course. I code as a hobby when I have spare
time from my real job. Right now I'm awaiting some projects so I'm
building an N-ary tree to prove some geneology stuff (see here:
http://tinyurl.com/2rh987). Amazing that my home grown tree is
similar to the C# cookbook's tree, independently derived.

Hopefully over time you'll grow to love the lack of redundant
definitions, as I believe most Java and C# developers do.