• Advertisement
Sign in to follow this  

C# - huh?

This topic is 3900 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I don't think I need to add anything to the discussion of C++ and C#, just that it all depends on your abilities, desires, need for balance and control, the usual generic response.

As for an IDE, I've switched from Dev-C++ to Code::Blocks (using the Nightly builds on the forum), for a little more control, more feature sets, and an IDE made using the langauge it 'advocates'.
As far as I know, there may be a possiblity for it to use C# (it does have support for D), but I honestly don't know

On the note of D, you could also try that. It's a relatively young language (began in 2002, I think), and I've seen some applications/libraries on various D repositories and on SourceForge. As far as how good it is for game programming, I can't formulate an opinion on it just yet. I still need to get into the language.

Share this post


Link to post
Share on other sites
Advertisement
Not to mention, that there is C++/CLI, which imho completely undermines C#, unless
you never learned C++.

Share this post


Link to post
Share on other sites
C++/CLI is great for porting legacy C++ code into a managed environment (eg, porting an old game engine so you can use it with C#).

It is sufficiently ugly and awkward to make writing fresh, new applications in it painful. [wink]

Share this post


Link to post
Share on other sites
C# for tools, C++ for games, is a nice rule of thumb.

I don't really advise *learning to program* games in C# if you want to get into the industry professionally - good luck writing a triple A title for the PS3, Xbox 360 and Wii in C#.

However, if you want to make an indie PC or XNA game or learn how DirectX works, it's quite nice. With DX being a lot about pointers and filling out data structures, you can get started faster in C#, and it's a bit more forgiving. You'll also find performance wise it's a lot better than Java.

Share this post


Link to post
Share on other sites
I still remember my high school C++ teacher saying that everything was going to be moving from C++ to Java, that still makes me laugh.

Share this post


Link to post
Share on other sites
Regarding C++ and safety --

It depends on what definition of 'safe' you're going after. C++ is not particularly type safe, in that it's a very weakly typed system. I can coerce any type to any other type in C++ if I want it badly enough. Then there's the trap of how easy it is to write code that suffers undefined or implementation defined behavior, both of which make it a rather unsafe environment to work in. Then there's the question of how safe it is with regards to basic operations without doing stuff like trashing your stack. Again, it isn't really, though there's a lot more you can do here than you could in C.

I'm having trouble thinking of anything that makes C++ "safe". I can think of things that make it safer than C -- but that's like thinking of things safer than dousing yourself with kerosene and then playing with matches.

You need to learn C++ eventually if you intend to make any progress in game programming as a profession. That doesn't mean you need to learn it immediately. C# is a great language, but there are various problems keeping it from being adopted in The Industry (tm). Those problems mainly involve platform support, legacy codebases, and developer training.

Share this post


Link to post
Share on other sites
Quote:
Original post by fsm[...] you can get started faster in C#, and it's a bit more forgiving. You'll also find performance wise it's a lot better than Java.


What data are you basing this on?

I'm asking since I've only seen benchmarks that concludes the opposite, like this one.

Share this post


Link to post
Share on other sites
Ugh, not another "he said, she said" benchmark pissing contest. It all depends on your code, the compiler, the runtime, etc.

Regarding everyone "switching from C++ to Java", I think Java was held back by the awkwardness of using native code with it. With C# and the CLR, that was rectified by allowing easy interop with native libraries, making a transition more likely (though, still slow with library-lag).

Share this post


Link to post
Share on other sites
Quote:
Original post by benryves
It is sufficiently ugly and awkward to make writing fresh, new applications in it painful. [wink]


I think you should update your knowledge about C++ in the .NET environment, as Managed C++ is no more...
Even Stroustrup himself praises C++/CLI's design, altough he doesnt like its non-ISO C++ keywords and Microsoft dependency.
Maybe you should just compare C++/CLI examples versus C# examples on MSDN...you might be up for a suprise.
Actually, have you ever used VS2005? :)

Share this post


Link to post
Share on other sites
Quote:

think you should update your knowledge about C++ in the .NET environment, as Managed C++ is no more...

He was talking about C++/CLI, and he's right. It's pretty ugly to work with. C++/CLI also has a ECMA standard, incidentally; it's its own language.

Share this post


Link to post
Share on other sites
Quote:
Original post by guardian24
Even Stroustrup himself praises C++/CLI's design, altough he doesnt like its non-ISO C++ keywords and Microsoft dependency.
Stroustrup designed C++, which raises some serious questions about how many pounds of salt to carry when listening to him talk about language design.

Having done more work in C++/CLI than I ever wanted to, I can honestly say that I hate this language and pity anyone else working with it. It takes the insanely complex beast that is C++ and makes things even worse. It doesn't help that the compiler emits worthless and irrelevant error messages for many common mistakes.

Share this post


Link to post
Share on other sites
Well OK, but maybe you should demonstrate its "ugliness" and "makes things even worse" thingy. Imho its "nice" :), and there are many positive reviews on the internet.
I dont think that this is ugly:

interface class I {
};
delegate int ClickHandler();
ref class M : public I {
event ClickHandler^ OnClick;
public:
property int Num {
int get() {
return 0;
}
void set(int value) {
}
}
};


Where is the ugliness, comparing to C#?
You could surely show some examples...

Share this post


Link to post
Share on other sites
Quote:
Original post by guardian24
Where is the ugliness, comparing to C#?
It's in your hideous code formatting [lol]

For the most part, the language itself does not *look* bad. Neither does C++, for that matter, unless you're playing with the more convoluted depths of it. It's the sheer complexity of things, and the mass of finicky details that really complicate things.

For example, consider destruction.
ref class Foo
{
public:
~Foo() { Foo::!Foo(); }
!Foo();
};
So we've got a destructor, which more or less behaves like a destructor. And then we've got this extra thing tacked on, which is the finalizer. The destructor implementation, in turn, explicitly calls the finalizer. These get remapped into the disposable pattern. Foo implements IDisposable, and two methods are generated, Dispose() and Dispose( bool disposing ). Finalize() is also generated. Those methods call the destructor and finalizer as they see fit. GC.SuppressFinalize is magically called for you at some point as well. The compiler emits more calls to these functions around your code as needed. You now use delete obj; instead of obj->Dispose(), and destructors are also chained automatically per C++ rules -- which of course means that you need to mark your base class destructors virtual like in C++. Oh, and you're not allowed to explicitly implement IDisposable. In other words, this is illegal:
public ref class Foo : IDisposable
{
public:
virtual void Dispose()
{
}
};
Another example. Every variable can now be a value, a pointer, a reference, a handle (managed reference) or a tracking reference(ref/out in C#) to one of those things. You can form a reference or a pointer to any of the first four, but the reference will show up as a pointer when exported with an attribute, and who knows how other languages consume that. You can form a handle to any ref class, but nothing else. And boxing gets involved somewhere in there, allowing you to have boxed handles to value types. Don't forget NULL for pointers but nullptr for handles. You can pass anything as a tracking reference, but you have to use the [Out] attribute to differentiate between what C# calls 'ref' and 'out'. I also noticed something about some "take-address" operator, but really just didn't care. All that only applies to managed classes; native classes and structs can't be exposed as values. On top of that, you can take pointers to things inside managed objects, but only by using pin_ptr and interior_ptr, which are pseudo-template pointer types that the compiler inherently knows about. Then you've also got the pseudo-template array type. So some of the syntax here:
array<Byte>^ data = gcnew array<Byte>(100); //gotta use gcnew. Can't use ^ on the rhs.
pin_ptr<const unsigned char> pinnedData = &data[0]; //automatically unpins via RAII. And make sure you put const in the right place!
array<array<MyClass^>^>^ local; //whoo jagged array


For more fun, look into any of the following:
* String literal handling (when is it a char*, and when is it a String^?)
* Casting behavior, safe_cast, and what the compiler does with C style casts
* Context sensitive keywords -- I can happily name a variable 'delegate' if I want!
* Explicit overriding
* The rules for mixing generics and templates, and metadata for managed templates
* The myriad of rules for what you can and can't do with tracking references

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement