|
Christian Graus wrote:
I could be wrong. Best case scenario, I need to learn a whole new library in order to end up able to do what I could do in the first place.
well, i don't think that's your best case scenario.
I'd say the best case is that .net opens your eyes to new things that you hadn't thought of doing before or didn't realize you could afford to do within budget constraints.
|
|
|
|
|
If it didnt come from the same people who brought us MFC and CArray, I'd consider that might be possible. I *know* .NET does not provide standard algorithms, I can't think of anything they could add to make up for that.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
They can use java style standard algorithms. I am surprised that it isn't there yet atleast I could not find it. May be JTJ knows. Of course those algorithms rely IComparer, IComparable etc.
|
|
|
|
|
Yes, I know there are mechanisms there, but where are the algorithms ?
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
I agree with you Christian. So far diving into c# looks like a big waste of time.
swine
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
I miss:
- Generics - No; Object/object/<insert favourite="" root="" class="" here=""> doesn't qualify as a generic
- Efficiency - running time and storage
- Portability - can I with relative ease get the software to run on a system other than Microsoft Windows 98+?
FreeBSD is sexy.
Getting closer and closer to actually submit an article...
|
|
|
|
|
Christian Graus wrote:
I suspect a lot of people are ignorant enough of the std library to agree with you.
*I* would agree that the price is a steal, and I'm hardly ignorant of the std library. I can also name several folks on the C++ standards committee who are at least very interested in the .NET platform.
And you're making a terrible mistake when you assume you lose anything. Exposed interfaces have to follow the .NET rules, but the implementation is free to use everything that C++ has to offer.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote:
*I* would agree that the price is a steal, and I'm hardly ignorant of the std library. I can also name several folks on the C++ standards committee who are at least very interested in the .NET platform.
I am interested in the .NET platform, but it offends me that people talk as if it's full of new stuff. The stuff I most like in the .NET platform copies the design of the STL and iostreams. Microsoft are hardly innovators, they are good at copying ideas and marketing.
William E. Kempf wrote:
And you're making a terrible mistake when you assume you lose anything. Exposed interfaces have to follow the .NET rules, but the implementation is free to use everything that C++ has to offer.
If you read this thread, the point was you cannot use them in MC++ in a way that is portable between .NET languages.
And my main point is that most people fawning over .NET facilities have no idea of the capabilities of C++ because they would have had to learn them from a book instead of having them sold to them via Microsoft marketing. I do not deny that .NET has some cool stuff in it, but saying the price is a steal implies that C++ has nothing remotely similar going for it, which is just not true in a lot of cases. Yes, .NET has some very cool stuff if you want the handle XML, for instance, but it is not the first library to allow me to write a sort function and apply it to a container, for instance.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
Christian Graus wrote:
I am interested in the .NET platform, but it offends me that people talk as if it's full of new stuff. The stuff I most like in the .NET platform copies the design of the STL and iostreams. Microsoft are hardly innovators, they are good at copying ideas and marketing.
1) I've not seen anyone talking as if .NET is full of new stuff (though it does give us some exciting new stuff that *hasn't* been done before).
2) I don't see anything in .NET that I'd consider a copy of the STL, and iostreams are definately missing from the platform. .NET uses very .NET centric containers (and containers were not the invention of the STL), and the iterators used by .NET resemble COM/VB iterators more then C++ iterators (and I may be mistaken, but I think the VB iterators pre-date the STL, and more importantly, once again iterators were not the invention of the STL).
3) MS *is* very good at marketing, but it's not fair to claim they aren't good at invention. I can point at several things in .NET that are firsts (though they are mostly obvious extensions to existing concepts). In any event, taking something existing and using it in a new way is not something you can criticize, and the .NET platform is certainly something new.
Christian Graus wrote:
If you read this thread, the point was you cannot use them in MC++ in a way that is portable between .NET languages.
No, the thread was complaining that they couldn't be used at all. In any event, they can be used in a way that's portable, they just can't be exposed to the interface. Nor should they be, IMHO.
Christian Graus wrote:
And my main point is that most people fawning over .NET facilities have no idea of the capabilities of C++ because they would have had to learn them from a book instead of having them sold to them via Microsoft marketing. I do not deny that .NET has some cool stuff in it, but saying the price is a steal implies that C++ has nothing remotely similar going for it, which is just not true in a lot of cases. Yes, .NET has some very cool stuff if you want the handle XML, for instance, but it is not the first library to allow me to write a sort function and apply it to a container, for instance.
And this is the point I think is offensive and misses the point. Yes, there are people who are ignorant of C++ who are excited about .NET, but there are also a lot of people who are anything but ignorant of C++ who are excited about .NET as well. The .NET platform is a useful tool (not a silver bullet, just another tool for the toolbox), and one that can actually strengthen the usage of my favorite language, C++.
And no, C++ doesn't have anything remotely similar to .NET going for it. You're focusing on the wrong things here. The STL is great, yes, but .NET is offering a hell of a lot more then containers and algorithms. What it offers is language interoperability (and if that doesn't excite you then you're a little too married to C++... imagine being able to use COBOL for file access and Mondrian for complex functional computation and mix all of that into an application written in C++). What it offers is binary portability. What it offers is a much larger set of available libraries.
Then there are things that .NET gives to C++ today that the committee is considering for the next C++ standard: GC and introspection.
William E. Kempf
|
|
|
|
|
No it's notm,William E. Kempf wrote:
I don't see anything in .NET that I'd consider a copy of the STL,
The ability to write a function that does sorting for an existing container is what I am thinking of, although overall the .NET containers blow chunks.
William E. Kempf wrote:
and iostreams are definately missing from the platform.
I've seen things that reminded me of iostreams, but you're right - they ARE missing, and I love them.
William E. Kempf wrote:
and containers were not the invention of the STL
Of course not.
William E. Kempf wrote:
In any event, taking something existing and using it in a new way is not something you can criticize, and the .NET platform is certainly something new.
Not it's not, it's oneupmanship on Java. They had one language for everywhere, so we'll have ALL languages everywhere. But building on an existing idea is hardly a bad idea,I agree.
William E. Kempf wrote:
The .NET platform is a useful tool (not a silver bullet, just another tool for the toolbox), and one that can actually strengthen the usage of my favorite language, C++.
I think .NET will be a powerful tool, because of asp.net. I reserve judgement on the rest of it.
William E. Kempf wrote:
The STL is great, yes, but .NET is offering a hell of a lot more then containers and algorithms. What it offers is language interoperability (and if that doesn't excite you then you're a little too married to C++... imagine being able to use COBOL for file access and Mondrian for complex functional computation and mix all of that into an application written in C++).
Yes, I keep saying that language interop will become cool when the languages on offer are not all pale imitations of C++. In fact, I've said that on this thread.
William E. Kempf wrote:
Then there are things that .NET gives to C++ today that the committee is considering for the next C++ standard: GC and introspection.
It's my opinion that whoever decided to add things like threading and GUI components to the standard is a card carrying moron. GC I am also not so keen on, but at least I'd say it's a plausible addition, so long as I can turn it off. I am not happy with the direction to standard is taking, it needs not to chase new languages like Java, but focus instead on why C++ succeeded in the first place.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
Christian Graus wrote:
Yes, I keep saying that language interop will become cool when the languages on offer are not all pale imitations of C++. In fact, I've said that on this thread.
Let's see: COBOL.NET is hardly an immitation, pale or otherwise, of C++. Mondrian.NET, as a functional language, provides a lot of things that serious C++ developers are trying to emulate today. Eiffel.NET is certainly not a C++ imitator. I could go on, but I think I've made my point.
Christian Graus wrote:
It's my opinion that whoever decided to add things like threading and GUI components to the standard is a card carrying moron. GC I am also not so keen on, but at least I'd say it's a plausible addition, so long as I can turn it off. I am not happy with the direction to standard is taking, it needs not to chase new languages like Java, but focus instead on why C++ succeeded in the first place.
As the author of Boost.Threads I'd almost take great offense at the first sentence. However, since Bjarne Stroustrup has published papers on the need for thread support in C++ which were published long before Boost.Threads was even an idea (and I believe before Java hit the scenes as well), I'll just chalk this remark up as a stupid thing for you to say.
I also don't think you understand what's going on with the standard. The standard is hardly "chasing new languages like Java", and is certainly still "focused on why C++ succeeded in the first place". What's being considered are additions that have existed for decades, long before Java, and many of them as C/C++ libraries. Threading is not new to C/C++, and predated Java. GC is not new to C++, and predated Java (and was considered for the first standard, actually, but was dropped for lack of time). GUI components actually aren't being considered for the next standard, so you're mistaken on that one. You didn't mention introspection, but this is actually a proposal by Bjarne himself, and the design is very C++ centric with the goal of "pay only for what you use".
William E. Kempf
|
|
|
|
|
William E. Kempf wrote:
I could go on, but I think I've made my point.
Cool. I have not needed to seek anything out beyond C++ at this stage, so I did not know all of these languages existed. Now THAT is what interop is about, the stuff that M$ ships is useless in that regard.
William E. Kempf wrote:
Threading is not new to C/C++, and predated Java.
No, but I still think that the OS should provide it, not the core language.
William E. Kempf wrote:
GC is not new to C++, and predated Java (and was considered for the first standard, actually, but was dropped for lack of time).
I think it's in D&E that Stroustrup says GC was not considered for performance reasons, and that it's best added through a third party library. As I said, I'm happy for the language to provide it if I can turn it off.
William E. Kempf wrote:
GUI components actually aren't being considered for the next standard, so you're mistaken on that one.
According to CUJ they are. I'm glad to hear you say that, because that was the dumbest one of all IMO.
William E. Kempf wrote:
You didn't mention introspection,
Because I was talking about things I thought were bad ideas
William E. Kempf wrote:
and the design is very C++ centric with the goal of "pay only for what you use".
That is the bit I want most of all to remain - I'm glad to hear it is still being kept foremost.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
Christian Graus wrote:
William E. Kempf wrote:
Threading is not new to C/C++, and predated Java.
No, but I still think that the OS should provide it, not the core language.
It will still be the OS that provides the support. The reason for standardization is to provide:
a) Gaurantees for how MT effects the abstract machine. Today there are things that are platform and even compiler dependent on this count. For instance, the standard gaurantees that function local statics are initialized the first time you call the function... but with multiple threads you don't know if this will be thread safe or not. And the behavior can differ from compiler to compiler, not just from OS to OS.
b) A standard, thus portable, interface.
Both of these are very important.
I should also point out that POSIX threads are a standard, and are not OS centric.
Christian Graus wrote:
William E. Kempf wrote:
GUI components actually aren't being considered for the next standard, so you're mistaken on that one.
According to CUJ they are. I'm glad to hear you say that, because that was the dumbest one of all IMO.
I missed where the CUJ said this. I'm not on the committee, so I may not have this 100% correct. However, I do converse with several committee members on a regular basis, and my understanding is that they entertained the idea (which isn't bad), but feel that this is one case where the best you can hope for is a least common denominator solution which isn't really acceptable.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote:
The reason for standardization is to provide:
To be honest, I have a CUJ with info on this earmarked for my perusal, I may well change my mind after reading it.
William E. Kempf wrote:
and my understanding is that they entertained the idea (which isn't bad), but feel that this is one case where the best you can hope for is a least common denominator solution which isn't really acceptable.
Phew. That is exactly how I feel. OpenGL has an extention for simple GUI support, so a cross platform solution already exists for teaching, and I don't see teaching aids ( the reason given for them in CUJ ) as a good reason to put stuff in the language which is of no use to anyone.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
|
Look at the proposed generics that is going to be released in the nect .NET version. The spec rocks. The generics are at the IL level and no longer at the compiler level. That is the reason why managed classes cannot be templates in the current release because next release they are going to rock. You can still use templates as unmanaged classes gcroot is a very good example of it.
|
|
|
|
|
Christian Graus wrote:
MC++ cannot use STL ?
Not exactly what I said. Technically, MC++ can't use the STL, because the STL is unmanaged code. However, you can mix unmanaged and managed code with the MC++ compiler, so the STL can be used in the implementation. It just can't be exposed to the other .NET languages.
Christian Graus wrote:
I guess not given that it has no generics.
There are several people hard at work at bringing generics to .NET, so this *will* change, and probably soon. However, the STL still probably couldn't be exposed to the other .NET languages even then. It's design doesn't lend itself to well to the .NET world. You'd be able to use it to implement something similar for the other .NET languages, though.
Christian Graus wrote:
Yet one more reason that MC++ is utter, utter crap.
I simply can't agree. The .NET platform offers a lot of exciting possibilities, including full multi-language integration and cross-platform binaries. MC++ offers a bridge allowing C++ to enter this .NET world. More importantly, it's currently the only implementation that I'm aware of that allows you to mix managed and unmaged code, which gives MC++ a definate advantage over other .NET languages for many uses.
|
|
|
|
|
Anonymous wrote:
I simply can't agree.
Fine by me.
Anonymous wrote:
The .NET platform offers a lot of exciting possibilities, including full multi-language integration and cross-platform binaries.
That's a cool idea, and had Java worked, I would sit back and expect it to all drop into place. Even then, I think MC++ is a bad idea. If I want .NET code, I'll do it in C#, or a language totally dissimilar to C#/VB/C++/Java. THAT is when multi language will become cool, not when all the other languages are pale imitations of C++ anyhow.
Anonymous wrote:
MC++ offers a bridge allowing C++ to enter this .NET world.
That much is true, and I get that for people with legacy systems. But to puruse MC++ for totally new code is bizarre IMO.
Anonymous wrote:
More importantly, it's currently the only implementation that I'm aware of that allows you to mix managed and unmaged code, which gives MC++ a definate advantage over other .NET languages for many uses.
Actually, you can use pointers in C#, I have done exactly that in my C# image processing articles.
The advantage MC++ has is that the IL is optimised, but that won't last and hell, if I want speed, why on earth am I using IL in the first place ?
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
Christian Graus wrote:
That's a cool idea, and had Java worked, I would sit back and expect it to all drop into place. Even then, I think MC++ is a bad idea. If I want .NET code, I'll do it in C#, or a language totally dissimilar to C#/VB/C++/Java. THAT is when multi language will become cool, not when all the other languages are pale imitations of C++ anyhow.
Java failed for numerous reasons, none of which need to apply to .NET. And you seem to miss the point. You view C++ as the only solution, it appears, instead of just a tool to use to solve a problem. C++ is one of the better tools, being designed to be useful for multiple tasks. But I can still point out several things that other languages are better at. COBOL is better suited for data centric file I/O. Numerous other languages are better suited for string processing. Functional languages are better suited for many computational tasks. Fortran is better suited for mathematical computation (despite the fact that C++ can be as fast as Fortran this remains true because it's still easier to code this stuff in Fortran). So too me it's very exciting that you can do the majority of your coding in C++ and call out to other languages when they are better suited for solving a particular problem.
Christian Graus wrote:
Actually, you can use pointers in C#, I have done exactly that in my C# image processing articles.
That's not the same thing as mixing managed and unmanaged code. Pointer manipulation is only a small part of what unmanaged code brings to the table, and MC++ is the only language that currently provides this AFAIK. It's the only one supplied by MS, in any event, as VB.NET and C# do not offer fully unmanaged capabilities.
William E. Kempf
|
|
|
|
|
William E. Kempf wrote:
You view C++ as the only solution, it appears, instead of just a tool to use to solve a problem.
I guess you're not reading what I have to say then.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
Christian Graus wrote:
I guess you're not reading what I have to say then.
No, I was reading what you had to say. Your comments certainly made it appear that you were viewing C++ as the only solution. You repeatedly said things like "other languages that pale in comparison to C++". I understand now that you were saying this because you were only aware of VB.NET and C# (I still think these two languages can be considered the right choice for some tasks). This was surprising to me, however, because MS has been bragging since before the .NET beta about how many languages already existed for the .NET platform. At the time there was something like 14 different languages. Now I believe the number is probably upwards of 30 or more, though I don't know for sure.
William E. Kempf
|
|
|
|
|
I had not followed it up. I'd admit my view of things is C++ centric, but I'm always open to learn something new, if it is useful. So far I've been exposed to Python ( good, we used it for scripting our app ), C# ( useful in some circumstances, I am learning it, and I expect it to get better with time. It's probably better than CFront C++ now, and they were both first releases although C# has the benefit of experience learned from C++ so that is to be expected ) and VB ( good for nothing IMO except making programming easier at the expense of flexibility for the sake of people unable to understand C++ ).
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
If you know Python and like it maybe you should check out Python.NET from ActiveState.
William E. Kempf
|
|
|
|
|
> "Every C/C++ programmer knows that the only way to make structures
> that are 'really' dynamic is to use linked lists..."
This demonstrates a basic misunderstanding of data structures. A linked list is neither 'better' nor 'worse' than an array. For a collection that sees a large number of inserts and deletes, a linked list will give better performance. An array, however, is much faster for iteration and random access, and is thus better suited for cases where these operations constitute the majority of structure access.
In other cases, neither an array or a linked list will give good performance, and you may need a hash table, a b tree, or something else entirely. So choose the best structure for your needs and remember that, in programming as in everything else, there is almost never an "only way" to do something right.
|
|
|
|
|
Take my comment with a bit of salt. I'm exaggerating. Oh, and I consider binary trees to be a variation of linked lists. The point is that you can't have a really dynamic structure without using pointers. Pointers rule.
|
|
|
|
|