C# or C++?!?!?!
July 3, 2006 7:57 AM Subscribe
C# or C++ for windows-based multimedia applications?
I usually work with Java, and have about zero knowledge of the internals of DirectX/Show/Sound. I want to access input streams from video cameras (or webcams or whatevs) and do audio output in close to real time. Is C# suitable for this or should I be putting time into C++ instead?
I usually work with Java, and have about zero knowledge of the internals of DirectX/Show/Sound. I want to access input streams from video cameras (or webcams or whatevs) and do audio output in close to real time. Is C# suitable for this or should I be putting time into C++ instead?
Response by poster: I probably won't be distributing this piece of software, so distribution of the .NET runtime isn't an issue.
Do I have alternatives to DirectX perhaps?
posted by beerbajay at 8:13 AM on July 3, 2006
Do I have alternatives to DirectX perhaps?
posted by beerbajay at 8:13 AM on July 3, 2006
C++ is probably the worst programming language invented. Based on a mishmash terrible principles, implemented in various confusing, incompatible compilers, and overflowing with various gotchas, it's really the only truely programmer-hostile language. Avoid it at all costs. A simple google search indicates that it's possible to use DirectX to C#, though you're potentially sacrificing some of the more advanced capabilities and performance. I'm not sure about the details but again, I'd avoid (Microsoft) C++ if possible.
posted by nixerman at 8:59 AM on July 3, 2006
posted by nixerman at 8:59 AM on July 3, 2006
Agreed with nixerman. My impression is that the only people who still use C++ do so because they have no other choice. C++ is necessary for things that absolutely must be super-super-super fast. However, I would argue that if you can write the same code in C# and just buy a faster machine, you would be far better off.
posted by Afroblanco at 9:05 AM on July 3, 2006
posted by Afroblanco at 9:05 AM on July 3, 2006
C++ is only a bad language when it's in the hands of bad programmers.
posted by cmonkey at 9:06 AM on July 3, 2006 [1 favorite]
posted by cmonkey at 9:06 AM on July 3, 2006 [1 favorite]
Exactly cmonkey. C++ is powerful, which means there is the capability to do great evil but also great good. Well written C++ can be efficient, portable and orders of magnitude faster and less resource intensive than other languages.
The upside, and the down, is that you are working much closer to the actual hardware than in other languages (especially managed ones like Java or C#). I would consider some knowledge and experience with C++ absolutely vital to nearly any programmer. A thorough grasp of "what is really going on" makes working in higher level languages much easier.
As to the original question, it may be possible in C#. This kind of application is usually done in C++ but if you don't mind having some really high system reqs then managed DirectX isn't bad at all. You will need to be pretty familar with C++ anyway because most of the DirectX docs are only available in C++ and you need to do a little conversion here and there.
BTW: About the distibution size of .NET, I wouldn't sweat it. It's actually about the same size of the Adobe Acrobat Reader and is available via Windows Update.
posted by Riemann at 10:33 AM on July 3, 2006
The upside, and the down, is that you are working much closer to the actual hardware than in other languages (especially managed ones like Java or C#). I would consider some knowledge and experience with C++ absolutely vital to nearly any programmer. A thorough grasp of "what is really going on" makes working in higher level languages much easier.
As to the original question, it may be possible in C#. This kind of application is usually done in C++ but if you don't mind having some really high system reqs then managed DirectX isn't bad at all. You will need to be pretty familar with C++ anyway because most of the DirectX docs are only available in C++ and you need to do a little conversion here and there.
BTW: About the distibution size of .NET, I wouldn't sweat it. It's actually about the same size of the Adobe Acrobat Reader and is available via Windows Update.
posted by Riemann at 10:33 AM on July 3, 2006
All the DirectX documentation will be better for the C++ APIs, and most if not all third party samples/documentation will be for the C++ APIs.
As for the C++ Haters/Language Hipsters, just ignore them. You'll probably take a few lumps switching from a higher level language like Java (don't let the similair syntax fool you), but you'll likely learn quite a bit that will help you be a better coder no matter what language you're using.
posted by hamhed at 12:29 PM on July 3, 2006
As for the C++ Haters/Language Hipsters, just ignore them. You'll probably take a few lumps switching from a higher level language like Java (don't let the similair syntax fool you), but you'll likely learn quite a bit that will help you be a better coder no matter what language you're using.
posted by hamhed at 12:29 PM on July 3, 2006
As for the C++ Haters/Language Hipsters, just ignore them.
More accurately, "As for the [any language] Haters, just ignore them." Or imagine them saying "hammers" or "phillips screwdrivers" in a workshop context - people who think any given tool is simply good or bad aren't worth your time.
Any MS language should be pretty easy to access DirectInput and DirectOutput with, however you might find life easier if you're using a language that is utilized for examples in the DirectX documentation. I see DX8.1 examples in VB but all the examples in my DirectX 9.0c update seem to be C++, though a quick google for "directinput c#" turned up this tutorial at Riemers. It's heavy on 3D rather than DI/DO but for syntax and using DirectX in your chosen language it could be useful...
Have you looked at the information at the DirectX dev center?
posted by phearlez at 12:58 PM on July 3, 2006
More accurately, "As for the [any language] Haters, just ignore them." Or imagine them saying "hammers" or "phillips screwdrivers" in a workshop context - people who think any given tool is simply good or bad aren't worth your time.
Any MS language should be pretty easy to access DirectInput and DirectOutput with, however you might find life easier if you're using a language that is utilized for examples in the DirectX documentation. I see DX8.1 examples in VB but all the examples in my DirectX 9.0c update seem to be C++, though a quick google for "directinput c#" turned up this tutorial at Riemers. It's heavy on 3D rather than DI/DO but for syntax and using DirectX in your chosen language it could be useful...
Have you looked at the information at the DirectX dev center?
posted by phearlez at 12:58 PM on July 3, 2006
While C++ can be well written, and is certainly faster than C#, it's also significantly trickier. I'd say you'd be better off writing your app in C# initially, and if there are some parts that need the extra oomph, implement them in C++ modules called from your C# code.
(I'd even go so far as to say you should write the app in Python (calling C++ for fast bits). At the very least, prototyping in Python will enable to get the design sorted quickly, then you can rewrite it (or the performance-sensitive parts). But I know that's not really what you asked.)
posted by wilberforce at 1:08 PM on July 3, 2006
(I'd even go so far as to say you should write the app in Python (calling C++ for fast bits). At the very least, prototyping in Python will enable to get the design sorted quickly, then you can rewrite it (or the performance-sensitive parts). But I know that's not really what you asked.)
posted by wilberforce at 1:08 PM on July 3, 2006
A few points on why C++ can be easier and more fun, if you do it right:
RAII, so you can do stuff like this:
void myclass:foo() {
{
hisMutex( this ) ;
// do stuff, the mutex is released when local scope is exited. set it and forget it
}
}
A Standard Template Library that's really well thought out, with extremely modular parts. Plus all the additional stuff you can get from boost.org. Compare this to the mish-mash of Java containers, only somewhat re-jiggered in more recent releases to play nicely together, and still able to throw a MethodNotImplemented exception! (That's design by contract????)
With RAII and the STL, you never have to call new() or delete(); it's like having managed GC, without the GC overhead.
Templates. Real templates, not the hidden conversions to void pointer so you have to use reflection nonsense you have in Java. synthesized classes that are also actually their own types. This allows all sorts of compile-time programming. Read Alexandrescu's book, it'll free your mind.
Conversion operators. Yes, in other OOP languages you can have converting ctors, but you wouldn't get them automatically invoked by Koenig lookup. and you won't have conversion operators, so you'll call redundant function names like OtherType toOthertype().
Not to mention functors. In Java, every time you want a simple functor (or even a function pointer), it's time to write a new class. With the right templates, functors can require almost no programmer effort beyond a declaration. And value templates are automatically idempotent, no need for writing code to ensure your singleton object really is a singleton.
The ability to bit-twiddle if you really need to. Remember 80/20, and be prepared for the 20% that managed languages won't let you get at.
Multiple inheritance, if you need it, instead of endless parallel hierarchies. How many times in Java have you cursed because you can't (without re-writing the world or at least a bunch of stubs calling the real implemented-in-terms-of functions) have something be a FooBean and a BarBean or a Container and a Widget?
Value object with copy ctors instead of pointer aliasing and broken clone() methods. Automatics on the stack rather than paying for heap allocation with new(). The ability to write, for any class, its own new operator to use a class-specific memory allocation scheme. The ability to pass allocators functors to all STL containers.
Orthogonal construction of class types from aspects (again, Alexandrescu). Don't write a class, construct it out of aspect primitives.
There's a lot more room in C++. yes, that can be intimidating, but it can also be freeing.
I'd love to be doing C++. Unfortunately, the last recruiter I talked to explained his clients are willing to pay for C++ only half what they'll pay for Java.
posted by orthogonality at 1:57 PM on July 3, 2006
RAII, so you can do stuff like this:
void myclass:foo() {
{
hisMutex( this ) ;
// do stuff, the mutex is released when local scope is exited. set it and forget it
}
}
A Standard Template Library that's really well thought out, with extremely modular parts. Plus all the additional stuff you can get from boost.org. Compare this to the mish-mash of Java containers, only somewhat re-jiggered in more recent releases to play nicely together, and still able to throw a MethodNotImplemented exception! (That's design by contract????)
With RAII and the STL, you never have to call new() or delete(); it's like having managed GC, without the GC overhead.
Templates. Real templates, not the hidden conversions to void pointer so you have to use reflection nonsense you have in Java. synthesized classes that are also actually their own types. This allows all sorts of compile-time programming. Read Alexandrescu's book, it'll free your mind.
Conversion operators. Yes, in other OOP languages you can have converting ctors, but you wouldn't get them automatically invoked by Koenig lookup. and you won't have conversion operators, so you'll call redundant function names like OtherType toOthertype().
Not to mention functors. In Java, every time you want a simple functor (or even a function pointer), it's time to write a new class. With the right templates, functors can require almost no programmer effort beyond a declaration. And value templates are automatically idempotent, no need for writing code to ensure your singleton object really is a singleton.
The ability to bit-twiddle if you really need to. Remember 80/20, and be prepared for the 20% that managed languages won't let you get at.
Multiple inheritance, if you need it, instead of endless parallel hierarchies. How many times in Java have you cursed because you can't (without re-writing the world or at least a bunch of stubs calling the real implemented-in-terms-of functions) have something be a FooBean and a BarBean or a Container and a Widget?
Value object with copy ctors instead of pointer aliasing and broken clone() methods. Automatics on the stack rather than paying for heap allocation with new(). The ability to write, for any class, its own new operator to use a class-specific memory allocation scheme. The ability to pass allocators functors to all STL containers.
Orthogonal construction of class types from aspects (again, Alexandrescu). Don't write a class, construct it out of aspect primitives.
There's a lot more room in C++. yes, that can be intimidating, but it can also be freeing.
I'd love to be doing C++. Unfortunately, the last recruiter I talked to explained his clients are willing to pay for C++ only half what they'll pay for Java.
posted by orthogonality at 1:57 PM on July 3, 2006
Unless you're going to be doing processing, go with C#. It'll be easier all-around to manage. If you're going to be processing the video, consider writing the processing component in C++ and calling the native code from within C#.
I love C++; I think its the most flexible & the best language hands down. But its not ideal for every task, and this sounds ike something you just want to whip out.
posted by devilsbrigade at 3:49 PM on July 3, 2006
I love C++; I think its the most flexible & the best language hands down. But its not ideal for every task, and this sounds ike something you just want to whip out.
posted by devilsbrigade at 3:49 PM on July 3, 2006
For multimedia you should use C++.
If you can, look for a modern major game for the PC written with the core being something other than C++. Ask yourself why. Are all the game programmers out there stupid or is there a good reason for this?
For console development, C is still used because of the overhead of C++ and the limitations of console processors, in particular on the Playstation and Playstation II.
You may also want to check out Bink if you're going to be doing things with video. It is easier to use than the DirectX APIs.
posted by sien at 3:59 PM on July 3, 2006
If you can, look for a modern major game for the PC written with the core being something other than C++. Ask yourself why. Are all the game programmers out there stupid or is there a good reason for this?
For console development, C is still used because of the overhead of C++ and the limitations of console processors, in particular on the Playstation and Playstation II.
You may also want to check out Bink if you're going to be doing things with video. It is easier to use than the DirectX APIs.
posted by sien at 3:59 PM on July 3, 2006
Wha? C is still used because of the overhead of C++ and the limitations of console processors? I call bullshit. RTTI has overhead, the STL has overhead in parts, exceptions need RTTI to function properly (yet compilers find ways around this fairly often), sure. But the majority of C++ code will compile identically to C code, with identical optimizations. These processor limitations you refer to are, I'm guessing, floating point, which is handled identically (except for some weird stuff with C99, I think) in C and C++.
The question wasn't for games, where yes, every drop of performance matters (although even now, many games are going to a C++ base with a scripting language for the UI and logic). The question was for a 'multimedia app' that takes video and outputs realtime audio. This is completely within the realm of C# and DirectX, if no processing needs to be done.
posted by devilsbrigade at 4:19 PM on July 3, 2006
The question wasn't for games, where yes, every drop of performance matters (although even now, many games are going to a C++ base with a scripting language for the UI and logic). The question was for a 'multimedia app' that takes video and outputs realtime audio. This is completely within the realm of C# and DirectX, if no processing needs to be done.
posted by devilsbrigade at 4:19 PM on July 3, 2006
I forgot to finish the first part. Playstation & Playstation II had proprietary APIs which were exposed as C function calls. The choice to use C for games, if that was indeed the case, was likely because of the availability of an optimizing compiler for the MIPS processor it used, or experience and preference of the development team.
posted by devilsbrigade at 4:21 PM on July 3, 2006
posted by devilsbrigade at 4:21 PM on July 3, 2006
I see C and C++ as almost completely different languages. C is simple, elegant, and gets the job done. You can use it to write an operating system or program an elevator controller. Everyone should know C. C++ is a clumsy attempt to make C an OO language. Unless you want to wrestle with crap like compiler-generated temporaries and virtual deconstructors, I would reccommend a more modern language.
Also, there is the issue of bugs. For example, nearly every major bug in Windows, security or otherwise, is due to it being written in non-managed code. Start working in managed code, and little problems like memory leaks and buffer overruns magically disappear. In C++, expect to spend a lot of time tracking down these nastly little bugs, whereas in C# or Java, you would get a nice obvious exception, accompanied by a convenient stack trace.
posted by Afroblanco at 5:04 PM on July 3, 2006
Also, there is the issue of bugs. For example, nearly every major bug in Windows, security or otherwise, is due to it being written in non-managed code. Start working in managed code, and little problems like memory leaks and buffer overruns magically disappear. In C++, expect to spend a lot of time tracking down these nastly little bugs, whereas in C# or Java, you would get a nice obvious exception, accompanied by a convenient stack trace.
posted by Afroblanco at 5:04 PM on July 3, 2006
You can consider C# to be functionally identical to java, but with more keywords. Writing C# feels a lot like Java. As my 19th programming language, I spent a lot of time reading the C# spec nodding and a small amount of time saying to myself, "have you learned nothing?" For example, there are language features that create design patterns that are simply not optimizable under any circumstances.
The ability to hook into windows dlls and call functions as if they were built-in methods makes it quite easy to get into existing APIs. Having written native method hooks for three different Java VM's, this was a joy.
C# does not have good support for DirectX (yet) or multimedia (yet), but most of that will be obsoleted in the next rev of Windows. And since it's easy enough to interface to native dll's this is easily worked around.
If you're going for C# you should seriously consider the 2.0 language. The addition of generics makes it much easier to manage aggregates.
The Windows forms libraries are functional, but from a UI point of view, they still suck pretty badly, but they don't suck as badly as MFC.
No matter what, you'll be reading a lot of DirectX and DirectShow references.
You might look at CDX which wraps a lot of DirectX functionality in a tastier wrapper. Last I checked, there was a .NET version as well.
posted by plinth at 6:48 PM on July 3, 2006
The ability to hook into windows dlls and call functions as if they were built-in methods makes it quite easy to get into existing APIs. Having written native method hooks for three different Java VM's, this was a joy.
C# does not have good support for DirectX (yet) or multimedia (yet), but most of that will be obsoleted in the next rev of Windows. And since it's easy enough to interface to native dll's this is easily worked around.
If you're going for C# you should seriously consider the 2.0 language. The addition of generics makes it much easier to manage aggregates.
The Windows forms libraries are functional, but from a UI point of view, they still suck pretty badly, but they don't suck as badly as MFC.
No matter what, you'll be reading a lot of DirectX and DirectShow references.
You might look at CDX which wraps a lot of DirectX functionality in a tastier wrapper. Last I checked, there was a .NET version as well.
posted by plinth at 6:48 PM on July 3, 2006
Just want to throw my two cents in and say that I agree with everything orthogonality said. If you want real-time audio processing from a video/audio device, cycles matter. C++, the mean, bastard-child that it is, simply cannot be matched in either its performance or the depth and breadth of its libraries. And those are the two things that are going to matter to you most.
If .NET were so wonderful, Microsoft wouldn't have ditched the Vista .NET re-write and switched back to C++ (almost completely because of performance issues). Just keep an eye out for dangling references.
posted by Civil_Disobedient at 8:43 PM on July 3, 2006
If .NET were so wonderful, Microsoft wouldn't have ditched the Vista .NET re-write and switched back to C++ (almost completely because of performance issues). Just keep an eye out for dangling references.
posted by Civil_Disobedient at 8:43 PM on July 3, 2006
To qualify the remark on the playstation 2. C is still sometimes used. I went with a group of people to a development house for some stuff we were thinking of contracting out - the lead there said they were using C for their playstation 2 development and had tried C++ but had problems. They said the problem were mainly cache use, but this was a while ago and my memory may be faulty - but they definitely said they were developing with C.
posted by sien at 10:28 PM on July 3, 2006
posted by sien at 10:28 PM on July 3, 2006
Response by poster: Thanks for the answers everybody. I shall probably put my head into C++ for the time being.
Are there any further recommendations for alternatives to DirectX?
posted by beerbajay at 3:58 AM on July 4, 2006
Are there any further recommendations for alternatives to DirectX?
posted by beerbajay at 3:58 AM on July 4, 2006
The use of C in the game industry is largely dead or dieing. I've only been in the industry about a year, but in that time I've only heard about one studio that still uses C, and maybe a few coders who want to use C over C++(at least, who have been vocal about it).
As for C being faster than C++, that's a murky area. C may not have some of the overhead that C++ does, but in some areas C++ can do things better, like functor objects vs function pointers (the functor objects can be inlined) or compiler tricks thanks to C++'s tighter scoping.
posted by hamhed at 2:30 PM on July 4, 2006
As for C being faster than C++, that's a murky area. C may not have some of the overhead that C++ does, but in some areas C++ can do things better, like functor objects vs function pointers (the functor objects can be inlined) or compiler tricks thanks to C++'s tighter scoping.
posted by hamhed at 2:30 PM on July 4, 2006
This thread is closed to new comments.
However, Managed DirectX is like a neverending adventure of new versions and minimal documentation. Everytime I've played with it, it feels only half baked. Half of the reason I'm giving you my only-slightly-informed option is I'm hoping someone else on AskMe will come along with a brilliant answer which says "yes, this is how to use DirectX with .NET!". Cuz in my casual research I haven't found anyone who can say that yet.
Two other issues with C#/.NET you should be aware of. 1: C# apps require the runtime be installed on the Windows machine. It's not quite as bad as needing Java, but if you're distributing your app you should consider whether your customers have or are willing to install a 20 meg runtime. 2: C# is garbage collected and I have no idea how well their GC works with latency-sensitive apps like video and games. After 10 years Java still hasn't really nailed this, don't know if .NET is better.
posted by Nelson at 8:07 AM on July 3, 2006