|
C# will, like all microsoft products, not work properly and it
will only be useful for windows platforms.
|
|
|
|
|
Microsoft has a long history for designing ugly, tangled , messy and confusing APIs.
First they tried with Windows SDK and designed really horrible functions which would scare any sane programmer. Thanks to folks at Borland (now Inpise) for OWL (Object Windows Libarary) which made Windows programming possible for sane people. Microsoft just borrowed the idea from Borland and bought VC++ from a small company. That's how VC++ and MFC were born.
Then tried OLE, OLE2, COM, COM+ each uglier than the one before. They made the interface so unfriendly and stupid that you have to spend more time remebering different APIs and less on your program logic. This coincided with the emergance of tiny, nacent, slow programming langauge which was much cleaner and much easier to use and people who were already fadeup with COM and other Microsoft junk adopted Java inspite of all its defeciencies and young age.
I have been programming in VC++ for more than 5 years. I am not a Microsoft hater and I am not a Java fan. But still, if I have to choose between Microsoft's COM APIs and Java for my future projects; I will chose Java. COM APIs are pure mental torture.
Microsoft has proved to be totally incapable of coming out with elegant APIs. I think C# will be no exception (unless they bought/stole it from some other company).
So, Java is here to stay. COM, COM+ (I mean only the APIs and not the underlying technology), C# and all other Microsoft junk will die.
Regards,
Arvind
|
|
|
|
|
You say, "if I have to choose between Microsoft's COM APIs and Java for my future projects; I will chose Java". This shows a completely misunderstanding of what COM is. COM is not a programming language. You can do COM in Java, you can't do Java in COM. It's funny how failure to understand something seems to cause instinctual fear and hatred. COM is really quite elegant when you understand the problem it is designed to solve. If you want to really "get" COM, I highly recommend the article "From C++ to COM" by Markus Horstmann (http://msdn.microsoft.com/library/techart/msdn_cpptocom.htm).
You say, "They made the interface so unfriendly and stupid that you have to spend more time remebering different APIs and less on your program logic". If Microsoft is guilty of anything, it's over engineering. Their APIs are often obscenely flexible, and put a lot of the burden on the programmer to manage that flexibility. The fact that libraries as different in philosophy as Delphi, OWL and MFC can all be built on top of it should give some indication of how flexible the native API is.
It's ALWAYS possible to simplify something if you take options away. Just look at Java. C++ programmers who switch to Java often find it more productive precisely because of the flexibility that is taken away from them. Does not having to worry about memory leaks, dangling pointers, etc. make your life easier? Yes. What do you lose? Flexibility. It does not make Java "better" than C++ or vise-versa. It's a tradeoff.
Cheers,
Eri
|
|
|
|
|
It seems to be MS J++ under another name - and that was a terrible technology.
The COM integration is nice, but we can expect that to arrive with the next release of VC++ anyway.
- Tom
|
|
|
|
|
I have to disagree with you on almost every point.
First, C# is much more a "child" of VB and C++, with some Java features thrown in for good measure.
Second, VJ++ 6.0 is, IMHO, the most productive of the Java IDEs on the market, with the next closest contender being JBuilder 3.5
|
|
|
|
|
I just recently started looking at Java and started out with J++ 6.0, because... every other tool I use is from MS 
But... it turns out that MS removed all the standard Java GUI building from VJ++ in version 6.0. This means that if you write an app using the IDE interface to create your GUI, it will only run on a Windows platform. The reason I started looking at Java is because I need to write an applet that runs on any Java-capable platform, isn't that the main advantage of Java, that you can do that ? Of course you can manually add your GUI controls, but that is pretty poor don't you think ?
I had my company buy JBuilder and started looking at that, at least the standard JDK GUI stuff seems to be included there.
Again, this is POV of a Java beginner, I might have overlooked something...
Edd
|
|
|
|
|
Eddy,
I think this is off topic but you are missing something with the story of J++. Originally Sun shipped Java with something called AWT as the GUI. J++ (I think) and most browser JVMs do support this. However for various reasons the AWT was found to be inadequate. Sun then went on to develop something called Swing which is now the standard for Java GUIs (but not supported by most browsers which is another story). Unfortunately Microsoft at this time went ahead and polluted J++ with Windows specific libraries and never included Swing support in it. J++ is probably a dead product but Microsoft won't come out and announce this publicly.
The above is rather condensed. If you are doing Java GUI's then I strongly advise you to get some advice on the issue of using Swing in applets as this is not as straight forward as it should be.
Shimo
|
|
|
|
|
First words from the PDC is that VJ++ has been "omitted" from VS7.
http://www.wininformant.com/display.asp?ID=2821
|
|
|
|
|
I just don't get the connection between VB and C#...
I agree that it looks like Java in some ways, but then again so would any modern programming language based on C++.
(excluding the attributes, native-xml support aso)
Anyway, the GC and the attributes will be available in Moderated C++ too.
According to MS, it is the Component Oriented Programming Language of the C/C++/C# family.
From the demos I've seen, it looks simple and clean. And it does work (considering that the .NET runtime is built in C#)!
|
|
|
|
|
Will never have the flexibility of C++. Probably will be a very good language for manipulating components, better than VB or Delphi, but will never be a language as good as C++. Of corse, if you want to know what your code is really doing! If this will ever happen then C# will be C++#  .
|
|
|
|
|
The point of C# is not to replace C++. You could say "it doesn't have the flexibility of C++" about a lot of languages, that doesn't invalidate them. Different languages have different design goals and/or evolutionary histories, and serve different purposes
|
|
|
|
|
...I believe I saw the name of Anders Hejlsberg (spelling?) in some of the documentation. Yep, that guy that did wonders with Borland Delphi, before being snapped up by MS to do Visual J++. Top geezer.
|
|
|
|
|
It's gotta be good for VB, Java and Delphi programmers, but not for C/C++ programmers
|
|
|
|
|
It's gotta be good for VB, Java and Delphi programmers, but not for C/C++ programmers
|
|
|
|
|
Although I very much like Delphi, I am really a C/C++ devotee. If I could have the Delphi IDE and the Visual C++ Debugger, and a pure C++ version of VCL instead of MFC all mixed together I would be very much happier when building GUI apps. However this isn't likely to happen, and the best C/C++ programmers can hope for in the future is that C/C++ spin offs like C# and Java will provide a wider variety of more modern tools to choose from. Visual C++ is unlikely to be developed any further, more because of fashion rather than sound technical thinking. More fashionable things like Java/C# will be focused on, and will probably be the most productive tools in the future. But I tell you one thing, Windows, Excel, Word et al will continue to be written in C++ and not C# or VB. So some token support will always be available for Visual C++. (...rant, rant, rant)
I still have a great deal of respect for Mr Anders Hejlsberg
|
|
|
|
|
For GUI's, C#, Java or Delphi is a better choice than C++. But an application is not only a GUI. I really hate to do not know anything about when my objects are deleted! Garbage collectors are an interesting technology, but this are for programmers that really have problems whith memory management . An C++ implementation of smart pointers I think that is a better choice. And you know when and where and why your object is deleted. And anyway, is faster than a JVM garbage collector!
I will not sustain C# only because is a Microsoft product and is something unknown for many people.
And templates???? No templates??? Poor C# !!!
Uncle Sam
|
|
|
|
|
I've taken a somewhat modest look at the Language and Programmers References and my general feeling is: "not bad".
It's looking a lot like C++
with:
- garbage collection
- a finally clause
- consistent byte sizes for simple types
- support for COM
- built-in critical sections
- a common base class for all types
but without:
- templates
- multiple implementation inheritance
- stack allocation of objects
- const member functions
- global variables/functions
- operator delete
But it's looking a lot more like Java
with:
- support for COM
- operator overloading
- pointers (in unsafe code)
but without:
- cross-platform support
- a dedicated class library (like AWT, Swing, etc.)
Of the C++ features not available in C#, I think the most sorely missed will be templates. I guess Microsoft (like Sun) expects that the common "object" base class will serve as an adequate substitute. I'm not so sure about that. Multiple implemention inheritance would have been nice too but I guess it would have complicated things too much for the compiler.
Overall though, I think C# will be a cool little language for Windows development
|
|
|
|
|
A few cool things you left out:
with:
* strings are a built-in type not an add-on (CString, _bstr_t)
* Language support for generating and handling events
* Delegates. Delegates do for you what a callback function pointer does for you in C/C++, except that with delegates not only can you specify a method and parameters, you can also specify the object to call. Plus it is type safe.
* a 'foreach' statement (like in VB)
* 'typeof' and 'is' statements for runtime obj ident.
* 'base' keyword for calling super class overridden method
* 'if' statements that only accept boolean expressions
- no more if (i = 3) errors
* extensible attributes
* static constructors
without:
#include statements (which is a plus in my book)
Regarding lack of templates, I think templates is a hack in C++ to get the kind of functionality that us Objective C (and SmallTalk) programmers have had a for a long time. The reason ObjC and SmallTalk have had it is because everything derives from Object. It is absolutely cake to create a collection class that can hold any type of object. In the C# scheme, I really don't think you will miss templates and all their baggage (symbol too long...)
Regarding multiple implementation inheritance, you do still have multiple interface inheritance (which is something I have wished for in ObjC for a long time now).
I do think their will be a comphrehensive class library for C# (and the other VS languages not too mention 3rd party languages like COBOL, Eiffel#, etc). I have heard there will be GUI support via the System.WinForms.*.dll library. In fact, I think a good portion of the .NET infracture is provided via a common library set that will be accessible from C++, C#, VB, etc. Of course, I will know more after next weeks PDC.
I have used Objective C for the past 7 years (not by choice, the project team I work with picked it over C++ about 15 years ago. I guess back then it wasn't clear that C++ was going to win that one). From a Objective C programmers perspective, I am real pleased with what I have seen in C# so far.
|
|
|
|
|
Hi, just a few comments.
>- no more if (i = 3) errors
try to put the const on the left side, like that:
if (3 == i)
No more if (i = 3) errors!
>without:
>#include statements (which is a plus in my book)
I have never consider a 'missing' things to be a feature. For me it is a drawback and primitive. You don't like it - don't use it. But at least you have a choice.
>* a 'foreach' statement (like in VB)
Yeah? And who needs that?
>The reason ObjC and SmallTalk have had it is because everything derives from Object. It is absolutely cake to create a <snip>
And what stops you from derive everything from "Object" in C++? It is same story like with "include". Don't tell me that lack of a feature is good for me. I want to make my own choice.
Lack of features will also prevent from porting large amount of legacy code into C#, and that is not a good message for language.
Also, if the language is "too easy" then lots of miserable skills people will do a dirty hacks with it, ending up with a mess in design and implementation. That is a common problem with the VB, and is likely to persist with C#.
|
|
|
|
|
As George said, in C++ there's nothing to stop you deriving your world from Object (some libraries do just that). It's absolute cake to create a collection class in C++ that will hold polymorphic types, just derive them from a common base class. That is not what templates are about. Parameterized types are orthogonal to inheritance. In respect of collections, what templates allow you to do is produce an efficient *typed* (statically checked) container from a common code template, rather than a container for polymorphic objects. Not the same thing at all. Of course, a glance at the Standard Library shows that there is far more to templates than typed containers...
One of the major elements of C++ missing from both Java and C# is the direct link of resource aquisition and disposal to the object lifetime by guaranteed destruction. The finally clause acts on block scopes, so it doesn't really fit the bill. I much prefer having both resource aquisition and disposal encapsulated within the class - it seems so much safer. I don't know why Java doesn't have destructors, garbage collection can still be done.
Dav
|
|
|
|
|
I agree Dave!
If templates weren't as useful as they are, I don't thing the Standard Library would have employed them as extensively. They're just awesome and for all the reasons you stated so well.
On the second point, I couldn't have said it better myself. Nothing beats allocation of objects on the stack, especially for encapsulating resource get/release scenarios! It's such a powerful and handy feature of C++ (aside from being so much faster than allocating on the heap).
Unfortunately allocation on the stack can cause problems for example when the address of the object (on the stack) is passed to a function which holds on to it. Once the object goes out of scope, the passed pointer is no longer valid and unpredictable things happen:
void foo()
{
CMyObj obj;
bar(&obj);
}
void bar(CMyObj* pObj)
{
g_someMyObjCollection.Add(pObj);
}
In Java and C# this wouldn't be a problem because the object would always be allocated on the heap and the garbage collector would know about all the places where it's being used. Still, in my opinion, only an "inexperienced" (or heavily drunk) C++ programmer would write code like the one above. So I don't agree that Java and C# should have been handicapped on that pretense.
So as much as I like having a garbage collector that can free objects whose lifetimes I don't care to track, I'd also like to be able to control the lifetimes of objects and thus take advantage of destructors. This isn't possible in C# and Java but with the aid of some third-party garbage collection libraries it can be done in C++.
Alvar
|
|
|
|
|
Wow! I knew my list wasn't complete but you really added a lot to it. Of all the things in the "with" list, I have to say that the string class is probably the nicest one. Still, I can't help but wonder how complete that string class is going to be? And will we be able to derive from it?
The boolean if statements are also nice. Like George says, doing an "if (3 == i)" is a way around the problem in C++ but that to me just looks odd and you have to remember to write it that way.
The base keyword reminds me of the super keyword in Java which is nice but restricts you to only having access to your immediate parent class's members. If you want to go higher in the hierarchy, you're out of luck. I wonder if C# will have this restriction as well.
I have to disagree with you on your statement about templates being a hack. I tell you for a hack, they sure get used a lot in STL, ATL, et. al.
Regarding your assertion that multiple implementation inheritance is there, I don't think so. From what I've read, you can derive from multiple interfaces but you can only derive from one class's implementation.
Alvaro
|
|
|
|
|
I think after installing the new MSDN I will get much help about C# when I searched for something completely different.
That's all for me, at least for the next few months
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
