.Net Language Question (but not really programming...)

Red Stateler

We use C++/CLI. I think you should use c#.

Red Stateler

Nemanja Trifunovic wrote:

However, it was released too late, the name is horrible (most people consider CLI to be "command line interface"), and the marketing support from MS is weak.

Are those really good reasons too stay away from it?

Nemanja Trifunovic wrote:

Also, the level of VS support for it is worse than for VB or C#.

That's a huge understatement.

James R Twine

espeir wrote:

We use C++/CLI. I think you should use c#.

OK - but for what reason(s)? Lacking language-specific support for .Net features? IDE support for the language? Developer support for the language? Peace! -=- James

If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)

Nemanja Trifunovic

espeir wrote:

Are those really good reasons too stay away from it?

You tell me :)

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

Red Stateler

Overall, I like C++/CLI as a language. Mixed mode programming is pretty easy and straightforward, so if you're writing something that requires a lot of native code mingled with managed code it's a good thing. However, VS2005 simply does not support development as fluidly in C++/CLI as it does in c#. Here are a couple of examples off of the top of my head: -Intellisense :(: In c# it works wonderfully. In C++/CLI it works about half the time. In c#, when you begin typing, intellisense immediately pops up, whereas in C++/CLI, you have to use "this->" in order for intellisense to pop up with information about the current object. Plus there's that annoying "updating intellisense" nonsense that locks the IDE for minutes at a time. To my knowledge that does not happen with c#. -The Designer: It breaks. I sometimes get a "catostrophic error" in the designer just by removing a space or two from the designer-created code. It's also annoying that when events are added, the generated code is added to the header file (instead of just the definition). The code it creates can also be very messy. -Signing: In c#, you just go to properties and tell it to sign the assembly. in C++, you have to use some external tools non-straightforward tools to get it to work. -ClickOnce support: It looks kind of cool. But that's only in theory for me as, despite following some blogged directions (as none are really provided for a C++/CLI app) I haven't been able to get it to work properly. With c#, you pretty much press a button. I really have no problems with the language itself. For me it's entirely the IDE that gets under my skin.

Judah Gabriel Himango

I've been involved in porting a large Java app to the .NET framework. The Java app had lots and lots of native interop via JNI (java native invocation services, Java's fugly way of calling native code). I first tried P/Invoke, and what a pain to do. I ended up writing a little C++/CLI dll that easily communicates with native and sends the data back over into managed land with almost no effort. I was impressed. :cool: Also, the speed of calling native code via C++/CLI is far faster than using P/Invoke from C#; Nish has written an article on this. That said, I agree with the others; C++/CLI is a pretty good language and quite useful in my scenario, but the IDE support is far worse than C# IDE support. I wouldn't start a .NET project from scratch in it; for that I'd use C#. However, I would certainly use it again if I need lots of native interop.

Tech, life, family, faith: Give me a visit. I'm currently blogging about: Moral Muscle The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

Rama Krishna Vavilala

Nemanja Trifunovic wrote:

Nope. VB.NET seems to be much more used than C#.

I have some doubts about that. In my research I see that C# is used more than VB.NET. I have been trying hard to find some proof of that. Here are the reasons for my doubt: 1. Most of the books which have VB.NET version and C# version did not have good sale of the VB.NET version e,g. Chris Sells Programming windows forms. 2. The programming language popularity (which is contriversial) index which I posted last time show VB.NET popularity less than C# 3. I have seen a few projects which started in VB.NET but moved to C#.

My Blog

Nemanja Trifunovic

Rama Krishna Vavilala wrote:

Nemanja Trifunovic wrote: Nope. VB.NET seems to be much more used than C#. I have some doubts about that. In my research I see that C# is used more than VB.NET. I have been trying hard to find some proof of that.

My source:[^] " while I can't publicly state the actual numbers, I can tell you that there are many times more Visual Basic developers than C++ and C# developers.".

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

Rama Krishna Vavilala

I had seen that but he says there are more Visual Basic Developers. I don't have any doubts that there are more Visual Basic Developers which includes VB6. My doubts are about VB.NET developers. I see that for .NET development companises are using C# over VB.NET.

My Blog

James R Twine

Note that Tom writes that "there are more VB developers than C++ and C# developers." However, it is a tad of a leap to read that as "there are more VB**.NET** developers than C++/CLI and C# developers." He also mentions that there are more VB articles partly due to the fact(?) that VB developers are less likely to read a C# or C++-based article than the other way around, and then loads what he said by writing "I'll leave trying to surmise why this is true to the reader." This basically sounds like they (MS) are writing for/to the lowest common denominator (thus increasing the total number of readers), but not necessarily that VB rules the .Net world. Peace! -=- James

If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)

Joe Woodbury

The support for C++/CLI in Visual Studio 2005 is utterly lame compared to the support for C#, the amount of sample code for all but the most trivial operations is non-existant, the documentation stinks and Microsoft doesn't promote it. I am sure there are people within Microsoft who think C++/CLI is great--my own testing of it found it sometimes did result in faster managed code, sometimes significantly faster, than C#--but Microsoft itself appears not to care a whit. My own experience is that many of the productivity gains developers claim with C# are the nice additions to editing code (note the word many--I'm not saying all.) By contrast, C++ is treated as the ugly step-child by VS 2005 and C++/CLI even worse. Frankly, if the reverse were true, I'm sure people would be asking if C# was worth it. (I think even .NET would be taken less seriously, especially if Microsoft had significantly improved MFC back with VS 2002/2003.) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke

Rage

James R. Twine wrote:

Are enough people using it

Ah, everyone may use it ? I thought that was a language they had developped only for Nish to play with :) ~RaGE();

chrismueller consulting

It all depends on your company. If your company is full of C or C++ programmers, then you will probably use C#. Under .net, both C# and vb.net produce virtually identical MSIL (intermediate language), so there is really no fundamental reason to choose one over the other. That leaves the choice to personal preference, which will usually be whatever you are more familiar with. I can say that C++ is no longer popular. The choice for any new projects is between C# and vb.net. --Chris

ad_green

With regards to momentum I don't think it's really relevant. C++/CLI (wish it had a simpler name C##?) has a niche which I think raises it above considerations of momentum. Importing some win32 api functions is one thing but when you get to the point where you need to expose a managed api to a high performance native system you accept no substitutes. As to C# being de facto, it's a funny situation. I feel that way too yet I always seem to run into VB developers and hear about VB in person. So the reality and the media disagree in my area. At first I thought that Visual Basic was the CLS compliant language. No unsigned ints, no signed bytes, no pointers. But it wasn't until very recently that I finally realized that I had it backwards. C# IS the least common denominator. Pointers aside there are probably more VB-specific language features than C# features. They aren't always significant but for about 50% of the common scenarios there's a C# way, a VB translation of that way, and a VB specific way. So naturally if you want a code sample to be stripped to its barest you'd put it in C#. As far as being closer to the metal, it's all IL and I've disassembled enough methods to see that in the end equivalent code (if you know what that is) is generally equivalent in on the IL side. I don't honestly think you can be closer or fit better with .NET. You really fit or you don't. Besides the Microsoft Languages C++/CLI; C#; and Basic there are a host of dozens of other non MS .NET languages which we shouldn't discount. But if I had to describe a nich for each of them I'd argue that C++ is the high performance lowest level systems engineering language. Basic and C# are both Application programming languages however there are cases where you can use some of the darker C# features to squeeze an extra ounce of performance out of some method that'll be in a tight loop (though I am more likely to write the method in IL than use the heathen language!). If you need hardcore productivity, deadline tomorrow at noon, all-nighter prototyping then Basic shines there. This doesn't mean these languages are stuck in these roles (I personally think that C++/CLI is so awesome it almost negates C# and it makes me ashamed to have ever uttered the words Managed Extentions for C++) Only that that's where the language devs priorities are. Last but not least, as a .NET developer you have the easiest language transitions on the planet. You have almost no excuse for not being partially multilingual (not like you have to learn a new librar

machman1

This is not to add fuel to the fire, but it is good for me to hear that someone else thinks that C# and VB.Net are interchangable. My thought is that VB is so underrated and the main reason that people drift towards C# is because they have come from the C, C++ camps.

Armimema

One Reason: Ease of programming! I am (used to be??) a C++ developper, but had to do a project in C#. The switch to C# was extermely easy, prabably easier then the switch back to C++ (you get used to the new language constructs and the oh so dreaded garbage collector) Arend

Xoy

Yeah C# and vb are pretty much interchangable. There are some miniscule differences in the il they generate (which has to do with what it is supposed to do with it) but other than that its pretty much a line-per-line equivalence :) like one of the differences is with equality comparision... string equality under vb dictates that "" = nothing, but not under C#. oh and vb gives the option of having implicit declarations and the such... Might work for learning, but it gets annoying to find bugs - just turn option explicit & option strict on as the project defaults and its good to use :cool: People who make a fuss about it will throw an fit about little differences like that, but... all in all, it won't affect much - they are almost identical. As for reasons people don't like using vb... Many people grew up with cish languages... C/C++, java, etc... So yeah, its much easier for them to use C# - its what they are used to. vb would involve learning less familiar keywords. Also, vb has improved much over time... some people are still comparing new products to old old versions... like vb 6... 4... 1... Qbasic... OLD VB CLONES THAT DON'T WORK RIGHT (stares at some people)