Why I hate C#

[Christian Graus]

Skippums wrote:

I just expected that a new language would go the extra mile and give me more flexibility, instead of restricting me so much that I am spending about a tenth of my time jumping through hoops to trick the language into working how I need it to.

What you mean is, you expect a new language to work like the old one. C# is a new language. I went through the same pain, at first I tried to make C# be c++ and it did not work. Now I understand the differences, I know both have limitations, but I am used to working within each of them. I like C#.

Skippums wrote:

As far as your suggestion, "You should probably clean up your design before you start coding", I completely disagree.

If you want to decouple something as basic as the nature of an Id, then do it via a class, that makes sense to me.

Skippums wrote:

If I have class A in namespace NA, and class B in namespace NB which inherits from class A, to include class B I am forced to say that I am using namespace NA

Yeah, there's no auto namespace lookup. I agree that would be nice, but for every C++ person who expects it, there are 20 who would be troubled to see the namespace imported automatically.

Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )

[Christian Graus]

typedefs are plain ugly. They are a holdover from C, I thought. multiple inheritance was not included probably because the design focus of C# is to make it hard to hurt yourself using it. I disagree with them, but that is their focus.

Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )

[Skippums]

They have an anticollision beacon (the bright red flashing light on top and bottom), running lights (the red and green on the front wingtips, white on the back of the plane), and a landing light or lights. I would consider none of those to be taillights that could be shared with those of a road vehicle, and therefore they should not appear in the airplane class. Regardless, if we ignore semantics and focus on the point, we can see that there are some things that can be categorized in a multitude of ways, and my contention is that an object-oriented language should be able to model that reality, and further, that it should be able to be modeled without any redundancy in code. Jeff -- modified at 19:43 Wednesday 28th November, 2007

[Skippums]

I agree that they CAN be ugly, but all I want is to do something like, "typedef UniqueId as int;", so anywhere I put the word UniqueId, the compiler will know I want it to be an int. I don't understand how strongly coupling my UniqueId property and the integer type within the class is at all helpful. Code maintanance on this is going to be atrocious. Jeff

[Paul Conrad]

I guess if the boss says so, you have to.

"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon

[Paul Conrad]

SK Genius wrote:

C# is more of a mix between java and c++

I agree. After being a C++ programmer for 15+ years and using java in college, I find C# to be a happy median between the two.

"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon

[Paul Conrad]

Christian Graus wrote:

typedefs are plain ugly. They are a holdover from C, I thought.

Yes, they are ugly. I have always thought that they were carried over from C to maintain portability between older legacy C code and newer C++ code.

"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon

[PIEBALDconsult]

Skippums wrote:

the removal of the ever useful typedef

"When Anders closes a door he usually opens a window someplace." No one showed you the C# way? Won't this work for you?

// Uncomment one of these
// using MyType = System.Int32 ;
// using MyType = System.Double ;
// using MyType = System.Decimal ;
// using MyType = System.String ;

namespace Test
{
class Test
{
private static MyType
F
(
MyType x
)
{
return ( x + x ) ;
}

    \[System.STAThreadAttribute\]
    static void
    Main
    (
        string\[\] args
    )
    {
        try
        {
            System.Console.WriteLine ( F ( 2 ) ) ;
        }
        catch ( System.Exception err )
        {
            System.Console.WriteLine ( err.Message ) ;
        }

        return ;
    }
}

}

Of course C/C++ header files make using typedefs easier, whereas each C# file would need to have the using directive. On the other hand, you can pass C# code through the C-preprocessor if you want.

[PIEBALDconsult]

Well typedefs are prettier than having to say struct X all over the place.

[Christian Graus]

You could in fact create a generic class and define it that way. IMO maintenance on a project where the nature of your unique Id could change in mid stream is no less problematic. Hell, you can store an object if you want, and then handle it as whatever type you like from there. But if you use generics, then your type won't be boxed if it's a value type.

Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )

[Judah Gabriel Himango]

Why didn't they include multiple inheritence: Big question. Best I can do is point you to an in-depth post by one of the CLR guys who explains in detail why they didn't: http://blogs.msdn.com/csharpfaq/archive/2004/03/07/85562.aspx[^] Why didn't they include typedef's: well, technically they did, they just limited the scope of typedefs to the file level, which is a good thing IMO. For example, you can write:

using IntList = System.Collections.Generic.List;

...

public void Foo()
{
IntList list = new IntList();
list.Add(5);
...
}

If you don't like the fact that it's limited to the file level, then I'd just write a value type (e.g. a struct) that holds whatever data you need.

Tech, life, family, faith: Give me a visit. I'm currently blogging about: The Story of the Spoiled Child The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

[Bino B]

Never hate any languages,pls.

Cheers Bino www.codepal.co.in

[Luc Pattyn]

Hi Jeff, if you want to be able to write

for(uniqueID id=0; id<10; id++) Console.WriteLine(id.ToString());

then just do it. All it takes is a simple:

using uniqueID=System.Int32;

AFAIK this has been available since day one. The one thing now really missing from C/C++ is you can't collect statements like the latter in a single header file and get them included everywhere. :)

Luc Pattyn [Forum Guidelines] [My Articles]

---

this months tips: - before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use PRE tags to preserve formatting when showing multi-line code snippets

---

[Skippums]

Thanks to everyone who responded to my post! I got a lot of good opinions and dialogs going, and even some reasons why particular language design choices were made (although I still disagree with them). Perhaps the title of the post should have been, "Some of the features I miss from C++", as I still plan on using C# for my projects that I do in my free time, even when someone doesn't force me to. There are many great features of C# to take advantage of, and despite the few drawbacks (in my opinion, pretty significant drawbacks), it really is a great language. Thanks again everyone! Jeff

[Skippums]

"you can pass C# code through the C-preprocessor if you want" That is an interesting idea... I will have to try that one at home sometime. As far as the using statement, that works alright, but I will still have to modify the value in a number of places after the fact. What I really wanted was either namespace-scoped typedefs or project-scoped typedefs (solution-scoped would probably be nice in certain situations, but I could get by with just the other two mentioned above). Anyway, thanks for your input! Jeff

[Skippums]

Yeah, it's just that I will still have to have that statement in EVERY file where I reference the type. For maintanence purposes, I will still have to change the using statement in every file. I will probably just end up making my own value type, storing the "real" member as private, then implement the IEquatable and IComparable interfaces, so I can still sort and test for equivalence. Also, this will allow for strong type checking, as apposed to typedef (and I think, the using statement as outlined above) where the types are actually equivalent. Anyway, thanks for the input! Jeff

[PIEBALDconsult]

Skippums wrote:

I will still have to modify the value in a number of places after the fact

Wouldn't that be the case anyway?

Skippums wrote:

thanks for your input!

Glad to be of service.

[Skippums]

Ok, you got me. I should have said, "I will still have to modify the TYPE in a number of places after the fact". Jeff

[Alaric_]

bingo....your particular desired usage of typedefs typically follows a procedural mentality. ...C++ allows them because C++ is the disgusting bastard child caught in between the (now very)distant past of procedural design and what has been come to be accepted(OOP) as the way things are done from here(actually...probably closer to 10 years ago) until something better can be thought of ...C# is not the problem for placing said restrictions on you...C++ was the problem for allowing you to do them in the first place

"I need build Skynet. Plz send code"