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/mi...opic29393.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]
Hyun-jik Bae <im***********@ paran.comwrote:

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.

[Peter Duniho]

raylopez99 wrote:

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

"raylopez99 " <ra********@yah oo.comschreef in bericht
news:11******** **************@ 22g2000hsm.goog legroups.com...

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/mi...opic29393.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]
Hyun-jik Bae <im***********@ paran.comwrote:

>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

>a code guru, but that seems to be true).

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]

On Aug 1, 6:36 am, raylopez99 <raylope...@yah oo.comwrote:

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/mi...et.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]

Hyun-jik Bae <imays_NOSP...@ paran.comwrote:

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

>OS/WinAPI experience than other programmers. Their mechanical
understandin g 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.

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]

On 1 Aug, 12:36, "Larry Smith" <no_spam@_nospa m.comwrote:

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.

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)

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

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

"Peter Duniho" wrote:

raylopez99 wrote:

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.