Recommendation: C++ coding instead of C# & .NET (1 Viewer)

[Anonymous]

Media Portal is everything I wanted in an HTPC setup but there is a downfall using C# & .NET over C/C++. C/C++ would make it faster and more stable. I currently have a AMD Athlon XP 1900+ with 512 MB RAM and 128 MB nVidia GeForce 4 MX AGP Card. This program is slow compared to other HTPC interfaces due to C#. By converting it to C++ this would allow for the ability for it to be ported over to linux as well and more support for people who would like to help donate to the project.

 

[MrMario64]

it's C# and it will remain C#...
And we have no desire to be ported to linux..

And if it's running slow for you you prolly don't have a DX9 compatible card causing some rendering being done by emulation on the CPU.

It's running very fast for me, and I really do not have a power house PC.

 

[Anonymous]

C++

There are an advantage from using C++. But you know how much work would be an port of the whole MP?

Better take up to date hardware like MrMario64 said.

Maybe the next NET-Framework gives MP an speedbump...

greets
agree

 

[Frodo]

c++ may be a little faster then C# but not that much
If we want to make MP faster we should look what exactly is to slow right now according to you. Then see why it is slow and maybe to some refactoring to speed it up. I think we can get far more speedup from refactoring some code then by just converting everything to c++
also c++ is not more stable then C#, you'll have todo all memory tracking yourself so memory leaks are very very easy to make

so, lets start the discussion
which part(s) in MP do you find slow?

Frodo

 

[Anonymous]

In addition it is unlikey that and speed issues are because of TV/Capture or other hardware. MediaPortal uses and calls directshow via COM interop there is very little overhead in the interop and all of the major processing work is done by directshow which IS stable, IS tested and is used by damn near everyone else on windows in their products.

Because we use directshow we can support almost all types of video hardware under windows.

Because we user directshow/directx you will never see mediaportal under and flavor of unix.

Sorry, but thats the way it is.

and frankly I can do C++ but if this project was C++ I would no be volenteering. C# means I don't have to worry about a lot of things and it leaves me time to work on feature and functionality.

No memory leaks (do a degree), no pointer hassles etc.

 

[Anonymous]

The other bonus of course is that people can write plugins and other functionality in the language of *their* choice be it managed C++, Visual Basic, Perl, Effiel even Cobol!

Now beat that

 

[dman_lfc]

which part(s) in MP do you find slow?

I think you need to start another thread on this as this thread title may not get the interest you're after Frodo.

On my system everything runs AOK however it's pretty beefy. (specs below)
There are people who want to run in smaller cases and lower spec'd CPU's to reduce heat and typically use the integrated video cards as well. (lower cost HTPC)

I would say that the higher (typically 20%) extra CPU utlisation because MP re-draws the whole screen continuously is cause for concern. This GUI overhead does not allow some MP entusiasts to play back certain files with certain codecs as the CPU hits 100% and they may get choppy / stuttery sound.

The other issues that are minor on my system but may be major on others is when going into myTV it take 1-2 seconds to start - I don't know if any optimising can be done here.
There have been reports from other users where MP starts slowly as well.

You fixed the thumbnails loading slow in 0.0.0.12 with the latest CVS - so thanks!

Again - I would start another thread to get far more feedback.
I would start it as a template whereby the HTPC specs are provided to you etc.

DMAN.

 

[Anonymous]

it's C# and it will remain C#...
And we have no desire to be ported to linux..

And if it's running slow for you you prolly don't have a DX9 compatible card causing some rendering being done by emulation on the CPU.

It's running very fast for me, and I really do not have a power house PC.

This is clearly a anti-M$ issue than a what language is better/faster thing. You probably didnt want to have to install .NET. I don't blame you, but get off it, C# has proven itself to be a very useful language, and is one of the reasons MP is feature-packed this early in its development.

Also, as has been already covered in other posts, if you find MP slow, there's probably something wrong with your configuration. I too had a crappy non-DX9 video card in my desktop system, and MP ran slow. I bought a $50 fanless 128MB Gainward GeForce FX 5200, and MediaPortal's performance increased dramatically.

Lastly, Linux already has a great HTPC program to boot (MythTV) which has many features that MediaPortal doesnt, and vice versa. Trust me , I kow, I ran it for 6 months. So there's even LESS of a reason to want to port it.

 

[waeberd]

... and if you imposed C++, you wouldn't find as many plugin coders as you can find now! I certainly wouldn't have coded MP parts in C++....

... and I seriously doubt that C++ would make MP more stable!

 

[Mars Warrior]

Let's Retire C and C++

Let's Retire C and C++

They are tired and they can kill productivity

C and C++ are old and tired languages that have outlived their usefulness. For programmers, there are more productive ways to develop software. The odds of getting engineers a reliable program to use are significantly better with C#. While C and C++ are expressive and powerful languages, letting anyone but very experienced programmers use them is like greasing the floors and letting your programmers run across it with knives. The most likely victims will be schedules and/or code reliability.

Productivity is significantly influenced by a language's ease of use and the time it takes to debug and fix problems. Any language that requires a book like "C++ Gotchas", which describes 99 common C++ programming mistakes, has serious usability issues. For instance, who really has a handle on how to decipher C type declarations like:

char *(*(*a[5])())();

Don't get me started on the myriad string data types and APIs you have to deal with: ASCII char*, multi-byte char*, wchar_t, CString, BSTR, CComBstr, _bstr_t and basic_string<>. Come on! How many different ways of dealing with a string do we need?

By far the biggest productivity killer is the vast potential for writing buggy C or C++ code. Dynamic memory management and the pointers typically used in conjunction with them get more programmers into trouble than any other feature of C or C++. If you don't remember to explicitly free memory you have memory leaks. If you access memory that has been freed, your program may crash or behave unexpectedly. Indices used to access arrays are not validated in C or C++. As a result, an "off by one" error can cause undetected memory stomps that in turn can cause your program to crash somewhere completely different than where the stomp occurred.

C# leaves C and C++ in the dust when it comes to programmer productivity. C# and the underlying Microsoft .NET platform put to good use the exponential improvement in computing power that has occurred in the 30 years since C was created. The extra compute capacity is used to provide automatic garbage collection, which eliminates memory leaks and freed memory reads altogether. Array accesses are always checked at runtime to verify the index is valid; this eliminates one source of memory stomps. Since C# doesn't require the use of pointers, another class of memory stomps are eliminated. While these services require a little extra computing power, the way I look at it is that hardware is cheap, software development time is not.

Many C/C++ programmers are concerned about standards and performance. C# has been standardized by both ECMA and ISO. C# performance is not only better than Java and Visual Basic, it also isn't too far off the performance of C/C++. Furthermore, most instrumentation automation programs are performance limited not by the development language but by instrument I/O.

It is very easy to get started using C#. You can download the Microsoft .NET Framework SDK for free at: http://msdn.microsoft.com/netframework/downloads/howtoget.aspx.

The SDK comes with the C# command line compiler as well as many sample programs. I predict that you will be pleasantly surprised at how far your C or C++ skill set can take you with C# and how much more productive you will be!

And that my friends, ends this happy story :lol: