Which C platform is better for programming?

[MrSeanKon]

I was discussing with gizmo at MSN about Visual C++ vs C#.
Well I started programming the OcBible using Borland C++ Builder (2003) and at May of 2005 I moved to C#.
The heart of the program could be written in ANSI C but I want to share something well looking.

[Allan]

Tricky question, it isn't a matter of the one being better than the other, since they both have their pros and cons.

With C#, you can so easily make a program with a lot of fancy GUI and stuff. However, it will run slower than a similar program in C++, and the user must have the .NET framework installed. On the other hand, while C++ is faster at run time, it takes more time to make the same program, and you have a lot of things to worry about (who said pointers?).

For quick programming I'd go with C# anytime. You can use platform invocation (Pinvoke) to access non-C# stuff.

But what do I know, I'm mainly programming in C for embedded devices...

[Gizmo]

That pretty much summarizes my opinion on the issue as well Alan. But then again, I tend to like getting into the dirty stuff anyway.

[MrSeanKon]

Originally Posted by Allan

With C#, you can so easily make a program with a lot of fancy GUI and stuff

This was my first ideas when I stopped programming in Borland.
Both Visual C++ and C# are Microsoft products but C# is easier.
Of course I do not care for code executation time cos OcBible performs simple instructions.
Only some *.dlls are hungry for CPU performance.

[Gizmo]

And this is the heart of good programming; pick the right tool for the job.

A programming language is nothing more than a tool.

[MrSeanKon]

I agree gizmo.
For example the OcBible could written in MSDOS enviroment but this is boring for user.
I forgot anything about Pascal that's why I did not program in Delphi although it is a popular tool.
On the other hand as we chatted in MSN Visual C++ allows you assembly programming and Win32 API calls.
Two necessary issues for next OcBible editions.
Hopefully Visual C++ routines run OK under C#.

[Gizmo]

Originally Posted by MrSeanKon

Hopefully Visual C++ routines run OK under C#.

They do. I've actually written some C++ dlls in the past that were called from C#. The easiest way to do it, though, is to make the C++ code a COM object, and then the C# application can just import the COM object and use it like anything else.

[MrSeanKon]

Thanks gizmo.
BTW have you ever used an alternate graphical C enviroment?

[Gizmo]

I used Borland Turbo C many years ago with the Object Windows Libraries (OWL)

[MrSeanKon]

This was the previous enviroment version before *.NET.
BTW I do not know any other C Windows platform except of Borland and Microsoft.
If someone knows anything else let me know....

[chrisbard]

While @ it don't forget your Vitamin C dose

[MrSeanKon]

What do you mean?

[chrisbard]

Nevermind, just a poor joke

[Daniel ~]

No sweat Chris, poor jokes are the only one I can afford to get! ":O}

[MrSeanKon]

Originally Posted by chrisbard

Nevermind, just a poor joke

No more http://www.geocities.com/seankoniari...s/offtopic.gif
Continued....
gizmo I would like your opinion about Visual C++ vs. C#
The first platform is more complex IMHO but offers more capabilities e.g. Win32 API access.
For example which source code runs faster?
WMI commands using C# or Visual C++ and Win32 API?

[MONKEYMAN]

Chill out, thats what Chrisbard is here for

[Gizmo]

Originally Posted by MrSeanKon

No more http://www.geocities.com/seankoniari...s/offtopic.gif
Continued....
gizmo I would like your opinion about Visual C++ vs. C#
The first platform is more complex IMHO but offers more capabilities e.g. Win32 API access.
For example which source code runs faster?
WMI commands using C# or Visual C++ and Win32 API?

Actually, there are 4 options here:
C++ and Win32
C# and Win32
C++ and WMI
C# and WMI

The performance penalties associated with C# and WMI can be pretty severe. C# itself introduces roughly a 15% performance hit, in my experience. WMI can be accessed through a COM interface which is normally fairly efficient, but when coupled with C#'s marshalling code you take another 10%-15% performance hit.

C# to Win32 is even worse, because you have to write custom marshaling code or use the Microsoft.Interop stuff, or use PInvoke to access it. In my experience, there is typically about a 25% overhead in doing any of that.

C++ to WMI is pretty efficient.

C++ to Win32 will be probably 5%-10% more efficient than WMI, but brings with it a lot of baggage. WMI aggregates a lot of interfaces and information that are scattered throughout the Win32 API (and even some protected CPU instructions), and which also vary across operating system versions from Win95 to Win98 to WinMe to WinNT to Win2K to WinXP to Vista, into a single easy-to-use API.

To be fair, there are some variations of the WMI implementation across the various OSen, but those issues are documented. In addition, WMI isn't installed on 9x or WindowsNT 4, but you can download it from MS and install it on those machines.