Just to make sure. Are they necessary in C++/CLI if you use the CLI part only? The reason I'm asking is that in my C++/CLI textbook there are hardly no include files at all.Quote:
Originally Posted by TheCPUWizard
Printable View
Just to make sure. Are they necessary in C++/CLI if you use the CLI part only? The reason I'm asking is that in my C++/CLI textbook there are hardly no include files at all.Quote:
Originally Posted by TheCPUWizard
The majority of "textbook" programs are simple single module programs. This is radically different from a "real" program that may contain hundreds of .cpp (and corrosponding ".h") files.Quote:
The reason I'm asking is that in my C++/CLI textbook there are hardly no include files at all.
The project I am working on right now [in C#] contains over 2500 different classes. Many of these classes are implemented as partial classes, since portions of them are autogenerated by designers. The total number of files is just under the 8,000 mark.
You will not find this type of complexity in a textbook. :D
As a professional developer with over 30 years experience, using over 50 different computer languages [15 years C++, 6 years C#, 2 years Managed C++, 3 years C++/CLI], I think I might fall into that category... ;)Quote:
The virtues of any language only show after extensive use in real situations by language experts.
It was you who introduced "headers" as a special difficulty of C++/CLI in relation to C#. I don't need to be lectured about the use of header files or design issues concerning classic C++. I'm interested in pure managed C++/CLI only at this point.Quote:
Originally Posted by TheCPUWizard
As I mentioned the C++/CLI textbook I'm using show hardly no includes at all so I was under the impression that they weren't strictly necessary if one sticks to CLI.
My textbook isn't really a step-by-step introduction (It's C++/CLI by Hogenson). Still I can see no indication that a C++/CLI class file must be divided into a .h and a .cpp part.Quote:
Originally Posted by TheCPUWizard
I agree with you that controling and using header files is a true nuisance in classic C++ but I'm not convinced it's a problem in C++/CLI if you stick to the pure managed part.
In Java one is forced to import the classes one is using but this is largely a non-problem because of the import management good IDEs offer. In principle they tell you what you need to import.
If you cannot be bothered to be polite then I will not bother to continue trying to be helpful in this thread.Quote:
Originally Posted by _uj
Bye.
I appreciate your help but I still feel free to argue if I don't agree with you. What did you expect? That I lick your feet in thankfulness just because you replied? I also adopted your rather condescending tone. If you didn't like it why should I? Now be a good sport and come back to the thread. :)Quote:
Originally Posted by Zaccheus
Well I've browsed a little further in my textbook and it's pretty clear that the above isn't true.Quote:
Originally Posted by TheCPUWizard
The #include directive is part of classic C++ and you don't need to use it in pure managed C++/CLI. Instead you use the #using directive which should let you import managed assemblies very much the same way as in C#.
Again to me it seems very much that the notion of C# being much easier than pure managed C++/CLI is a myth. Okay if you resort to the classic C++ part of C++/CLI and you find C++ difficult than of course C++/CLI will be difficult too but this is an option you don't have to utilize (unless the need arises and then its quite handy actually).
So to me C++/CLI seems to fullfil two quite disparate objectives. Firstly to be a language capable of swallowing classic legacy C++ code, and secondly to be a good managed language at par with C#. In the latter capacity it has none of the drawbacks of classic C++, like say this "header" issue we've been discussing.
Argue away, by all means.Quote:
Originally Posted by _uj
But comments like ...
... are simply not helpful.Quote:
Originally Posted by _uj
I wasn't being condescending. Your post #44 was the first indication in this thread that you had not written any C# or C++/CLI at all - which surprised me, because if I'm considering using a language then I tend to give it a try, especially if I want to know something specific (like the #include issue). Of course it makes sense to ask people, who know the languages, for their opinions (that's why I'm responding to this thread) but that does not stop you from giving them a try. But that was not meant to be a put down, just a friendly suggestion.Quote:
Originally Posted by _uj
Well, as you ask so nicely.Quote:
Originally Posted by _uj
:D
For what it's worth, I have found C++/CLI to be unnecessarily complicated. I've been writing commercial ANSI C++ code for almost 8 years, so I've got no problem understanding or appreciating traditional C++.
What you call bickering is based on experimenting with C++/CLI for over a year and comparing it to the C# code I've written at work.
You are absolutely right in saying that C++/CLI is very similar to C# (they both fully utilise the benefits of .net), but the syntax for C# is simplified down to a very intuitive level.
For example, in C++/CLI you need to either use the dot notation or the arrow notation to access class members, depending on what kind of object you are dealing with. In C# it is always the dot notation.
The issue with the #includes only relates to classes which you have defined in the current project (i.e. which do not already exist as meta-data in another DLL).
One nice thing about C++/CLI is the full support for C++ templates (even in pure managed mode) as these are far more powerful and flexible than the .net generics, but these template classes always need to be #included because .net stores no meta-data for the uninstantiated templates.
Apart from the simplified syntax, C# also has a bunch of syntactical abstractions which make writing code easier. For example, have a look at the C# yield keyword in C# v2 and the new lambda expressions in the upcoming C# v3.
My understanding is that C++/CLI is really just meant to be a way of incorporating legacy C++ code in .net assemblies.
Zacchaus,
I agree with your last post, except:
It is primarily that, but it also fills two other roles:Quote:
My understanding is that C++/CLI is really just meant to be a way of incorporating legacy C++ code in .net assemblies.
1) The fairly rare condition where savinging microseconds counts. This should (of course) only be considered after measuring that there is a performance bottleneck that has a significant impact at the application level, and there are no improvements to the algorithms/design that can achieve the performance
2) EXTENSIVE interfacing with existing or "built-in" (e.g. Kernel) native code. The overhead of marshalling across the boundaries can become significant.
Alas, both of these techniques imply that "unsafe" native code will be used heavily, which brings back all of the classic C++ issues. So none of the three conditions (yours + my 2) apply if you are going to force the use of only safe managed code.
Yes, I agree.
I would also add that C++/CLI has the ability to access native C++ classes exported from 3rd party DLLs ('mangled' C++ identifiers), something you cannot do in C#.
Like you say, it's all to do with accessing native code efficiently, i.e. writing 'glue' code.
The bulk of most applications can be written more easily in C#.
Quote:
Originally Posted by _uj
Mmmhhhh.. It strikes me then, if you stick within C++/CLI then youre using (imho) an awkward and somewhat backward syntax/methodology to write a modern program, avoiding everything about what brought that syntax into being, purely for the sake of using the modern extensions..
I reckon that's a bit like falling out with a friend after he loaned you his lawn mower, but continuing to mow your lawn with his mower because you prefer it to yours..
In programming terms, using pure C++/CLI isnt really going to be any different to C#, just a bit more legwork and some "older fashioned" thinking, on the simplistic level
When I chose C#, C++/CLI didnt exist and I just didnt like MC++ as much; it looked a mess and the ambiguities bave me a headache. C# was much closer to java, and I rather liked java. I can write code without having to track and remember everything on a very micro scale.. This might arise from the rather typical male way of being forgetful and careless, I dont know!Quote:
So I was interested in why people chose C# over C++/CLI. Both are .NET languages and should be equally easy (or hard maybe) to master and use.
When you say both are .NET though, I still dont quite agree with that. C# is all .NET with this unmanaged ability if you really work at linking it up. Compared to that C++/CLI's unmanaged code accessibility is quite a lot more present and uncovered.. I dont feel I'm explaining this particularly well, but suppose you were in front of a class of students, teaching them pure C++/CLI, and one asked "What's the difference between String*and String^?" - your answer would have to be "String* is the one we dont use, String^ is the one we do use" without launching into a huge and long explanation, and like the big red button that says "dont push this button", someone will want to push it.
I guess you could say I use C# because it does everything that I need, cleanly and simply, consistently and easily.. Additionally, when I go looking for examples of things, I happen upon C# more often than all other .NET syntaxes put together. As no fan of reinventing perfectly good wheels, I like having that vastness of pre-existing material as a resource
No, but then I do feel that it was more a rip of J# 6.0, as the salvation of all the work that MS put into their proprietary form of java, that Sun sued them over..Quote:
Originally Posted by _uj
Nothing ever is completely new, but I wouldnt say C# has any C or C++ as a heritage.. I actually think that all the .NET languages have java as an ancestor due to they way they work under the hood. Developing a new syntax is probably trivial once the VM-esque way of working is in place..
It borrows a couple of keywords.. You couldnt really say that C++ has quite strong english influences, it just uses English words that embody the concept of what they achieve within the language..Quote:
It has quite strong C++ influences it seems to me.
The difference is that in C++/CLI the C++ heritage is a part of the language. You got classic C++ and in addition the CLI extension.
Last I knew, one of the biggest quibbles over C++/CLI vs C++ was that neither was a subset of the other.. But maybe I'm just out of date?Quote:
if you didn't know that classic C++ actually is a true subset of C++/CLI it would be almost impossible to guess.
Is there an inherent inconsistency there, though? In a language where there are two ways of doing most things, each affecting/influencing the style of the other, but just different enough to make the explanation difficult, I'd rather teacha language that was single-track, consistent and simpler..Quote:
You don't have to tell people how you would accomplish in classic C++ what now is much easier thanks to the CLI extension of C++/CLI.
Then you shouldnt struggle with either. Assuming you favour C++ and Java equally, with no intuition that makes you think "I like the way X feels, more than Y", then from a productivity point of view, you'll likely be more productive in C# than CLI (i'm going to drop calling it C++/CLI because we already are talking about avoiding the C++ part) because there is less messing around with the finer points. Of course, these may well be the finer points you seek, but the fact that you use and are happy with Java kinda makes me think you dont really miss the things that C++ does that Java doesnt..Quote:
Originally Posted by _uj
People typically use .NET because they want to develop a Windows app. If you dont want to develop a windows app (ignoring Mono), dont' use any .NET flavour.Quote:
I also know the benefits/drawbacks of .NET in relation to portability
It's not really a spitting contest between C# and CLI though, is it?Quote:
What I got so far in favour of C# is not that convincing.
Yep, that's viable; there will be a general ignorance towards CLI because it is newer than C#, has less of a following, is harder/more confusing/more leet haxor(probably an unfair stigmatisation from C++ associations) but saying that it's ahead of C# needs a little more qualification; what does the word "ahead" mean to you?Quote:
Most people in favour of C# don't even seem to realize that C++/CLI is very far from classic C++. In fact C++/CLI seems quite ahead of C#.
Glad you're back. I'll give you an extra hug to compensate for the hardship you suffered :)Quote:
Originally Posted by Zaccheus
Okay so the major advantage of C# is a more polished syntax and more avant-garde language constructs.Quote:
For what it's worth, I have found C++/CLI to be unnecessarily complicated. I've been writing commercial ANSI C++ code for almost 8 years, so I've got no problem understanding or appreciating traditional C++.
What you call bickering is based on experimenting with C++/CLI for over a year and comparing it to the C# code I've written at work.
You are absolutely right in saying that C++/CLI is very similar to C# (they both fully utilise the benefits of .net), but the syntax for C# is simplified down to a very intuitive level.
For example, in C++/CLI you need to either use the dot notation or the arrow notation to access class members, depending on what kind of object you are dealing with. In C# it is always the dot notation.
The issue with the #includes only relates to classes which you have defined in the current project (i.e. which do not already exist as meta-data in another DLL).
One nice thing about C++/CLI is the full support for C++ templates (even in pure managed mode) as these are far more powerful and flexible than the .net generics, but these template classes always need to be #included because .net stores no meta-data for the uninstantiated templates.
Apart from the simplified syntax, C# also has a bunch of syntactical abstractions which make writing code easier. For example, have a look at the C# yield keyword in C# v2 and the new lambda expressions in the upcoming C# v3.
Well I buy that. C++/CLI must stay out of the way of classic C++ in order not to interfere with its current nor with its anticipated future syntax. C# on the other hand was designed from the ground up with no such restrictions.
Featurewise C++/CLI is tied to the evolution of C++ whereas C# is free to add on new sexy features, like the lambda expressions you mentioned.
In summary I think it's only natural that C++/CLI has a slightly more complex syntax and is likely to be more conservative in adding new language features. Because it's in the C++ tradition to avoid language changes these are likely to be quite few and instead find their way into the language as additions to the C++ standard library. There's a new C++ standard coming up "around 2009" and I guess this will also be the next time C++/CLI changes.
The main objective of C++/CLI is to,Quote:
My understanding is that C++/CLI is really just meant to be a way of incorporating legacy C++ code in .net assemblies.
"Enable C++ to be a first-class language for CLI programming" (Herb Sutter).
This is a far more ambitious goal than to be a mere upgrading path for old rusty C++ applications. With this objective C++/CLI takes on C# as the preferred language for the development of new applications. That's my interpretation.
To be honest I don't quite see where this speed advantage of C++/CLI over C# should come from?Quote:
Originally Posted by TheCPUWizard
C++/CLI is a managed language just like C# so both will suffer the same context switches when compiled with non-managed native code. Does C++/CLI offer an advantage in this area?
Or is it that C++/CLI can be more efficiently compiled to Intermediate Language code so it will be faster than C# for reason of more aggressive optimizations?
Or is it that the C++/CLI programmer can avoid using or better control the managed Garbage Collector for reference objects thus escaping some overhead which C# cannot?
I wonder how can C++/CLI be faster than C#?
I think it's more likeQuote:
Enable C++ to be a first-class language for CLI programming" (Herb Sutter).
-- Get those C++ guys who are very hard to shift to use .NET because we've come up with a .NET flavour of their favourite language --
Or
-- Get people to use .NET even though they have 2.5 million lines of C++ in their application --
Similarly for VB.NET.
Personally I wouldn't touch C++/CLI with a very long pole unless I had to. And I've had to.
I wrote an entire application in it to get around certain political issues and believe me it was hard work compared to C#.
I believe its faster (I can't believe my much though) than C# because it can do things like inlining, whole program optimisations and other C++ niceties. Because each class doesn't proliferate throughout each assembly and the compiler knows which classes reference it (because of the #include-s) then I can believe this.Quote:
To be honest I don't quite see where this speed advantage of C++/CLI over C# should come from?
How much difference it makes is debatable though. I've never seen any specific stats on it or tried anything out myself.
As to the fact you can compile native code into managed code I don't think you should be doing this anyway. My C++/CLI code always has the managed and native parts seperate anyway (as it should in my opinion) so why not just have a native dll which interfaces to C# via p/invoke ?
There is one thing I don't like about .NET and that's the rather fuzzy boundary between dlls. It doesn't lend itself nicely to re-use (without a great deal of self control and concious decision about what you're writing/changing).
Mind you I don't like equally the linked static dlls you get in C++ for this very reason either (e.g. rather than having a .def file and explicit exports you use the __declspec stuff and even export classes from the dll). I far prefer COM in this case because of its well defined interfaces and well defined boundary between client and server (or dll and exe/dll if you prefer).
I can't personally see how C++/CLI is a "first class language" for .NET. Why anyone would write a form in C++/CLI is beyond me. The autogenerated code is horrendous !
I suppose it has its place, but it doesn't do anything you can't do in C# and C# is much, much, MUCH easier to deal with so I'll stick with C# for .NET development.
Darwen.
Generally I'm over in the Visual C++/Multithreading forums, but since I primarily code in C# at work, I figured I'd chime in with a question.
Because I haven't ever programmed in MC++ or C++/CLI, I'm wondering what these have to offer over coding in C# and PInvoking to a C++ dll (or COM object) when doing it in C# doesn't cut it?
I claimed C++/CLI was "ahead" of C# to provoke a reaction. :) But I got the idea from my textbook (Gordon Hogenson) who writes,Quote:
Originally Posted by cjard
"The designers of C++/CLI had the advantage of looking at what works and what doesn't in the C# language, and planning the design of C++/CLI accordingly"
He's more or less forced to boost C++/CLI of course and to be honest I haven't found that many advantages of C++/CLI over C# really.
But one is that C++/CLI provides better and more predictable object cleanup. Another is that C++/CLI offers more interoperability options wheras C# has P/Invoke only. I haven't been convinced though that C++/CLI is capable of faster context-switching than C#. In fact I haven't find any evidence that C++/CLI should be faster than C# in any respect. Then comes the question you raise, that of language polularity. There's no doubt that C# has the lead and probably will have for the foreseeable future.
So all in all, the
- polished syntax,
- sexy language features,
- sufficient interoperability with native code via P/Invoke,
- popularity
seem to make C# the better choise. But I haven't written C++/CLI off yet especially not if evidence of possible substantial performance gains over C# will surface. Are there any?
Could you please be more specific. I cannot quite get how it can be so much harder to write a program in C++/CLI (in safe mode) rather than writing the same program in C#?Quote:
Originally Posted by darwen
Was it because of the unfamiliar C++/CLI syntax? Was if for the lack of essential language features available in C#? Or what was it?
Stanley B. Lippman is an Architect with the Visual C++ team at Microsoft:Quote:
Originally Posted by _uj
Quote:
C++/CLI represents an integration of the Kansas and Oz of native and managed programming. In this iteration, that has been done through a kind of separate but equal community of source-level and binary elements, including Mixed mode (source-level mix of native and CTS types, plus a binary mix of native and CIL object files), Pure mode (source-level mix of native and CTS types, all compiled to CIL object files), Native classes (can hold CTS types through a special wrapper class only), and CTS classes (can hold native types only as pointers).
Of course, the C++/CLI programmer can also choose to program in the CLI types alone, and in this way provide verifiable code that can be hosted, for example, as a SQL stored procedure in SQL Server™ 2005.
http://msdn.microsoft.com/msdnmag/is...5/02/PureC/#S7
I wouldn't say traditional C++ has been conservative in adding new language features. There have been a few changes and many many additions since it was first introduced in the mid-1980s.Quote:
Originally Posted by _uj
As far as I know, code written in the first version of C# will still compile just fine on the latest compilers.
Regarding the question of C++/CLI vs Managed C++, I think it is fair to call it a syntax change - in fact the Visual C++ 2005 compiler option for compiling code as Managed C++ is /clr:oldSyntax.
[quote]
But one is that C++/CLI provides better and more predictable object cleanup.
[quote]
Wrong, False, Utterly UNTRUE!
There are three phases to object cleanup:
1) Dispose() [optional]
2) Finalize() [automatic if implemented and not suppressed
3) Freeing Memory.
Items #2, and #3 are done by the Garbage collector, which is totally unaware of the thanguage the object is implemented in.
Item #1 Occurs only if the Dispose() method [which is implemented in C++/CLI using destructor semantics].
There are three ways that ispose typically gets invoked:
a) Explicit call to Dispose()
b) Exiting a "using" block in C#
c) Using stack semantics in C++/CLI
"b" & "c" both have identical performance, and are equally predicitable. "a" is actually a little more un-predicitable, since people often forget to structure things so that Dispose() always gets called in the event of exceptions.
The key word here is "substantial", and the general answer is a resounding NO.Quote:
But I haven't written C++/CLI off yet especially not if evidence of possible substantial performance gains over C# will surface. Are there any?
Typical cases where there will be a measurabe performance difference is if you allow mixed mode [not pure CLI]. Consider a loop which has to call two unmanaged functions in some other existing peice of code. The loop will execute a million times.
If the loop is written in managed code (any language), then there will be 2,000,000 marshlling calls.
With a mixed mode C++/CLI implementation, you can code the loop as a peice of unmanaged code, and marshall just once and execute the entire loop in the unmanaged space.
Again: This point goes away if you are going to restrict your C++/CLI code to being pure..
My textbook (Hogenson) on C++/CLI contains suspiciously little about multithreading. I cannot say if this means there's less support than in C#. It may be that threading is mainly handled by CLI libraries (say System.Threading or so) which means it should be equally supported by both languages. Well at least there seems so be some support,Quote:
Originally Posted by Arjay
http://www.ddj.com/dept/cpp/184402018
Multi-Threading (using managed threads which are not necessarily the same as system threads) is equally supported in all languages as you surmised.Quote:
I cannot say if this means there's less support than in C#. It may be that threading is mainly handled by CLI libraries (say System.Threading or so) which means it should be equally supported by both languages. It seems at least there's a lock keyword in C++/CLI.
C# also has the lock() statement.
There are DLLs which export native C++ classes, as far as I know these can only be accessed from .net via mixed-mode 'glue' DLLs implemented in C++/CLI.Quote:
Originally Posted by darwen
Also it may be easier / more efficient to access some COM objects via C++/CLI.
But those are relatively rare special cases. In general I agree that managed code should not be mixed with non-managed code in the same DLL.
In your lecture you correctly point out the difference between the languages,Quote:
Originally Posted by TheCPUWizard
b) Exiting a "using" block in C#
c) Using stack semantics in C++/CLI
Now I find the C++/CLI way both "better and more predictable". It's because it happens automatically and doesn't rely on the programmer to always remember to supply a using block. If you don't share my view please feel free to explain why you prefer the C# way.
1) It happens automatically if the user "remembers" to use stack semantics and not reference semantics.Quote:
It's because it happens automatically and doesn't rely on the programmer to always remember to supply a using block. If you don't share my view please feel free to explain why you prefer the C# way.
1a) FxCop can be configured to report any IDisposable object which is created outside a using block.
As to "prefer the C# way". I never said that. I merely said that I do not prefer the C++/CLI way, as there are no real advantages in this regard. In other words, the issues of managed object memory management, is (roughly) equivilant. The c# method has some advantages, in that you can do additional processing between different objects being disposed without any additional work.
The much bigger issue with memory management, it that most of the paradigms that apply to native code, are actually bad programming practice in a managed (Garbage Collected) environment. This topic is completely independant of the language being used.
Well you're entitled to an opinion and I won't yell "Wrong, False, Utterly UNTRUE!" at you for having it.Quote:
Originally Posted by TheCPUWizard
What we're discussing IS part of the bigger issue. How can resources securely and predictably be disposed off of in a GC environment. I think the RAII idiom is a good solution and I think I prefer the C++/CLI implementation.Quote:
The much bigger issue with memory management, it that most of the paradigms that apply to native code, are actually bad programming practice in a managed (Garbage Collected) environment. This topic is completely independant of the language being used.
Threading support in 1.0 and 1.1 was limited but it's pretty good in 2.0. 2.0 supports thread pooling (ala QueueUserWorkItem) and also a ReaderWriterLock class.
If you like to perform thread synchronization using RAII, you can do this in C# by leveraging the using statement.
So say I wanted to add thread safety to a property of a class
The cool thing about this is that the syntax for locking a mutex or ReaderWriterLock is similiar. Here's an example of locking a RWlock to read.Code:public string Location
{
get
{
using( AutoLock< LockableCS >
Lock = AutoLock< LockableCS >.Create( _csLock ) )
{
return _location;
}
}
}
Sure you can do this with the lock{ } block, but lock doesn't allow the granularity of this technique and doesn't provide mutexes and reader writer locking support.Code:public string Location
{
get
{
using( AutoLock< LockableRW >
Lock = AutoLock< LockableRW >.Create( _rwLock, LockType.Read, 5000 ) )
{
return _location;
}
}
}
Actually I was a Microsoft Employee at the time these decisions were made. Many were tradeoffs to keep thinks in a "C++ Paradigm" even if it was not optimal from other points of view. RAII with reference objects contains some inherent inner conflicts. An object needs to be able to support being Disposed of multiple times, and All methods on the object should fail once the object is destroyed once.Quote:
I'm sure the designers of C++/CLI also have given this some serious thought and they discarded the C# way. Why don't you go yell "Wrong, False, Utterly UNTRUE!" at Herb Sutter instead of me, or maybe you already did that?
If you use stack semantics on a managed object, and start passing and holding on to the references, you run into many of the same problems that you had in conventional C++ with holding references to objects which have gone out of scope. C++ programmers are used to this, so it was not deemed a proble. C# and most other Managed Languages, handle this a little more gracefully.
Actually there have been some heated discussions between us over the years.Quote:
Why don't you go yell "Wrong, False, Utterly UNTRUE!" at Herb Sutter instead of me, or maybe you already did that?
The methodology for handling the Dispose() of objects between the various languages can be debated on merits. This is an opinion.
The "predicitability" is a matter of fact. Objects get disposed if and only if the Dispose method (expressed as a destructor in C++/CLI) gets called. Objects get finalized, and their memory released as a function of the garbage collector and is independant of the language used. As far as I can see, there is NO difference in predictability.
I don't think it is possible to do that kind of 'using statement' with C++/CLI stack semantics, because you need to receive a reference to an object which was created in the called function (as discussed here).Quote:
Originally Posted by Arjay
My example was C#. Is the using statement, IDisposable not supported in C++/CLI? If so, that's a great reason right there to choose C#.Quote:
Originally Posted by Zaccheus
Have a look at the link in my post. You can create an instance of a class which is automatically disposed, but I cannot see a way of automatically disposing a reference received from a function call in C++/CLI.Quote:
Originally Posted by Arjay
However, it did just dawn on me that it might be possible to write a generic class which supports stack semantics, whose only purpose is to receive such a reference and dispose the received reference when it gets disposed itself ! A bit like a managed auto_ptr.
Sure and there's no special reason for you to call my opinion "Wrong, False, Utterly UNTRUE!". It's still my opinion and I suggest you stick to arguments even if you feel your opinion is superior.Quote:
Originally Posted by TheCPUWizard
In one case the language relies on the programmer to initiate destruction and in the other case this is taken care of automatically by the language. In my view in the latter case the language offers a higher degree of predictability. A reference object on the method stack will be destructed when the method is left. No programmer intervention necessaryQuote:
The "predicitability" is a matter of fact. Objects get disposed if and only if the Dispose method (expressed as a destructor in C++/CLI) gets called. Objects get finalized, and their memory released as a function of the garbage collector and is independant of the language used. As far as I can see, there is NO difference in predictability.
Okay predictability may be the wrong expression but now you know what I mean. In any case I wouldn't use this as a determining factor in the choise of language.
By automatically disposed, are you referring to the delete statement in the finally block?Quote:
Originally Posted by Zaccheus
100% agreement, not a determining factor.Quote:
In one case the language relies on the programmer to initiate destruction and in the other case this is taken care of automatically by the language. In my view in the latter case the language offers a higher degree of predictability.
Okay predictability may be the wrong expression but now you know what I mean. In any case I wouldn't use this as a determining factor in the choise of language.
Perhaps you really did not mean predictability, because in C#
1) If there is no call to Dispose, and the object is not in a using block. It will bot be deterministically Disposed.
2) If there is a using block it will be disposed.
3) If there is no using block, and there is an explicit call, it will be disposed itf the code executes. It must be inside a finally block to insure it is called in the event of an exception.
Therefore looking at any peice of C# code that has an object that implements IDisposable, I can "predict" if the object will be disposed with 100% certainity that my prediction is corredt. Not code like this:
I would definately consider to be less predictable. :DCode:IDisposable obj;
int x = Random.Next();
if (x%1)
obj.Dispose();
I think perhaps it's simply a case of what you are used to. In one case (C++/CLI) you have to create an auto-disposed object by leaving out the ^ symbol and the 'new' statement, in the other (C#) you have to put using() around a variable declaration which is otherwise unchanged. I don't think either is more logical than the other.Quote:
Originally Posted by _uj
Not having coded in C++/CLI I can't say for sure, but understanding the implications of leaving off the ^ and not using the 'new' sounds more trouble than in C#. In C# there is no ^ and everything must be 'new'd, so this part is removed from consideration. As far as the using statement, you can use the using block or call Dispose directly. If you try to call using on something that doesn't implement IDispose, the compiler tells you immediately. It just seems simpler in C#.Quote:
Originally Posted by Zaccheus
There are other considerations like :
(1) In C# intellisense works, in C++ it is very flaky.
(2) C# is much, much quicker to write code in.
By (2) I mean you don't have to type as much e.g.
In C# the seperator is '.' (dot) whereas in C++ it's ':' (colon) - I'm a speed typer and even to me a dot is easier to type than a colon as a colon requires the shift key.
In C# you can use 'as' to do casting whereas in C++/CLI it's safe_cast<>.
No need for #includes in C# (great !).
There are all sorts of other points like these which in my opinion make C# so much more of a nice language to code .NET in than C++.
Darwen.
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