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.
