>You have to learn the language *and* the implementation in order to really understand C or C++.
Yes, you're right! It was so long ago I started to internalize this that I had forgotten, and in fact, this would explain my weakness for C/C++, which is that it satisfied the urge to think of code in terms of the instructions the CPU understands aka, assembly/machine language. C++ does extend the tradition of C, which is having some idea of what a pariticular construct compiles to in machine language (at least roughly).
Re:Java has it's place, but it has problems
on
The Future of Java?
·
· Score: 1
>This can be said of any language, but much was made about Java being a language to make people make less mistakes - they just make different ones.
yes, and the bugs just get more surreal. Or worse, their solutions lie inside an impenitrable VM.
and I can't help but tease you about this typo... spoken like a true C/C++ lover (comrade!)
>Java has not delivered is because it's not made programming any easier or error prone
Yes... any good language should make programming more error prone, because if it doesn't kill you, it shall make you stronger....
>What I can say conclusively is that a programmer of equal skill in C++ and Java can write the same program in less lines of Java code.
While I agree 100% with the overall message of your post (that context is relevant to which language is superior), I disagree with the specific sentiment above. If you have a class system you are using, then the C++ can be fewer lines. Comparing the Java libraries with the C++ stdlib isn't really a fair comparison, because there are a multitude of free and commercial APIs and classes that also "do a lot for free".
>I would consider a language like SML or O'Caml or Haskell to be "radically modern" in the sense that, unlike Java, they don't feel that they need to present the user with familiar paridigms (OO) and syntax and buzzwords just to gain industry acceptance.
Very interesting take. I like that too, but I'm not familiar with SML or O'Caml, though O'Caml was recently recommended to me and it does sound like something I should check out.
As for the kinds of limits I'm talking about with "pure" languages, I'm really thinking in a general sense that there has to be some compromise. I see C++ as a very practical language, but which tries to give the higher level constructs, like constructors and destructors, to allow a "better way", without losing any abilities. But the results are as you see, C++ does not appeal to those that want a clean logic throughout their language, without compromise to being compatible with a legacy language like C, allowing direct memory manipulation, and the like. I tend to think the practical languages will always look messy to purists.
So put another way, C++ is trying to be the "better language" but "errs" by keeping legacy stuff that may even now be officially obsolete! How do you turn C++ into a purists language (just imagine it might be possible;)... by removing those old features and the abilities that went with them. Good riddence, maybe...
As for particulars, I was thinking about Java, and I don't like the loss of memory management control... I believe I should be able to call delete and have a destructor called. Right now, in Java, you don't know if the destructor will EVER be called. Remove goto... ok, fine, goto is evil. However, for a long time goto was the best way in C and C++ for the best error handling idiom. Exceptions are better, but for a long time poorly supported in C++. I was glad to have a language that would not cut off any old avenue while new avenues were being developed. But in any other case, I think the limitations would be different. C and C++'s limitation: you have to learn what you are doing, which is in general good advice!
It's funny your comment about the loss of control vs. gaining control... like all things it's perspective. I've created SDKs and classes for other people to use, and perhaps that's what you do because that is when you see C++ as limiting you ability... it limits your ability to limit. E.g. You CAN protect your class with the private and protected keywords, but I can take the.h file you have to provide, I can create a class that matches yours but has "public" where you have "private", I can do an illegal cast, and I can probably abuse your object quite well. I'd be insane to do it... but insanity is not exactly in short supply among programmers. To me it's, "if you point the gun at your foot an fire, don't blame the safety lock design!" But don't get me wrong, I'm not differing with you, it's a matter of perspective and it is best to provide classes that really are bullet proof, I understand the desire to be able to do that. Then... I guess the point for me is it's seems a bit futile to expect to TOTALLY protect something from misuse, there are so many other kinds of misuse besides the kinds of memory games that Java, at least, tries to globally address. That is... memory related issues is not the top bug I find myself worrying over in my carreer, so I'm not willing to give up much in the way of performance, etc., for a magic solution.
Re: memory ownership. To manage memory wisely with C++ (or C), you do have to have an idea of ownership. In C it's a bit unworkable, b/c some functions will own their memory, some won't, and the library calls will work however they like, breaking any consistency you impose. In C++ it's much easier... objects own memory, they own objects declared as members, and it's easy to impose this on your class system, essentially answering the question globally.
Finally, you (and some others) have convinced me I should look at OCml and SML (and Ruby, for that matter), which I imagine I will get to within the year. Nice talking to you.
Then he was lucky it worked well enough. I don't say you were lucky, you probably had to work and had to worry like hell. He was taking a risk that it would not work, and often, that gamble doesn't pay off.
I probably should not have shot from the hip... I don't know the project, I surmise that some Y2K flaw was understood and had to be addressed. So the bugs were bound to be less disruptive than no solution at all.
No doubt my comment was 3/4 projection... I have seen many times decisions made because someone has to tell someone something happened. If the product is called X, and is installed on Y, then some guy feels fine saying, "hey, we have X installed on Y, we have a few things to work out".
Well, I work with Java professionally, so if that's radically modern, then ok. There is nothing Java forced me to do that I couldn't do in C++.
Is C++ modern enough for your context because here is the deal: it's efficient (oh, we used to have the C programmers thinking it was bloated, but now we have a world of VMs to compare with), it's flexible, there is nothing it cannot do.
I like Java, but it's not "general purpose" in the sense that C++ is. In fact, all the "pure" languages ever tried (like Pascal) limit you in some way that C/C++ refuses to. This is a power of C++. The difficulties involved are possibly things you simply have to learn. Mathematicians have to learn mathematics. A simpler mathematics that loses some scope is not superior, even if it's interesting or important to a subfield of mathematics, overall, the broader mathematics is "superior" and a better tool.
Memory issues... they will not be solved in a general purpose compiled language by the language itself b/c that removes the ability to create certain memory management schemes. However, they are well solved in classes, including classes from the standard library such as auto_ptr. Solving them there and using a compiled and flexible language means you get the benefit of code that can do it's best to keep things clean "for" the programmer, but you don't lose in performance, you don't lose access to designs that would otherwise be available.
I like the fact that many idioms are available in C++ and that it embraces that. Let the craftsman chose his idiom.
I like Java and other languages, but there is no getting around that C/C++ is the most powerful tool at the moment. "But there are gotchas and it's hard to learn" doesn't change that... especially for those of us that have learned it.
Know what I think? Memory management in C is not rocket science and in C++ it doesn't have to be an issue if you chose a sensible paradigm for handling memory. They are easy! AND flexible. No harder than closing parenthesis, and sanity checking is rather easily automated, in C with various tools, in C++ by the classes responsible for the memory. Rule. Free what you Malloc, Set your pointers to null when you free. All done.
I use Java and I don't find myself not thinking about memory management. But I do lose "delete" and the ability to have special heaps, etc. etc., that is, I'm no longer "allowed" to memory manage in Java.
The advantages of Java are special, not general. WORA without recompilation makes Java great for servlets and for distributed computing where you want to fling code around a network. The API is large, but C++ has a huge array of free and commericial libraries, so again, the "problem" with C++ is a lot of choice and decisions to make. Making those decisions and being informed about the state of the available libraries is just a part of the job.
I think one memory issue that C++ has is the idea of ownership. If you pass memory to a function or class, you have to be clear on who "owns" it, meaning, who has to or can delete it. In Java, well, it doesn't matter, anyone with a reference owns it.
But see, this is flexibility. You can decide who own it, and if you want it to "own" itself, and use a reference counting scheme where it frees itself when it's final reference is decremented... well I've done that many times too!
I understand why people want to compare languages on syntax and readability, etc. the internal view of the code... but isn't that really secondary... shouldn't they be judged based on their abilities? What is the resulting running process like? Professional tools are tools that allow a professional to produce the optimal result, and if the professional has to learn the tool to accomplish that... is that not simply the way of the craftsman?
Lesser craftsmen will use lesser tools, lesser cooks will use storebought mixes, amateur handymen will use good-enough tools that yeild lesser but good-enough results, but the best will use the tool promising the best results. C++ provides some structure to make C safer, and essentially is just as capable as C, so it's an improvement. But if you remove ability, the total value of the safety introduced is called into question.
Finally, I suspect all "obvious" choices, as they are based on assumptions. I don't think it's really "more secure" in an "obvious" sense. I don't prefer the 70's, but then I segued into a C++ advocacy and maybe that isn't even what you meant... maybe that counts as a modern language, certainly C++ provides solutions or avenues to address all the 70's-era problems with C.
>Unfortunately, C encourages such bad program design, and then makes bugs deadly.
I don't think so. I think languages that claim to do it all for you and protect you from logic errors (I guess you start from a truth and only divide, truth truth truth all around) are the ones that encourage bad program design. C encourages very careful program design after one, maybe two feet are gone. But C++ is better, in general and with respect to your desire to allow automatic memory management techniques (plural).
Re:Dude, I think we grew up in the same mall.
on
Phantom Game Console
·
· Score: 1
every mall had an Orange Julius and Alladin's Castle and a Radio Shack... e.g. The mall in Boulder Colorado.
which is interesting because this is the point of TCL... TCL has a very good attitude about itself in that it's not presented as the end all be all language, one language for all. TCL justifies script languages as a means to tie together all the components that are carefully created in optimal, compiled, languages.
This is appealing as a philosophy because it's the reality that most seem to wish away... many languages always crying for various types of integration. But it's still a scripting language, and in a way any scripting language can borrow that philosophy.
don't forget:... "you're a naughty one aren't you? He's tryin' to let me cream go bad! But I'm in 'is territory, an' he reckon's I'm out to eat his food."
No, it's not Asteroids or Missile Command... my mind reading device indicates it's "Space Invaders" that he's thinking of.
No wait -- pachinko!
Re:Computers Teaching UI to Humans = Bad
on
Palm Kills Off Graffiti
·
· Score: 2, Insightful
wrong! Tools should be efficient, if that involves some training for the user... fine. Why should you be able to do something you've never done before in a way familiar to you... it's an unfamiliar task, then it's an unfamiliar tool, you will have to learn how to use it.
Should a screwdriver have to use a hammer's interface because the hammer interface is intuitive because it's ALREADY learned? Should the hammer not have a handle and instead use the interface of the pounding rocks that preceded it?
How do you improve tools if you can't optimize the UI for the task and instead have to optimize it to avoid learning. If the learning is costly, at least the cost stops when the learning is accomplished and the result is an efficient tool. If the tool is not optimized for it's purpose, then you continue to pay for that loss of optimization forever, and eventually it will be more costly than having the user learn the task and method at hand.
Of course you should use known metaphors, and use real world tools and metaphors, but in the end we want the best tool, we are tool building. Tools are not automatically bad because they require knowledge or expertise to apply. In fact, the best tools, the most powerful tools, always do involve learning the tool itself. The interface needs to seem convienient once you have learned it, not before so.
I think you are mistaking a marketing imperitive and marketing principle for an engineering principle.
As for Newton's handwriting recognition... it's so unbelievable I think I might have been trolled! Not the Newton's I used...
to be willingly part of a plan that intends to burn you out in eight years is a bad idea.
The idea that you could work hard and retire in that time is nonsensical, a promise Microsoft can not keep, that it could in the past is the past, like spending lottery money because you'll just win another one, not a good forward plan.
this money is like all the money you "make" saving buying items on sale... if you go to enough sales you can save $100,000 a year and live quite comfortable... but where do you come up with the $1,000,000 it takes to generate that sweet income?
No it's really true, and you are right, it could affect you with static linking, but generally is less likely to.
The issue is this... the binary picture of the object in memory. Strictly speaking the compiler needs to know the parent and descended type to make this upcast (potentially, even without MI). If you do this cast without knowing what the descended type really is, you are taking a pointer and just lying to the compiler what the memory print looks like. This generally works (better know your compiler, but that's true in general, since different compilers generally arrange objects differently in memory) since the object does look like it's parent in memory with single inheritance. The data at the top of the object is the same, you can pretend it's the parent and using virtual functions, the overridden functions will be called. But if the descended class were MI, then the footprint is changed, before the data fields there is likely a new pointer to the second parent's data, or it's virtual functions, or the data is possibly inserted prior to the parent you are upcasting to, etc., but whatever the layout, it's changed, and to make the cast safely the compiler needs to know the child type because it's going to have to find the part of the object that is of the same type as the parent and give you a pointer to that.
This may be making someone shudder as I speak, because I have not mentioned many other ways you should be careful if you play these kinds of games. In general, the way to do this thing carefully is to use pure virtual objects as interfaces, and ask for those (i.e. how COM works). You have some thunking though the interface to your real classes, but everything stays clean and safe, you just have to build or use a thin interface-managing layer (again, such as COM). Real, btw, uses "lightweight" COM even on it's server side... as someone pointed out, COM interfaces are just pure virtual classes... essentially tables of function pointers, so you can use it without the OS registration related stuff that COM also entails (especially now).
The reason this isn't a problem, usually, with static libraries is merely that the compiler usually knows the descended type, and inserts code to do the conversion. With statically linked libraries often the project is arranged such that the compiler does know the return type is, say, class D, and is doing an actual conversion (not just a static_cast).
There are other solutions... the library could convert the pointer the proper way before returning it, which is one way to build COM objects using MI, converting the pointer in the library to what the main code expects or was promised.
So the real issue isn't my specific example, but the havoc that is played at the binary level. A clear strucure-like layout, that maps quite directly to the source code description starts to become mixed up with MI as the compiler juggles the data and function pointers. MI is one of those things that introduces the compiler level voodoo that puts off so many C programmers (e.g. the kind that can't stand even the fact that the 'this' pointer is pushed on the stack and slipped into your function -behind your back!!!-:) I'm not that zealous, but 8 years ago we were worried about performance complications and MI seemed a good thing to avoid.
Mind you, so were templates (not supported) and exceptions (still badly implimented then), both of which I heartily rejoice in now that compilers support them well and efficiently. It's probably time for me to come back to MI, because I use the "mix-in" design idea anyway, which without MI involves some degree of thunking.
One more thing about the extensibility system I created this way. There were a lot of special rules for objects created this way... how you created them, how you added data members... too many specific rules for me to argue that this kind of thing isn't a mine field. I think in a multiparadigmed language it's inevitable that you will have to understand not only C++ but the C++ philosophy of a particular project, before you really understand the project. That's the justification of having extra rules. Still, I would now probably do this much differently.
Playing games at the level of the binary layout of your strucutures is one of the things that makes people now say that C++ is too low level. But the way I see it the only problem is maybe that I should not have thought about it at that level, i.e. it's not C++ fault that it gave me free reign. Considering the task at hand at the time I think it was reasonable in context.
thanks... that's food for thought... your comment that OCaml is statically typed and yet that's generic is interesting... don't quite follow, but I'm not asking for explanation, I'll just take a look at OCaml I guess!
The decision of pointer or value in containers is also a good example... you have to think through your problem, each time, to figure which is best and acceptable for the problem at hand.
I guess a follow up question of mine is: is there any such problem that cannot be solved with a class or library! That is... is there anything C++ is too low level for that cannot be solved with some system written on C++ that you then use (e.g. we used to write containers a lot, and generally I wrote content specific containers in that case, and now, I can do the same thing design wise but use generic efficient algorithms via the STL portion of stdlib. C++ "became" higher level.)
Do you think C++ highest possible level is bound? I tend to think that we can achieve higher and higher levels of programming, without cutting off any avenue of development, without introducing major performance hits (other than those that are what you "paid" for/wanted). Because C++ is multiparadigmed they don't even have to be OO systems, again, like the stl.
Comparing C++ to Java or PERL or TCL or.... ek, VB, I'm in danger of becoming a C++ bigot. I'm unimpressed with those "improvements". Java I like well enough, but to me it's "VB done right", which is not entirely a compliment. I better look at some of the other language candidates brewing to keep the open minded perspective I prefer... Ruby is another language that's been recommended to me.
What had driven me to avoid MI, and I must say that design wise I struggle to get the effects of MI through other means, was simple.
The first C++ project (and most after) have involved designing extensibility by using a base class in an executable, and derived classes created in dynamically linked libraries. The point being the executable loads the library, links to a constructor function, calls it and is returned and object B which can be upcast to the base class A.
This cannot be done if B is multiply inherited because the executable module does not know about that at compile time.
This came up a lot when I made client software for Windows where we often wanted to do something like this. COM and other solutions were possible, but this was the simplest, requiring no special layer to manage interfaces instances or thunk to the real member functions.
Slashdot Mirror
Step 6: ????
Step 7: Pork!!!!
oh, about 5 to 10...
oops. I thought you asked, How long for...
>You have to learn the language *and* the implementation in order to really understand C or C++.
Yes, you're right! It was so long ago I started to internalize this that I had forgotten, and in fact, this would explain my weakness for C/C++, which is that it satisfied the urge to think of code in terms of the instructions the CPU understands aka, assembly/machine language. C++ does extend the tradition of C, which is having some idea of what a pariticular construct compiles to in machine language (at least roughly).
>This can be said of any language, but much was made about Java being a language to make people make less mistakes - they just make different ones.
yes, and the bugs just get more surreal. Or worse, their solutions lie inside an impenitrable VM.
and I can't help but tease you about this typo... spoken like a true C/C++ lover (comrade!)
>Java has not delivered is because it's not made programming any easier or error prone
Yes... any good language should make programming more error prone, because if it doesn't kill you, it shall make you stronger....
>What I can say conclusively is that a programmer of equal skill in C++ and Java can write the same program in less lines of Java code.
While I agree 100% with the overall message of your post (that context is relevant to which language is superior), I disagree with the specific sentiment above. If you have a class system you are using, then the C++ can be fewer lines. Comparing the Java libraries with the C++ stdlib isn't really a fair comparison, because there are a multitude of free and commercial APIs and classes that also "do a lot for free".
>I would consider a language like SML or O'Caml or Haskell to be "radically modern" in the sense that, unlike Java, they don't feel that they need to present the user with familiar paridigms (OO) and syntax and buzzwords just to gain industry acceptance.
;)... by removing those old features and the abilities that went with them. Good riddence, maybe...
.h file you have to provide, I can create a class that matches yours but has "public" where you have "private", I can do an illegal cast, and I can probably abuse your object quite well. I'd be insane to do it... but insanity is not exactly in short supply among programmers. To me it's, "if you point the gun at your foot an fire, don't blame the safety lock design!" But don't get me wrong, I'm not differing with you, it's a matter of perspective and it is best to provide classes that really are bullet proof, I understand the desire to be able to do that. Then... I guess the point for me is it's seems a bit futile to expect to TOTALLY protect something from misuse, there are so many other kinds of misuse besides the kinds of memory games that Java, at least, tries to globally address. That is... memory related issues is not the top bug I find myself worrying over in my carreer, so I'm not willing to give up much in the way of performance, etc., for a magic solution.
Very interesting take. I like that too, but I'm not familiar with SML or O'Caml, though O'Caml was recently recommended to me and it does sound like something I should check out.
As for the kinds of limits I'm talking about with "pure" languages, I'm really thinking in a general sense that there has to be some compromise. I see C++ as a very practical language, but which tries to give the higher level constructs, like constructors and destructors, to allow a "better way", without losing any abilities. But the results are as you see, C++ does not appeal to those that want a clean logic throughout their language, without compromise to being compatible with a legacy language like C, allowing direct memory manipulation, and the like. I tend to think the practical languages will always look messy to purists.
So put another way, C++ is trying to be the "better language" but "errs" by keeping legacy stuff that may even now be officially obsolete! How do you turn C++ into a purists language (just imagine it might be possible
As for particulars, I was thinking about Java, and I don't like the loss of memory management control... I believe I should be able to call delete and have a destructor called. Right now, in Java, you don't know if the destructor will EVER be called. Remove goto... ok, fine, goto is evil. However, for a long time goto was the best way in C and C++ for the best error handling idiom. Exceptions are better, but for a long time poorly supported in C++. I was glad to have a language that would not cut off any old avenue while new avenues were being developed. But in any other case, I think the limitations would be different. C and C++'s limitation: you have to learn what you are doing, which is in general good advice!
It's funny your comment about the loss of control vs. gaining control... like all things it's perspective. I've created SDKs and classes for other people to use, and perhaps that's what you do because that is when you see C++ as limiting you ability... it limits your ability to limit. E.g. You CAN protect your class with the private and protected keywords, but I can take the
Re: memory ownership. To manage memory wisely with C++ (or C), you do have to have an idea of ownership. In C it's a bit unworkable, b/c some functions will own their memory, some won't, and the library calls will work however they like, breaking any consistency you impose. In C++ it's much easier... objects own memory, they own objects declared as members, and it's easy to impose this on your class system, essentially answering the question globally.
Finally, you (and some others) have convinced me I should look at OCml and SML (and Ruby, for that matter), which I imagine I will get to within the year. Nice talking to you.
ok, I believe you.
Then he was lucky it worked well enough. I don't say you were lucky, you probably had to work and had to worry like hell. He was taking a risk that it would not work, and often, that gamble doesn't pay off.
I probably should not have shot from the hip... I don't know the project, I surmise that some Y2K flaw was understood and had to be addressed. So the bugs were bound to be less disruptive than no solution at all.
No doubt my comment was 3/4 projection... I have seen many times decisions made because someone has to tell someone something happened. If the product is called X, and is installed on Y, then some guy feels fine saying, "hey, we have X installed on Y, we have a few things to work out".
>He absolutely needed the app in place by midnight on Dec 31 1999, so he was willing to accept a potentially buggy product.
let me reword this for you... he absolutely needed to be able to TELL SOMEONE THAT HE HAD the app in place by midnight on Dec 31 1999.
He needed it to be the real app, then he would have needed to know that it was working too.
>Have you read Also Sprach Zarathustra?
I did! And what I learned was this: if you wake up and find a snake is biting your tongue, bite it's head off.
Gsus! I'm still just thankful the fonts have lower case in them now!
I'm old. In 40 years... I might be dead! But maybe not.
Well, I work with Java professionally, so if that's radically modern, then ok. There is nothing Java forced me to do that I couldn't do in C++.
Is C++ modern enough for your context because here is the deal: it's efficient (oh, we used to have the C programmers thinking it was bloated, but now we have a world of VMs to compare with), it's flexible, there is nothing it cannot do.
I like Java, but it's not "general purpose" in the sense that C++ is. In fact, all the "pure" languages ever tried (like Pascal) limit you in some way that C/C++ refuses to. This is a power of C++. The difficulties involved are possibly things you simply have to learn. Mathematicians have to learn mathematics. A simpler mathematics that loses some scope is not superior, even if it's interesting or important to a subfield of mathematics, overall, the broader mathematics is "superior" and a better tool.
Memory issues... they will not be solved in a general purpose compiled language by the language itself b/c that removes the ability to create certain memory management schemes. However, they are well solved in classes, including classes from the standard library such as auto_ptr. Solving them there and using a compiled and flexible language means you get the benefit of code that can do it's best to keep things clean "for" the programmer, but you don't lose in performance, you don't lose access to designs that would otherwise be available.
I like the fact that many idioms are available in C++ and that it embraces that. Let the craftsman chose his idiom.
I like Java and other languages, but there is no getting around that C/C++ is the most powerful tool at the moment. "But there are gotchas and it's hard to learn" doesn't change that... especially for those of us that have learned it.
Know what I think? Memory management in C is not rocket science and in C++ it doesn't have to be an issue if you chose a sensible paradigm for handling memory. They are easy! AND flexible. No harder than closing parenthesis, and sanity checking is rather easily automated, in C with various tools, in C++ by the classes responsible for the memory. Rule. Free what you Malloc, Set your pointers to null when you free. All done.
I use Java and I don't find myself not thinking about memory management. But I do lose "delete" and the ability to have special heaps, etc. etc., that is, I'm no longer "allowed" to memory manage in Java.
The advantages of Java are special, not general. WORA without recompilation makes Java great for servlets and for distributed computing where you want to fling code around a network. The API is large, but C++ has a huge array of free and commericial libraries, so again, the "problem" with C++ is a lot of choice and decisions to make. Making those decisions and being informed about the state of the available libraries is just a part of the job.
I think one memory issue that C++ has is the idea of ownership. If you pass memory to a function or class, you have to be clear on who "owns" it, meaning, who has to or can delete it. In Java, well, it doesn't matter, anyone with a reference owns it.
But see, this is flexibility. You can decide who own it, and if you want it to "own" itself, and use a reference counting scheme where it frees itself when it's final reference is decremented... well I've done that many times too!
I understand why people want to compare languages on syntax and readability, etc. the internal view of the code... but isn't that really secondary... shouldn't they be judged based on their abilities? What is the resulting running process like? Professional tools are tools that allow a professional to produce the optimal result, and if the professional has to learn the tool to accomplish that... is that not simply the way of the craftsman?
Lesser craftsmen will use lesser tools, lesser cooks will use storebought mixes, amateur handymen will use good-enough tools that yeild lesser but good-enough results, but the best will use the tool promising the best results. C++ provides some structure to make C safer, and essentially is just as capable as C, so it's an improvement. But if you remove ability, the total value of the safety introduced is called into question.
Finally, I suspect all "obvious" choices, as they are based on assumptions. I don't think it's really "more secure" in an "obvious" sense. I don't prefer the 70's, but then I segued into a C++ advocacy and maybe that isn't even what you meant... maybe that counts as a modern language, certainly C++ provides solutions or avenues to address all the 70's-era problems with C.
>Unfortunately, C encourages such bad program design, and then makes bugs deadly.
I don't think so. I think languages that claim to do it all for you and protect you from logic errors (I guess you start from a truth and only divide, truth truth truth all around) are the ones that encourage bad program design. C encourages very careful program design after one, maybe two feet are gone. But C++ is better, in general and with respect to your desire to allow automatic memory management techniques (plural).
every mall had an Orange Julius and Alladin's Castle and a Radio Shack... e.g. The mall in Boulder Colorado.
which is interesting because this is the point of TCL... TCL has a very good attitude about itself in that it's not presented as the end all be all language, one language for all. TCL justifies script languages as a means to tie together all the components that are carefully created in optimal, compiled, languages.
This is appealing as a philosophy because it's the reality that most seem to wish away... many languages always crying for various types of integration. But it's still a scripting language, and in a way any scripting language can borrow that philosophy.
don't forget: ... "you're a naughty one aren't you? He's tryin' to let me cream go bad! But I'm in 'is territory, an' he reckon's I'm out to eat his food."
their name, not his.
No, it's not Asteroids or Missile Command... my mind reading device indicates it's "Space Invaders" that he's thinking of.
No wait -- pachinko!
wrong! Tools should be efficient, if that involves some training for the user... fine. Why should you be able to do something you've never done before in a way familiar to you... it's an unfamiliar task, then it's an unfamiliar tool, you will have to learn how to use it.
Should a screwdriver have to use a hammer's interface because the hammer interface is intuitive because it's ALREADY learned? Should the hammer not have a handle and instead use the interface of the pounding rocks that preceded it?
How do you improve tools if you can't optimize the UI for the task and instead have to optimize it to avoid learning. If the learning is costly, at least the cost stops when the learning is accomplished and the result is an efficient tool. If the tool is not optimized for it's purpose, then you continue to pay for that loss of optimization forever, and eventually it will be more costly than having the user learn the task and method at hand.
Of course you should use known metaphors, and use real world tools and metaphors, but in the end we want the best tool, we are tool building. Tools are not automatically bad because they require knowledge or expertise to apply. In fact, the best tools, the most powerful tools, always do involve learning the tool itself. The interface needs to seem convienient once you have learned it, not before so.
I think you are mistaking a marketing imperitive and marketing principle for an engineering principle.
As for Newton's handwriting recognition... it's so unbelievable I think I might have been trolled! Not the Newton's I used...
to be willingly part of a plan that intends to burn you out in eight years is a bad idea.
The idea that you could work hard and retire in that time is nonsensical, a promise Microsoft can not keep, that it could in the past is the past, like spending lottery money because you'll just win another one, not a good forward plan.
and what by chance do you prefer?
this money is like all the money you "make" saving buying items on sale... if you go to enough sales you can save $100,000 a year and live quite comfortable... but where do you come up with the $1,000,000 it takes to generate that sweet income?
-1 sig comment
what is the meaning of your sig?
No it's really true, and you are right, it could affect you with static linking, but generally is less likely to.
:) I'm not that zealous, but 8 years ago we were worried about performance complications and MI seemed a good thing to avoid.
The issue is this... the binary picture of the object in memory. Strictly speaking the compiler needs to know the parent and descended type to make this upcast (potentially, even without MI). If you do this cast without knowing what the descended type really is, you are taking a pointer and just lying to the compiler what the memory print looks like. This generally works (better know your compiler, but that's true in general, since different compilers generally arrange objects differently in memory) since the object does look like it's parent in memory with single inheritance. The data at the top of the object is the same, you can pretend it's the parent and using virtual functions, the overridden functions will be called. But if the descended class were MI, then the footprint is changed, before the data fields there is likely a new pointer to the second parent's data, or it's virtual functions, or the data is possibly inserted prior to the parent you are upcasting to, etc., but whatever the layout, it's changed, and to make the cast safely the compiler needs to know the child type because it's going to have to find the part of the object that is of the same type as the parent and give you a pointer to that.
This may be making someone shudder as I speak, because I have not mentioned many other ways you should be careful if you play these kinds of games. In general, the way to do this thing carefully is to use pure virtual objects as interfaces, and ask for those (i.e. how COM works). You have some thunking though the interface to your real classes, but everything stays clean and safe, you just have to build or use a thin interface-managing layer (again, such as COM). Real, btw, uses "lightweight" COM even on it's server side... as someone pointed out, COM interfaces are just pure virtual classes... essentially tables of function pointers, so you can use it without the OS registration related stuff that COM also entails (especially now).
The reason this isn't a problem, usually, with static libraries is merely that the compiler usually knows the descended type, and inserts code to do the conversion. With statically linked libraries often the project is arranged such that the compiler does know the return type is, say, class D, and is doing an actual conversion (not just a static_cast).
There are other solutions... the library could convert the pointer the proper way before returning it, which is one way to build COM objects using MI, converting the pointer in the library to what the main code expects or was promised.
So the real issue isn't my specific example, but the havoc that is played at the binary level. A clear strucure-like layout, that maps quite directly to the source code description starts to become mixed up with MI as the compiler juggles the data and function pointers. MI is one of those things that introduces the compiler level voodoo that puts off so many C programmers (e.g. the kind that can't stand even the fact that the 'this' pointer is pushed on the stack and slipped into your function -behind your back!!!-
Mind you, so were templates (not supported) and exceptions (still badly implimented then), both of which I heartily rejoice in now that compilers support them well and efficiently. It's probably time for me to come back to MI, because I use the "mix-in" design idea anyway, which without MI involves some degree of thunking.
One more thing about the extensibility system I created this way. There were a lot of special rules for objects created this way... how you created them, how you added data members... too many specific rules for me to argue that this kind of thing isn't a mine field. I think in a multiparadigmed language it's inevitable that you will have to understand not only C++ but the C++ philosophy of a particular project, before you really understand the project. That's the justification of having extra rules. Still, I would now probably do this much differently.
Playing games at the level of the binary layout of your strucutures is one of the things that makes people now say that C++ is too low level. But the way I see it the only problem is maybe that I should not have thought about it at that level, i.e. it's not C++ fault that it gave me free reign. Considering the task at hand at the time I think it was reasonable in context.
thanks... that's food for thought... your comment that OCaml is statically typed and yet that's generic is interesting... don't quite follow, but I'm not asking for explanation, I'll just take a look at OCaml I guess!
.... ek, VB, I'm in danger of becoming a C++ bigot. I'm unimpressed with those "improvements". Java I like well enough, but to me it's "VB done right", which is not entirely a compliment. I better look at some of the other language candidates brewing to keep the open minded perspective I prefer... Ruby is another language that's been recommended to me.
The decision of pointer or value in containers is also a good example... you have to think through your problem, each time, to figure which is best and acceptable for the problem at hand.
I guess a follow up question of mine is: is there any such problem that cannot be solved with a class or library! That is... is there anything C++ is too low level for that cannot be solved with some system written on C++ that you then use (e.g. we used to write containers a lot, and generally I wrote content specific containers in that case, and now, I can do the same thing design wise but use generic efficient algorithms via the STL portion of stdlib. C++ "became" higher level.)
Do you think C++ highest possible level is bound? I tend to think that we can achieve higher and higher levels of programming, without cutting off any avenue of development, without introducing major performance hits (other than those that are what you "paid" for/wanted). Because C++ is multiparadigmed they don't even have to be OO systems, again, like the stl.
Comparing C++ to Java or PERL or TCL or
What had driven me to avoid MI, and I must say that design wise I struggle to get the effects of MI through other means, was simple.
The first C++ project (and most after) have involved designing extensibility by using a base class in an executable, and derived classes created in dynamically linked libraries. The point being the executable loads the library, links to a constructor function, calls it and is returned and object B which can be upcast to the base class A.
This cannot be done if B is multiply inherited because the executable module does not know about that at compile time.
This came up a lot when I made client software for Windows where we often wanted to do something like this. COM and other solutions were possible, but this was the simplest, requiring no special layer to manage interfaces instances or thunk to the real member functions.