|
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.
|
|
|
|
|
linkedlist are cool,.. but arrays are very good for caching. So the real question is about performance.
Peter Marino
IO Interactive
|
|
|
|
|