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

raylopez99 <raylopez99@xxxxxxxxx> wrote:
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.

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 :)

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.

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.

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.

Not sure what you mean.

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".

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).

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.

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.

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.

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.

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.

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.

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.

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

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: 7.0 wishlist?
    ... The "auto-implement" is intended mainly for the odd situation where an existing class you can't edit fits some interface and you're willing to take responsibility for it if it turns out not to actually adhere to the contract, and try using it where that interface type is expected. ... If reference declarations started showing up with the odd asterisk, bang, or other punctuation mark on it, but never primitive declarations, people would probably be able to guess what was going on, on the basis of "what other binary flag might be set on references but not primitives and would be really useful besides can be/cannot be null?" ... the compiler cannot prove by static analysis that the RHS isn't null might be a good idea. ... Object foo, bar; ...
    (comp.lang.java.programmer)
  • Re: Anders Hejlsberg comment on immutable objects
    ... >explicit interface implementation exists is so an interface name can class ... Improper implicit conversions constitute a nasty ... >> With value types, the variable's value is the object, not a reference ... Consider the affects of our different views on a const ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: please try this program (generic resolution)
    ... of the specific interfaces of a generic interface that has that name and ... either is in the scoping unit in which the reference appears or is made ... And now in my example I misspelled ENISOC. ... external fun ...
    (comp.lang.fortran)
  • Re: C# Plugin system - same interface in two different assemblies...
    ... "add a reference to the appropriate assemblies to each and every project"? ... You don't have each plugin project deciding what ... its idea of the interface is. ... can't by forcing people to include them in assemblies as I've explained. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Using early-bound interface on a late-bound object
    ... > the compiler determines which interfaces to use, ... > supports the declared interface. ... >> help if someone can point me to some authoritative document or reference ... within customer shops when they mirrored this 'division' to keep their ...
    (microsoft.public.vb.general.discussion)