 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / August 2008how does C# compare to C++ and VB
If I'm reasonably familiar with C++ and am an expert at Visual Basic, what principles should I apply in order to understand C# so that I could more quickly learn the language? Daniel Would anyone be able to recommend a book or a web site that would help me learn C# given my background in programming? Daniel > If I'm reasonably familiar with C++ and am an expert at Visual Basic, what > principles should I apply in order to understand C# so that I could more > quickly learn the language? > > Daniel > Would anyone be able to recommend a book or a web site that would help me > learn C# given my background in programming? http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/search?g roup=microsoft.public.dotnet.languages.csharp&q=book+recommendation >> If I'm reasonably familiar with C++ and am an expert at Visual Basic, what >> principles should I apply in order to understand C# so that I could more >> quickly learn the language? > Would anyone be able to recommend a book or a web site that would help me > learn C# given my background in programming? Try Profession C# from Wrox. Arne > Would anyone be able to recommend a book or a web site that would help me > learn C# given my background in programming? There's a good book called "A Programmer's Introduction to C# 2.0." The current version is 3.5 but there has been little change. I don't know if the book has been updated. > > Would anyone be able to recommend a book or a web site that would help me > > learn C# given my background in programming? > > There's a good book called "A Programmer's Introduction to C# 2.0." The > current version is 3.5 but there has been little change. I don't know if > the book has been updated. Slight correction: the current version of C# is 3.0. Don't get confused between framework and language versions : See http://csharpindepth.com/Articles/Chapter1/Versions.aspx (And I would disagree strongly with the idea that there's been "little change" between 2.0 and 3.0. LINQ is a pretty massive change, IMO...)  SignatureJon Skeet - <skeet@pobox.com> Web site: http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon_skeet C# in Depth: http://csharpindepth.com >>> Would anyone be able to recommend a book or a web site that would help me >>> learn C# given my background in programming? [quoted text clipped - 9 lines] > (And I would disagree strongly with the idea that there's been "little > change" between 2.0 and 3.0. LINQ is a pretty massive change, IMO...) I really think they should have kept the .NET and C# version numbers in synch. It would avoid much confusion. Arne > > (And I would disagree strongly with the idea that there's been "little > > change" between 2.0 and 3.0. LINQ is a pretty massive change, IMO...) > > I really think they should have kept the .NET and C# version > numbers in synch. It would avoid much confusion. Agreed. Although as I blogged earlier tonight, publishers are doing their bit to add to the confusion too, talking about "C# 2008" :( SignatureJon Skeet - <skeet@pobox.com> Web site: http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon_skeet C# in Depth: http://csharpindepth.com The LINQ is a significant addition with v3.5, as compared to v2. Microsoft .NET development has evovled a lot in the past two years. For more about this, see: http://blogs.technet.com/mscom/archive/2008/04/16/modern-net-development -and-the-joy-of-simple-linq-to-sql.aspx > If I'm reasonably familiar with C++ and am an expert at Visual Basic, > what > principles should I apply in order to understand C# so that I could more > quickly learn the language? How did you get reasonably familiar with C++ without making a substantial investment in it? Seriously though, I think you're overthinking things. C#, C++, and VB all have substantially the same kinds of features. They are more like each other (especially C++ and C#) than they are like most other languages. Each language has some specific differences, and some people will swear one is broadly superior to another, but on the whole -- and especially in the context of .NET programming -- it really just comes down to your preferences. I strongly prefer C# over VB and C++, at least for .NET programming, and I have my reasons for that. But I don't think I've written any C# programs that couldn't have been written in either of the other languages, and 80-90% of the code would have been pretty much the same even. As for how best to learn C#, I'd say that using it is the best way to learn it. There are threads in this newsgroup with recommendations for specific books, and if that's a learning technique that's useful to you, you should check those out too. Other than that, I can't imagine what "principles" you would "apply" to "more quickly" learn C#. As they say, "just do it". :) Pete >> If I'm reasonably familiar with C++ and am an expert at Visual Basic, >> what [quoted text clipped - 8 lines] > like each other (especially C++ and C#) than they are like most other > languages. Each language has some specific differences, and some C# is far closer to Java and VB.NET than it is to C++. C++ has substantially the same OOP features as C#, but templates can do a not of things generics can't, other features are more powerful as well, and as a result C++ supports modern non-OOP programming styles (TMP for example). > people will swear one is broadly superior to another, but on the > whole -- and especially in the context of .NET programming -- it [quoted text clipped - 5 lines] > languages, and 80-90% of the code would have been pretty much the > same even. I agree with this. Writing .NET code with C++/CLI is really sluggish compared to C#, at least once you add in the Visual Studio environment and add-ins like Resharper/Refactor Pro/VAX. Making tools for C# is just much much easier than doing the same for C++. > [...] >> Seriously though, I think you're overthinking things. C#, C++, and [quoted text clipped - 3 lines] > > C# is far closer to Java and VB.NET than it is to C++. I agree whole-heartedly about being closer to Java. But the OP didn't ask about Java. :) I disagree on the VB/VB.NET point, but I guess that's a matter of opinion so not entirely unexpected. In spite of some fundamental conceptual differences between C++ and C#, I find moving back and forth between those languages much easier than moving back and forth between C# and VB.NET and so to me they are more similar to each other than C# is to VB.NET (and this is especially true if only limiting the comparison to C++/CLI rather than C++ more generally). > C++ has > substantially the same OOP features as C#, but templates can do a not of > things generics can't, And generics can do things templates can't. They are similar, but not equivalent. > other features are more powerful as well, and as a > result C++ supports modern non-OOP programming styles (TMP for example). IMHO it's inflammatory to describe one language as "more powerful" as compared to another, and in most cases (including this one) decidedly inaccurate. Of course, if by "other features are more powerful" you did not mean to imply that C# does not also have "more powerful" features, then my concern is misplaced. But that's not how I read your statement. Pete >> [...] >>> Seriously though, I think you're overthinking things. C#, C++, and [quoted text clipped - 10 lines] > I disagree on the VB/VB.NET point, but I guess that's a matter of > opinion so not entirely unexpected. In spite of some fundamental They don't "look" alike, but the actual feature matrices for VB.NET and C# are almost identical. VB has exception filters that C# doesn't. I suspect we'd be hard-pressed to list more than 6 more differences. > conceptual differences between C++ and C#, I find moving back and > forth between those languages much easier than moving back and forth [quoted text clipped - 8 lines] > And generics can do things templates can't. They are similar, but not > equivalent. Generics can do things that the Microsoft C++ compiler can't do with templates, because Microsoft C++ doesn't support the C++ standard (specifically export). Since I'm aware of only one C++ compiler that does implement export, your statement is correct for all practical purposes. However, the Microsoft C++ compiler does support generics. >> other features are more powerful as well, and as a >> result C++ supports modern non-OOP programming styles (TMP for [quoted text clipped - 3 lines] > compared to another, and in most cases (including this one) decidedly > inaccurate. Would you disagree that C++ is more powerful than C? It's practically a 100% superset. The same is true of C++ vs C#, although they're a lot closer in capability. Actually one of the big points in favor of C# is that it's controlled by a single company, so new features reach developers a lot more often, in many cases earlier. C++03 beats C# 1.x which was available at the same time. And C++0x will be a near superset of whatever version of C# is out at the same time, probably 4.x > Of course, if by "other features are more powerful" you did not mean > to imply that C# does not also have "more powerful" features, then my > concern is misplaced. But that's not how I read your statement. C# has some of these powerful features that don't have a direct equivalent in C++. There's some very nice syntactic sugar, like anonymous methods (although closures are coming soon to C++ as well). But none of them respresent a truely different paradigm, such as TMP is, so ultimately most of the reasons to choose C# over C++ (such as garbage collection, runtime code generation, etc) come from either lack of features (making the language easier to learn) or the CLR, which isn't a feature of any particular .NET language. These can be accomplished in C++ by using an appropriate library and runtime, one of which, thanks to the /clr option, is .NET itself. > Pete > > I disagree on the VB/VB.NET point, but I guess that's a matter of > > opinion so not entirely unexpected. In spite of some fundamental > > They don't "look" alike, but the actual feature matrices for VB.NET and C# > are almost identical. VB has exception filters that C# doesn't. I suspect > we'd be hard-pressed to list more than 6 more differences. I'm game to see if we can manage it between us. No cheating and looking it up though. If anyone fancies verifying my guesses, however, that's a different matter :) VB 9 has XML literals; C# doesn't. C# 3 has lambda expressions with block bodies (i.e. multiple statements); VB 9 only allows lambdas of a single expression, IIRC. VB 9 allows mutable anonymous types; they're always immutable in C#. VB allows late binding; C# doesn't (yet). C# has pointers and allows unsafe code. I'm not sure whether VB has this yet. C# has iterator blocks; I don't believe VB does. That's 6 - can anyone add to it to go to *more* than 6? SignatureJon Skeet - <skeet@pobox.com> Web site: http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon_skeet C# in Depth: http://csharpindepth.com > [...] > That's 6 - can anyone add to it to go to *more* than 6? Sure, I think there's at least a couple of obvious ones: -- VB has a concept of a "default instance". That is, if you refer to a type by name rather than an explicitly allocated instance, VB creates the instance for you. I don't know VB well enough to know if that's a language feature or something special to the Form class, but it's certainly something that happens in VB but not in C#. -- The "With" statement. -- VB's support for declaring an event handler that specifies what event it's actually handling (in C# you have to subscribe the event explicitly). Oops, sorry. That's three. I suspect an expert in both languages could come up with a great deal many more than that. That said, I don't really disagree with the overall idea that VB.NET and C# share a great number of features. That's not surprising given that they are specifically designed to target the same run-time and framework. What does surprise me is that Ben can on the one hand argue that VB.NET and C# are closer to each other than C# is to C++, and yet on the other hand argue that C++ is essentially a "superset" of C#. At best, C++ can only be thought of as a superset of C++ if one looks only at the Microsoft C++/CLI implementation of C++ (reasoning that I find a bit disingenuous), but even if one does, the implication of that assumption is that C++ is just as similar to VB.NET as C# is. But as I've said before, personally I find all three languages functionally to be basically equivalent. This entire discussion is starting to smack of "my langauge is better than yours" and I think that's a silly discussion to have. Religious arguments of that nature don't interest me much. Pete >> [...] >> That's 6 - can anyone add to it to go to *more* than 6? [quoted text clipped - 14 lines] > > Oops, sorry. That's three. These seem to me to be more syntactic than anything, unlike the ones Jon came up with, which for the most part cannot be duplicated in the other language at all. [snip] > What does surprise me is that Ben can on the one hand argue that > VB.NET and C# are closer to each other than C# is to C++, and yet on [quoted text clipped - 3 lines] > find a bit disingenuous), but even if one does, the implication of > that assumption is that C++ is just as similar to VB.NET as C# is. Let's use "natural numbers", "cardinal numbers", and "real numbers". Would you dispute that "natural numbers" are most similar to "cardinal numbers", but "real numbers" are a superset of both? Similarly, C++ is an almost 100% superset of C89, yet C89 and C99 are far closer to each other in every respect than to C++. > But as I've said before, personally I find all three languages > functionally to be basically equivalent. This entire discussion is > starting to smack of "my langauge is better than yours" and I think > that's a silly discussion to have. Religious arguments of that > nature don't interest me much. I'd suggest you read some of Stroustrup's papers to understand just how far beyond simple OOP C++ can go. Yes, if you restrict yourself to thinking of the approach you'd take with C#, then all three are basically equivalent. But C++ enables other approaches entirely that C# and VB have no way to represent. > Pete > [...] >> Oops, sorry. That's three. > > These seem to me to be more syntactic than anything, unlike the ones Jon > came up with, which for the most part cannot be duplicated in the other > language at all. On "With" I see your point (though I'm not sure why it's relevant...it's still a real difference between the languages). On the other two, I don't see those as any more "simply syntactic" than for example VB's lack of multi-statement lamba's (which are at least partially duplicated simply by putting the code in a separate method, just as anonymous methods themselves don't do anything you couldn't write explicitly if you wanted to), or iterator blocks (again, it's just "compiler magic"...you could implement the same functionality more explicitly in VB.NET if you like, just without any help from the compiler). > Let's use "natural numbers", "cardinal numbers", and "real numbers". > Would > you dispute that "natural numbers" are most similar to "cardinal > numbers", > but "real numbers" are a superset of both? Forgive me if I fail to see the point of the analogy. The "superset" and "subset" relationship mathematics between the kinds of numbers you describe is well-defined. Not so with computer languages, nor the idea of "similar". The problem here is (I believe) is a fundamental difference in the way we perceive the concepts of "similar". > [...] > I'd suggest you read some of Stroustrup's papers to understand just how [quoted text clipped - 4 lines] > But C++ enables other approaches entirely that C# and VB have no way to > represent. Why not provide an example? I'm not going to go off picking to read random writings by the designer of C++ in the hopes of figuring out what you mean. If you think there's such a clear difference, it should not be difficult to present a practical example clearly demonstrating how C++ is "more powerful" in a way that C# cannot be. Personally, the thing I find "most powerful" about C# is its integration with .NET. Yes, you can write .NET code in C++. But it's clumsy, and frankly I don't feel that features in C++ that aren't available in C# justify dealing with the clumsiness. The relative frequency with which the opposing issues come up is heavily weighted in favor of C#, at least in my own experience. Others may have different experiences and thus different conclusions. But I don't think that justifies a claim of one language being "more powerful" than others. Indeed, that sort of claim just leads to pointless, endless debates about "my language is better than yours", which as I've mentioned I find completely valueless. Pete >> [...] >>> Oops, sorry. That's three. [quoted text clipped - 10 lines] > just as anonymous methods themselves don't do anything you couldn't > write explicitly if you wanted to), or iterator blocks (again, it's Ahh, but lambda's can be traversed as a parse tree instead of turned into a delegate. The workaround of putting the code in a separate method doesn't support that. > just "compiler magic"...you could implement the same functionality > more explicitly in VB.NET if you like, just without any help from the [quoted text clipped - 9 lines] > describe is well-defined. Not so with computer languages, nor the > idea of "similar". So you snipped the (self-evident) example using computer languages. In any case, "superset" does not imply "similar". > The problem here is (I believe) is a fundamental difference in the > way we perceive the concepts of "similar". [quoted text clipped - 13 lines] > should not be difficult to present a practical example clearly > demonstrating how C++ is "more powerful" in a way that C# cannot be. Well, there are quite a few examples here: http://www.codeproject.com/KB/cpp/crc_meta.aspx But a simple one you should be very familiar with is EqualityComparer::Default Just you try to make a Dictionary in .NET that supports *any* Key class or struct without a virtual call to test equality. I suspect that the .NET JIT is coded to specifically recognize Dictionary or at least EqualityComparer::Default and perform a spot optimization, because doing the virtual call would kill performance. C++ templates easily implement the different comparison cases at compile-time with no runtime overhead, using type traits and partial specialization. Or try making a cache that uses a different data structure for small objects vs big ones, without the consumer having to select the right one. Multiple inheritance isn't all that useful -- unless you combine it with CRTP for composition of multiple behaviors. Let's say I had a word processing control, and a derived class that implements stylus entry (handwriting recognition). And another derived class that provides skinning (i.e. select a color scheme). And another one that automatically backed up the users' data periodically in case of power loss while the app is open. And another that implements text-to-speech. In C#, is there any way to get more than one of these behaviors at the same time without reimplementing the functionality? Not without modifying one of the components to inherit from a different one. In C++, if you implement CRTP composition or even template parameter inheritance support then you can build any combination without any of the variants having prior knowledge of any of the others. > > On "With" I see your point (though I'm not sure why it's > > relevant...it's still a real difference between the languages). On [quoted text clipped - 7 lines] > delegate. The workaround of putting the code in a separate method doesn't > support that. On the other hand, lambdas with multiple statements can't be turned into a parse tree by the C# compiler either: Expression<Action> f = () => { int i=0; i++; } gives: error CS0834: A lambda expression with a statement body cannot be converted to an expression tree Just a minor point, and mostly irrelevant to the discussion on C++ though. SignatureJon Skeet - <skeet@pobox.com> Web site: http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon_skeet C# in Depth: http://csharpindepth.com > Ahh, but lambda's can be traversed as a parse tree instead of turned > into a > delegate. The workaround of putting the code in a separate method > doesn't > support that. The use of lambda's as expressions is why I wrote "partially duplicated". That said, you could in fact construct the parse tree explicitly. The lambda expression is not _mandatory_. In that sense, "it's just syntax". > [...] >> Forgive me if I fail to see the point of the analogy. The "superset" [quoted text clipped - 5 lines] > any > case, "superset" does not imply "similar". I never said it does. As far as your example being "self-evident", that's in the eye of the beholder. Suffice to say, I disagree with your claim of "self-evident", and that is in fact the crux of the point here. > [...] > Just you try to make a Dictionary in .NET that supports *any* Key class [quoted text clipped - 8 lines] > using > type traits and partial specialization. You seem to be making the assumption that this difference represents "more power". I simply disagree. And again, this is because you are trying to argue a point ("a language is more powerful than another") before we have decided to agree on the definition of "more powerful". You have a priori defined "more powerful" in a way that supports your claim, so of course your claims seem self-evident to you. But they fail to convince someone who doesn't agree on the definition. The other issue is that I've never said that C++ doesn't have features that C# has. That's not the point. I readily admit the languages are different. The question is whether C++ has ALL the features C# has. As far as I know, it doesn't. Certainly the C++ I'm familiar with doesn't. All that said, your religious view of C++ as _the_ superior language is intractable, and it's this sort of religious view that I find pointless to try to debate. Tautological arguments are the norm, openness to compromise is absent, and I detest such discussions. So I won't bother you further on the point. Pete >>> Forgive me if I fail to see the point of the analogy. The >>> "superset" and "subset" relationship mathematics between the kinds [quoted text clipped - 9 lines] > your claim of "self-evident", and that is in fact the crux of the > point here. Before we forget, here was the example: "C++ is an almost 100% superset of C89, yet C89 and C99 are far closer to each other in every respect than to C++." Do you want to contest that? >> [...] >> Just you try to make a Dictionary in .NET that supports *any* Key [quoted text clipped - 27 lines] > openness to compromise is absent, and I detest such discussions. So > I won't bother you further on the point. I didn't say "superior". Simplicity and barriers to making mistakes are advantageous in their own right. I said "almost superset" and "more powerful" and I stand behind that claim. > Pete > Before we forget, here was the example: > > "C++ is an almost 100% superset of C89, yet C89 and C99 are far closer to > each other in every respect than to C++." > > Do you want to contest that? I'm not sure what you mean. I do contest that it's an example relevant to what C# is similar to. But if all you meant by "self-evident" that the example is, as a self-contained statement having no implication anywhere else in this thread, "self-evident", no...I wouldn't have any reason to contest that. > [...] > I didn't say "superior". Simplicity and barriers to making mistakes are > advantageous in their own right. I said "almost superset" and "more > powerful" and I stand behind that claim. Well, I find "superior" and "more powerful" practically synonymous. But more problematic is that you haven't defined "powerful" in a way that allows for any factual statement to be used using the term. And in particular, you seem to be using the term differently than I would. As a tautological assertion, perhaps your claim has basis. But then, any tautological assertion would. :) Pete > But a simple one you should be very familiar with is > EqualityComparer::Default > > Just you try to make a Dictionary in .NET that supports *any* Key class or > struct without a virtual call to test equality. If you mean doing so while keeping the existing interface of Dictionary, then it's possible, though tricky - once you get the comparer, you create dynamic methods for all the search operations that directly invoke the most derived implementation of IComparer<T>.Compare on the actual comparer instance. In effect, you still have dynamic dispatch, but it's moved outside the loop where it kills performance. In fact, I wouldn't be surprised if JIT was able to lift virtual method resolution outside the loop on its own, without any dirty Emit tricks. On the other hand, if you mean writing my own class with interface different from that of Dictionary, that's quite doable, too, and will actually look very similar to std::map: class Map<TKey, TValue, TComparer> where TComparer : IComparer, new() { readonly TComparer comparer = new TComparer(); // calls to Compare() on this won't be virtual, and will likely be inlined } This is particularly efficient if you then pass an empty struct, rather than class, as TComparer. >> But a simple one you should be very familiar with is >> EqualityComparer::Default [quoted text clipped - 9 lines] > still have dynamic dispatch, but it's moved outside the loop where it > kills performance. Congratulations, you can do it by *re-implementing the C++ rules for templates*. Pretty cool that .NET gives you the dynamic codegen to let you do it, but still waaaay more difficult than using C++ to do it. > In fact, I wouldn't be surprised if JIT was able to lift virtual > method resolution outside the loop on its own, without any dirty Emit [quoted text clipped - 13 lines] > This is particularly efficient if you then pass an empty struct, > rather than class, as TComparer. They will be virtual unless TComparer is a struct. Which, unfortunately, EqualityComparer<T> isn't, and EqualityComparer<T>.Default isn't. But honestly, you've done a great job of working within the confines of .NET and making the JIT work for you. > (although closures are coming soon to C++ as well). But none of them > respresent a truely different paradigm, such as TMP is, so ultimately most What does TMP stand for? Daniel >> (although closures are coming soon to C++ as well). But none of them >> respresent a truely different paradigm, such as TMP is, so >> ultimately most > > What does TMP stand for? Template Meta-Programming > Daniel >> C# is far closer to Java and VB.NET than it is to C++. > [quoted text clipped - 8 lines] > is to VB.NET (and this is especially true if only limiting the > comparison to C++/CLI rather than C++ more generally). C#<->VB.NET converters are much better than C#<->C++ converters. Which I see as a reasonable indication of how close the languages are. Arne > C#<->VB.NET converters are much better than C#<->C++ converters. "much better" == subjective, unquantified opinion. > Which I see as a reasonable indication of how close the languages > are. You may. But it could be more an indication of how the languages are used than anything else. In any case, I'm not insisting that anyone else take the same view. My own personal experience is irrefutable as it pertains to my own perceptions, and that is that I find it easier for _me_ to translate between C++ and C# than to translate between either of those and VB.NET. YMMV, and I don't care. It doesn't have anything to do with _my_ impressions, which was all I was sharing. Pete >> C#<->VB.NET converters are much better than C#<->C++ converters. > > "much better" == subjective, unquantified opinion. Should be obvious to anyone with experience in the languages. But let us find the last complete program you posted in this group > 100 lines. I will find a converter that convert it to VB.NET - you will find a converter that converts it to C++ (not C++/CLI), we post the two here and then people can compare. OK ? > In any case, I'm not insisting that anyone else take the same view. My > own personal experience is irrefutable as it pertains to my own [quoted text clipped - 3 lines] > YMMV, and I don't care. It doesn't have anything to do with _my_ > impressions, which was all I was sharing. Who on earth would convert manually between C# and VB.NET at all ? Translations are very good. Usually you convert and it either just works or you have to make a few trivial changes. Arne >>> C#<->VB.NET converters are much better than C#<->C++ converters. >> "much better" == subjective, unquantified opinion. > > Should be obvious to anyone with experience in the languages. Ah, yes...like Ben's "self-evident" comment. Suffice to say, I don't find that sort of expression a valid debating style. "Should be obvious", "self-evident", etc. are just crutches for people who don't feel like proving their point. > But let us find the last complete program you posted in this > group > 100 lines. I will find a converter that convert it to > VB.NET - you will find a converter that converts it to C++ > (not C++/CLI), we post the two here and then people can compare. > > OK ? What would make you think that a single data point in any way represents a valid study? > Who on earth would convert manually between C# and VB.NET at all ? I find myself doing it somewhat regularly, when dealing with different code examples different people post. The context isn't about getting a program to work; it's about understanding what someone else has written. In spite of the fact that the most common scenario is seeing VB.NET code, I still find it easier to deal with C++ code. I'm not sure what it is about "my own personal experience" that you are having trouble comprehending, but that's the bottom line here. None of your comments regarding machine translation are relevant at all with respect to my observations about the different languages. Pete >>>> C#<->VB.NET converters are much better than C#<->C++ converters. >>> "much better" == subjective, unquantified opinion. [quoted text clipped - 5 lines] > obvious", "self-evident", etc. are just crutches for people who don't > feel like proving their point. Well - I actually offered a demonstration below. Which makes your comment above look rather stupid. >> But let us find the last complete program you posted in this >> group > 100 lines. I will find a converter that convert it to [quoted text clipped - 5 lines] > What would make you think that a single data point in any way represents > a valid study? Last 10 so ? >> Who on earth would convert manually between C# and VB.NET at all ? > > I find myself doing it somewhat regularly, when dealing with different > code examples different people post. The context isn't about getting a > program to work; it's about understanding what someone else has written. It is quite common to want to do something manually to learn from it, but it is rather irrelevant in a discussion of whether it is easy to do automatically. Arne > Well - I actually offered a demonstration below. Which makes your > comment above look rather stupid. I don't doubt that you believe that. > [...] > It is quite common to want to do something manually to learn from it, > but it is rather irrelevant in a discussion of whether it is easy to > do automatically. The only person having that discussion is you. I am participating in a different discussion that is about my own perceptions regarding the specific similarities between the languages. You are free to carry on your own conversation with yourself if you like. But don't expect me to agree that it's relevant. Pete >> It is quite common to want to do something manually to learn from it, >> but it is rather irrelevant in a discussion of whether it is easy to >> do automatically. > > The only person having that discussion is you. Actually it was you that wrote: #What would make you think that a single data point in any way #represents a valid study? in response to me talking about automatic conversions. So yes - you were actually also participating in that discussion. Arne > If I'm reasonably familiar with C++ and am an expert at Visual Basic, what > principles should I apply in order to understand C# so that I could more > quickly learn the language? You are pretty well covered with C++ and VB. You need to study garbage collection and interfaces. LINQ if you want the latest. Arne What is LINQ? Daniel >> If I'm reasonably familiar with C++ and am an expert at Visual Basic, >> what principles should I apply in order to understand C# so that I could [quoted text clipped - 6 lines] > > Arne >>> If I'm reasonably familiar with C++ and am an expert at Visual Basic, >>> what principles should I apply in order to understand C# so that I could [quoted text clipped - 4 lines] >> you want the latest. > What is LINQ? http://en.wikipedia.org/wiki/LINQ Arne > If I'm reasonably familiar with C++ and am an expert at Visual Basic, what > principles should I apply in order to understand C# so that I could more > quickly learn the language? It thinks like VB but looks like C++. That is, it is practically the same language as VB but with a C-like syntax. It is not much like C++. That's what I needed to know. Thanks. Daniel >> If I'm reasonably familiar with C++ and am an expert at Visual Basic, >> what principles should I apply in order to understand C# so that I could >> more quickly learn the language? > > It thinks like VB but looks like C++. That is, it is practically the same > language as VB but with a C-like syntax. It is not much like C++. > If I'm reasonably familiar with C++ and am an expert at Visual Basic, what > principles should I apply in order to understand C# so that I could more > quickly learn the language? Do you mean you're an expert at "old" VB (version 6 or earlier) or the .NET version (now no longer called VB.NET, unfortunately)? If you already know the .NET framework you'll get to grips with C# a lot more easily than if all your experience is with "classic" VB. SignatureJon Skeet - <skeet@pobox.com> Web site: http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon_skeet C# in Depth: http://csharpindepth.com > If I'm reasonably familiar with C++ and am an expert at Visual Basic, what > principles should I apply in order to understand C# so that I could more > quickly learn the language? > > Daniel Progamming principles :) Joke apart, the languages are only a mean to express concepts. If you are familiar with the OOP concepts you will have no problem in C# Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.