Jump to content

  • Log In with Google      Sign In   
  • Create Account

C# - huh?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
37 replies to this topic

#21 GnomeTank   Members   -  Reputation: 195

Like
0Likes
Like

Posted 17 May 2007 - 10:57 AM

Quote:
Original post by DaBono
Quote:
Original post by skittleo
I would call C++ minimalistic. There's nothing built into the syntax of the language for strings, lists, dictionaries, etc. You can access most of the missing features through STL and boost [...] these features exist outside the basic syntax of the language.

The same is true for Java and C#. The actual Java-language has no knowledge about strings. However, any installation of Java comes with a really nifty library full of stuff like String-classes, data structures etc. You know, just like with C++ and it's runtime library (including STL).


There is still a difference. You can write, run and ship a C++ program without the STL. You can (and I have) write C++ in environments where the STL does not exist. You can't decouple C# and .NET, or Java and it's libraries, it just doesn't work. They ship as a package. If I am working in C#, I know for a fact I have the .NET facilities at my disposal, it's not something I have to think or care about. System.String will be there and it will have a primitive syntactic sugar element called "string" and it will support all the operations I need it to. Even if STL DOES exist in the C++ environment, is it a good implementation? Does it follow the standard?

Sponsor:

#22 ejele012   Members   -  Reputation: 100

Like
0Likes
Like

Posted 17 May 2007 - 11:19 AM

What's C#? Look here:

http://en.wikipedia.org/wiki/C_Sharp

http://en.wikipedia.org/wiki/Microsoft_Visual_C_Sharp

Can you use C# for game programmming?

Yes, you can. take a look here:

http://msdn2.microsoft.com/en-us/xna/default.aspx

#23 nobodynews   Crossbones+   -  Reputation: 1915

Like
0Likes
Like

Posted 17 May 2007 - 12:32 PM

Quote:
Original post by GnomeTank
Quote:
Original post by DaBono
Quote:
Original post by skittleo
I would call C++ minimalistic. There's nothing built into the syntax of the language for strings, lists, dictionaries, etc. You can access most of the missing features through STL and boost [...] these features exist outside the basic syntax of the language.

The same is true for Java and C#. The actual Java-language has no knowledge about strings. However, any installation of Java comes with a really nifty library full of stuff like String-classes, data structures etc. You know, just like with C++ and it's runtime library (including STL).


There is still a difference. You can write, run and ship a C++ program without the STL. You can (and I have) write C++ in environments where the STL does not exist. You can't decouple C# and .NET, or Java and it's libraries, it just doesn't work. They ship as a package.


Why can't you decouple C# and .NET? I mean, I guess you can't really write an operating system in C#... Oh wait, yes you can.

#24 Zahlman   Moderators   -  Reputation: 1682

Like
0Likes
Like

Posted 17 May 2007 - 01:45 PM

Quote:
Original post by RyanZec
Quote:

And think about all the time spent fixing bugs caused by unsafe operations.

And did C++ create these errors or did you?


I don't know. Did the chainsaw cut off your fingers or did you? Is the chainsaw safe?

#25 Josh Petrie   Moderators   -  Reputation: 3116

Like
0Likes
Like

Posted 17 May 2007 - 02:09 PM

Quote:

You can't decouple C# and .NET

Yes you can. .NET is just a CLR implementation, you can run C# on any CLR implementation. Furthermore, nothing in the C# standard really mandates that you use a CLR... you could have the language compile to native code if you liked (though nobody has bothered to implement such a C# compiler).

In any case...

Quote:

You can write, run and ship a C++ program without the STL. You can (and I have) write C++ in environments where the STL does not exist.

There are two things wrong here. First, did you really mean the STL (the old SGI library), or did you mean the SC++L (the modern standard C++ library, which contains some of what used to be the STL)? They are different, although commonly used interchangeable, so clarifying your meaning would help.

I'll assume you meant the SC++L, because that makes the most sense in this context. I'll also assume that by .NET you mean the standard library that is exposed by .NET (all the System.* stuff), since I already pointed out the fallacy in your statements when .NET is taken to mean the underlying common language runtime implementation.

In that case, you're still wrong. Just because you ship code that does not utilize the SC++L does not mean it isn't there. Likewise, just because you ship code that makes no reference to the System namespace doesn't mean it isn't there. But you can, in fact, ship code in both C++ and C# that does not make use of the standard library as long as you rely appropriately on 3rd party libraries (otherwise there's actually very little you can do with the language).

This tends to be true of many languages, in fact. The actual language intrinsics portion of a language tends to be very limiting, and the standard library facilities (built on top of those basic intrinsics) tend to be what gives many languages their expressiveness and power. The way that many modern languages (and even C++ is moving in this direction) entangle their language intrinsics with their standard library (for example, as syntactic sugar) is becoming increase more common and pervasive, so it makes even less sense nowadays to consider a language without its standard library.

Note that you can make the argument that you worked with an implementation of language X that lacked its standard library (for example, C++ without any of the standard headers), but this really doesn't hold up because such an implementation is not standard-conforming, at which point you can say, make or do pretty much anything with said implementation since it has no baseline. Consequently, any remotely standards-conforming C++ environment should ship with a remotely-standards-conforming implementation of the SC++L (but not necessarily the STL, as its the SC++L that is detailed in the C++ Standard document, not the STL, which is technically a 3rd party library despite what the S stands for).

#26 deadimp   Members   -  Reputation: 310

Like
0Likes
Like

Posted 17 May 2007 - 02:33 PM

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.

#27 guardian24   Members   -  Reputation: 100

Like
0Likes
Like

Posted 18 May 2007 - 12:42 AM

Not to mention, that there is C++/CLI, which imho completely undermines C#, unless
you never learned C++.


#28 benryves   Members   -  Reputation: 1992

Like
0Likes
Like

Posted 18 May 2007 - 12:57 AM

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]
[Website] [+++ Divide By Cucumber Error. Please Reinstall Universe And Reboot +++]

#29 fsm   Members   -  Reputation: 122

Like
0Likes
Like

Posted 18 May 2007 - 05:39 AM

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.

#30 RyanZec   Members   -  Reputation: 124

Like
0Likes
Like

Posted 18 May 2007 - 05:46 AM

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.

#31 Promit   Moderators   -  Reputation: 7189

Like
0Likes
Like

Posted 18 May 2007 - 06:12 AM

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 ™. Those problems mainly involve platform support, legacy codebases, and developer training.

#32 Ahnfelt   Members   -  Reputation: 176

Like
0Likes
Like

Posted 18 May 2007 - 06:39 AM

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.

#33 smitty1276   Members   -  Reputation: 560

Like
0Likes
Like

Posted 18 May 2007 - 06:47 AM

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

#34 guardian24   Members   -  Reputation: 100

Like
0Likes
Like

Posted 18 May 2007 - 01:34 PM

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

#35 Josh Petrie   Moderators   -  Reputation: 3116

Like
0Likes
Like

Posted 18 May 2007 - 02:06 PM

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.

#36 Promit   Moderators   -  Reputation: 7189

Like
0Likes
Like

Posted 18 May 2007 - 06:03 PM

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.

#37 guardian24   Members   -  Reputation: 100

Like
0Likes
Like

Posted 18 May 2007 - 08:53 PM

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

#38 Promit   Moderators   -  Reputation: 7189

Like
0Likes
Like

Posted 19 May 2007 - 05:16 AM

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




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS