Printable View
Yes, it's the little things in life.Quote:
Originally Posted by darwen
In C++/CLI you do have to type a lot more in order to get the same compiled code, like you say there's the :: insted of . and also -> instead of . for most objects.
By the way, just to avoid confusion, the equivalent of 'as' is dynamic_cast because it returns nullptr if the cast is unsuccesful while the (Type) cast in c# is equivalent to the safe_cast in C++/CLI because it will throw an exception.
Thereupon, I think, we hit on the main marketing drive behind .NET.Quote:
Originally Posted by darwen
Java has a wide appeal because it is multi-platform. .NET has wide appeal because it is multi-syntax.
Both approaches raise the number of people who will seek to use the language, with .NET perhaps having the advantage in that we peons can extend .NET with new syntaxes (Ruby.NET, COBOL.NET) and some brave souls even attack the problem of moving the .net VM to another platform (Mono)
While the same could be true of java, I dont recall anyone writing a VB-to-javabytecode compiler (-> would bring VB programmers into the java world) and because that extension of syntax options isnt present, .NET starts to win in terms of market appeal
In viewing C++/CLI as "CLI with support for pasting C++ code in as an upgrade path", i'm sure the purists would be up in arms, but its a valid point in the same way that the VB.NET team provide the Microsoft.VisualBasic namespace so that all the noddy/wally stuff from VB6 like Mid(str, 0, 1) still works when pasted in.
Doing little things like that helps smooth the transitions in minds of ignorant people, who do actually think that VB.NET is the next evolution of VB6 for example..
cjard,
Good post.
Alas this seriously perpetuates some really bad programming habits.Quote:
who do actually think that VB.NET is the next evolution of VB6 for example..
For those of us who habve been around awhile, and remember "C" programmers who were writing "C++" programs that had no object orientation even though they might have had classes, the transition to managed code and the .Net framework is as big (or IMHO a bigger) transition in the mind set thought processes.
When I do professional training for developers on .Net, I will typically make C++ programmers learn the techniques using VB.Net, and VB6.0 programmers learn the techniques using C#. This breaks the mindset of "well I used to do it this way..."
Once the concepts are understood, learning how to apply them in the syntax of any of the managed languages is a much smaller effort.
Given your skill at Java, I'm a little surprised that you make this comment. As a Java pro, you should know that GC is anything but predictable. One of the reasons that java and .net are not recommended for mission critical apps within constrained resources is that it's generally impossible to state how the program will consume those resources over time. In non-gc code, where the programmer must do all the allocations, in theory, a profiler can tell us (after X lines of code have been executed) exactly how much memory is being consumed (for example).. You just dont get that with garbage collecting programs that operate non-deterministicallyQuote:
Originally Posted by _uj
I'm sure I'm telling your grandma how to suck an egg here...
Do you need this level of predictability.. ?
Do you need to micromange your resources to this level?
OK.. but why do you need that absolutely instantaneous right-on-the-button destruction of objects, as soon as needs be?Quote:
Originally Posted by _uj
Do you do the pans washing up as soon as you have plated up the evening meal, or do you eat while it's hot, save the washing up for after when the pudding bowls have been added to the stack of plates too?
I cook, eat, eat pudding, wash all..
I look on "cook, wash pan, eat, wash plate, pudding, wash bowl" as a bit OCD ;)
Amen.. I just wish the manager of every IT department thought like that. Here (i'm sure it's no different to there) we have a "Well, we got 4 guys who know a bit of VBA, plus cjard who knows everything, so we'll use VB.NET because cjard might fall under a bus and we at least have a hope of understanding the code" mentality.Quote:
Originally Posted by TheCPUWizard
So far I've been called on to explain just about every feature of code that isnt present in VB6/A (threads, delegates, remoting, parameterized queries [and they WERE available back then]) and they still turn their nose up at the code and go back to writing
"SELECT * FROM table WHERE col =" & var & "..."
I never really thought about it, but I went from java -> some c++ -> vb6 -> c# (and then realised that all .NET languages are the same, so I conceded to the VB.NET demands) so i had to shed quite a few concepts along the way.. (THanks, VB6.. the rest have been "real" languages, thankfully)
I've given up trying to realise the same change in the others; at the end of the day I'm a contractor and I can do as I like.. they are managed employees, subject to the ignorance of the manager (not usually the most technical people)
I found this statement from the Visual C++ team. I just post it and comment later.
--------------------
As part of a standard business review, the Visual C++ team recently spent several months evaluating our product strategy. Central to this analysis were in-depth conversations with many of our customers and partners. These talks spanned a wide range of segments from small development shops all the way up to global ISVs. Our goal was to ensure that the direction of the product aligns closely with customer needs and market realities.
What we discovered from our customers can be summarized in three key points:
* It is clear that you mostly develop native code applications. You feel that the Visual C++ toolset has not evolved sufficiently in the past several years to meet your needs. You would like to see renewed emphasis on native code tools – especially in light of new native APIs introduced in Vista. As an aside, Microsoft itself is in a similar situation as the majority of our own applications rely on native code.
* While you are firmly rooted in native code, you do see significant value in some of the managed innovations. This is particularly true around WPF, WCF and workflow. You develop in native code, but want to extend your applications to take advantage of this managed functionality. The largest use of C++/CLI is within this interop scenario – i.e. the bridging between native and managed code.
* Finally, you have told us that you prefer to write managed code using C#. As stated above, you are using C++/CLI to bridge between native and managed code, but once you are squarely in the managed world Visual C# is the tool of choice.
After reviewing the data, our team has decided to refine the product direction. Moving forward we will increase our support for native development tools and will work to provide “friction-free” interop between native & managed code. As part of this we intend to update our frameworks to simplify the development of rich-client user interfaces and access to underlying Windows platform innovation. We’re also investigating ways to make C++ developers far more efficient in understanding, updating and validating the quality of large native code bases.
With this change we will focus less on making Visual C++ a “pure” .NET development tool. This decision is supported by the fact that Microsoft already has tools in Visual C# and Visual Basic that meet the needs of .NET developers. By not having to map to all the new aspects of.NET (such as LINQ or WPF designers), our team can concentrate on building better native and interop features. Despite these changes, please note that we will continue to provide support for C++/CLI as it is fundamental to our interop strategy.
The Orcas release will begin to reflect this new strategy but large changes – especially to the design time experience – must wait to the version beyond that. The team is currently kicking around a number of native code & interop features but we’re always interested in hearing from customers. If there are some specific things you’d like to see in future versions of Visual C++ please let us know.
The Visual C++ team
Which just confirms what has been being said by most of us all along. :D
I guess the Visual C++ team is the "bearer of the C++/CLI flame" within Microsoft so that what they say about the Visual C++ IDE also strongly reflects Microsoft's overall strategy for the C++/CLI language itself.Quote:
Originally Posted by _uj
I draw the conclussion that C++/CLI will not be positioned as a strong alternative to C#. In the future the Visual C++ IDE will focus more strongly on classic C++ than on C++/CLI. The role of the C++/CLI language will be that of a bridge between classic C++ and CLI.
To me it's a little disappointing. I would rather have had C++/CLI as a first class CLI citizen (and with Visual C++ strongly reflecting that), but with such a strong statement from the Visual C++ team it would be quite foolish to go against the stride. C# rules for managed code. :)
I'm not so sure about that. The discussion here has been largely technical and the Visual C++ team statement isn't about the technical merits of the languages. It's a political statement. It's about in which direction the Microsoft money will flow.Quote:
Originally Posted by TheCPUWizard
I still prefer C++/CLI and nobody has put forward strongly convincing arguments that C# is a better language. What I have come to realize though is that the decision isn't that dramatic because the .NET languages can be quite easily mixed.
Thanks everybody for this discussion. I know I can be a nuisance and I appologize for any inconvenience. :p
/Ulrika
I have to be very careful when discussing my thoughts on public MSFT statements, since I was previously an MSFT employee, and was party to many of the internal and confidential discussions....
That being said. Take a quick look at "why" the team may have made those statements.
1) In our discussions here, we could not come up with a compelling reason for using C++/CLI as a primary tool for developing business applications [which account for the vast majority of professional software development]
2) Many people are "comfortable" with either C# or even VB.NET. They can accomplish what they need, and do not have to faqce choices [e.g. Should I use Stack Semantics in C++/CLI]. Scott Meyers' said it best "Dont give users of your code multiple ways of accomplishing the same task. They will waste countless hours deciding which to use, when it really doesn't matter most of the time."
3) In any company, resources are limited (to at least some degree). Expending an effort on something that is not going to increase sales enough for the return on investment is simply bad business.
So [IMHO] rather than saying it is a "political statement". I would rather say it is a sound business decision based on both the underlying technical requirements of the available languages, and addressing the desires of the customer community.
In principle the answer is yes. It's a good thing that a language has some mechanism to implement the RAII idiom. C# and C++/CLI have it but Java doesn't. In Java you have to rely completely on the programmer to call a termination method (like dispose or close or whatever) before releasing an object to the GC, otherwise he has a resource leak on his hands.Quote:
Originally Posted by cjard
It can always be discussed how the RAII idiom should be provided by the language but I definately think a GC based language should have it. Here in my view Java is wanting.
Note that this question isn't related to whether a GC is deterministic or not. Determinism in this context means that the pauses the GC imposes on the application is bound in time. It's not related to whether the language supports the RAII idiom.
Quote:
Originally Posted by _uj
In summary:
"If you want to write unmanaged code, and occasionally reach into managed space, use C++/CLI"
"If you want to write managed code, and occasionally reach into unmanaged space, use C#"
Horses for courses? I dont think _uj has said, through this entire debate, which course she wants her horse to run..
As ever, but you can ally investment with technical merit, so I'd say the two are linked.Quote:
It's about in which direction the Microsoft money will flow.
As far as I was aware, this discussion was never a urinating contest in such absolute terms of "C# vs C++; which is better?"Quote:
I still prefer C++/CLI and nobody has put forward strongly convincing arguments that C# is a better language.
Several people have put forward convincing arguments why C# is better for them or better for their situation
This, of course, is contextual.. Debates as to the absolute "X is better than Y" dont get very far before they are deleted; its very tiring.
Indeed, you can even have a C# project, a COBOL.NET project and a VB.NET project added to your CLI solution, and singlestep the debugger back and forth between them seamlessly. Given that it's all bytecode, its not rocket science, but it looks that way ;)Quote:
What I have come to realize though is that the decision isn't that dramatic because the .NET languages can be quite easily mixed.
End of the day, pick whatever youre happy with, but be sure that the tool is up to the job. It's not a "do or die" world, you can learn both C++/CLI and C# if you really want; doing so enables you to choose which one is best for a particular job. In terms of tools, i really like hammers; whacking nails in is a very satisfying thing. I also see that a hammer can whack a screw in, but i'll probably use a screwdriver. Horses for courses..
I agree. And okay "political" may not have been the right word but it is a communication of Microsoft's strategy (however they reached it).Quote:
Originally Posted by TheCPUWizard
I also agree that C# like Java are "safe" languages in the sense that they minimize the programmer's opportunities to "shoot themselves in the foot". Both Java and then C# came about as a reaction to the complexity of C++.
After the success of C# and after the failure of Managed C++ it's no big surprise really that C++/CLI has found it hard to establish itself as a strong alternative to C#.
Still, regardless of the above good properties of C# (programmer safety and popularity), it may not be the qualities I'm personally looking for in a language. I like the relative complexity of C++/CLI in relation to C#. I'm not that interested in that other programmers (possibly uneducated and unexperienced) find C# easier than C++/CLI.
In short I can take some pain if it gives some gain and that requires that C++/CLI offers some tangible benefits over C#. I will have to ponder this now with the information I have.
I'm not sure Microsoft saw it as a competition either.. Look at it in purely monetary terms:Quote:
Originally Posted by _uj
Microsoft want $$$, and that means taking some small amount of $ off a lot of people (developers)
Pander to the C++ technical gurus, and also support the internally developed company products that lean heavily on C++.. Invent C++/CLI
Pander to the "uneducated" programmers out there who are clearly too stupid(or jsut dont care) to understand the Really Hard Stuff in C++ -> invent C#
I reckon that both teams, within MS, have reasonably recouped the $ they spent on R&D the language.. MS took sensible business decisions, gave us a choice, we took our personal choices and gave MS $ because they pandered to us, everyone won.
They didnt bother with minor (Ruby...), old (COBOL...) or otherwise crappy (FoxPro...) syntaxes, and the brilliance being that the community will generate those syntaxes for free (for love, not $$)
That's the great thing about choice; buy a sports car and deactivate the traction control, airbags, anti-lock brakes etc..Quote:
Still, regardless of the above good properties of C# (programmer safety and popularity), it may not be the qualities I'm personally looking for in a language.
Just a curio; howcome you never complained this loudly about Java? According to your posts, it's even more retarded than C# - did you always hate it?
So, there's an element of snobbery here? If you could do the job in either C# or C++, you'd choose C++ because it's more "elite" and your programming peers are less likely to be "uneducated/inexperienced"?Quote:
I like the relative complexity of C++/CLI in relation to C#. I'm not that interested in that other programmers (possibly uneducated and unexperienced) find C# easier than C++/CLI.
For some, that may be as good a reason as any, but if that's your take, its a bit unfair to say that C# pros in this thread havent presented any good reasons in favour of C# (IMHO, of course)