point 1: Class designers often do not know which methods will need to be overridden in derived classes, thus if they are kind they declare any usefully overridable method virtual. Now, dispite the C++ mythos of paying only for what you ask for, all clients of that class must now pay for the virtual table overhead even if nothing in their _particular_ application requires overloading of some of the virtual methods.
point 2: Only public/protected functions that are not marked to be un-overloadable would require this special processing. Most of the code generation could still be done at compile-time, but you'd have to allow for some flexibility w/respect to code layout and additional (small amounts) of code at final link. You definitely could not use existing object file formats.
Dynamic libraries are a difficulty with this scheme, but could be done by falling back to vptr tables for the classes that are exposted by the library.
point 3: As for virtual methods, a jump through a data table is more expensive because no speculative execution can be performed. This is true even for implementations that put jump instruction in the table. The pipeline is stalled until the vptr of the object is fetched. By contrast, even if the id of an object has not been fetched, decision trees can be speculatively executed, at least for small orders of overloading. Thus by the time the id is fetched, the correct code will most likely already be in the pipeline.
This ignores the idea that you want to be able to explicitly tell the compiler which functions should be allowed to be "virtualized." How would that work out if the compiler auto figured out which functions should be virtual? Would you replace virtual with a "no_virtual"
I think a keyword like "final" on a base method that you don't want to be overloaded, and a "overload" keyword on the method in the derived class would do what you want ( to avoid erronous overloading). With these kinds of changes, a new language would probably be required as it wouldn't be particularly backwards compatible.
Small Eiffel does some of this. Not that I advocate Eiffel per se. See:
Not necessarily a good thing. Redundance catches errors.
The only errors this catches are discrepancies in the header and source, which of course would be avoided by this feature.
Definitely not a good thing, virtualness is important when reasoning about a class. After a call to a virtual function much more state is uncertain than after a call to a non-virtual call
I disagree. Virtual-ness is an implementation issue which is exposed in the base class because of linker limitations. There should however be an overload keyword for methods in the derived class to make the intent clear and avoid erronous overloading, as well as a way to keep base methods from being overloaded intentionally.
The type information has to be represented somehow, name mangling is not really different from other means.
However with sufficiently advanced linking technology, no mangling need be done at all. Its a kludge to get around old linkers.
I don't seriously think the C++ committee would make any of these changes a reality, but I can dream. More likely a new high performance language will be created soon. There are so many issues in C++ due to its heritage, any new language with similiar (or greater) performance, features and a C-ish feel would be instantly popular, and probably take away both Java and C++ "market share" very quickly. It's an opportunity waiting to happen.
Wow, so smug, and yet so wrong. Rather than explain in excruciating detail how narrow minded your response was, or possibly how poor or incomplete your education is, I'll forgo all that nastiness and help you out.
Headers are a kludge leftover from C++' C ancestory. They allow all sorts of nasty tricks, but generally are considered the simplest way to accomplish independent compilation units. A more complicated, but much more efficient and less error-prone way to do this is to devise a language in which you can annotate the methods, types, etc that you wish to be part of the interface for a unit. When the compiler compiles the unit source, a compact description of the unit's interface is stored _somewhere_ in your build environment. When you need to use the interface of another module, your compiler goes into that module's description and pulls out the information it needs without doing any parsing whatsoever. I would imagine you would get compilation speeds in excess of a simple language like C using this technique.
For a library supplier, they can use a simple tool to generate documentation from the source.
As for virtual methods, this is an implementation detail that really does not need to exposed in the language if it could optionally use better linker/object technology. The language implementation can decide which methods need to be virtual itself through global analysis at or before linkage. For any given method, it must be virtual if any derived class overloads it. Since current linker/object technology is incapable of maintaining this kind of information and some code generation would be required at linkage, a more flexible object code format and linking technology would need to be created, but we are talking about a new version of C++, aren't we?
Note that once you have the list of methods which overload a method, you can implement that method using a decision tree, each branch of which contains the code for the derived class. This avoids the pipeline stalls that you get with vptr virtual dispatch, which I might note is essentially forced upon the compiler writer because of inadequate linker technology.
All sorts of interestings things become possible and lots of C++ frustrations fall away when the antiquated C linkage mechanism is done away with. But I fear it is too radical a change or it can't be done in a backwards compatible way. So I'm not holding my breath.
No there are plenty more areas that warrant a gripe.
The lack of an alternative to #include and 30+ year old linking technology sticks out in my mind as something that impacts both programmer and execution time. Fixing this would allow:
1. Losing the pointless duplication of declarations in.h files. In fact, you would not need.h files anymore except for backwards compatibility. 'Course you'd lose the ability to make a header file do different things based on defined symbols, but that would be an advance IMHO.
2. Virtual methods can be determined by the linker, so the programmer no longer needs to specify virtual-ness at all.
3. Virtual methods can be implemented by binary decision trees instead of jump tables. This speeds execution on pipelined CPUs. They can also be inlined when there are few overloads.
4. Inlining and template instatiation can be post poned until link given a sufficiently sophisticated intermediate format. In fact the compiler can inline any method or function.
5. No more name mangling.
6. Faster compiles -> no need to parse the same M header files N times for N files, once compiled, the intermediate format defines the interface to a module. Basically this is essentially global precompiled headers.
Could this be done and keep backwards compatability? I don't know, and I wouldn't care. I would personally convert all 5000+ of my companies C++ modules just for the performance benefit and future time saved.
The elevators make that Steve-Austin-in-action sound, I guess.
Re:Mandrake 8.0 Out! FTP install possible anyone??
on
Mandrake 8.0 Comes Out
·
· Score: 1
Errr, lt mousewheel support has been in there for some time, as long as you're willing to edit the X configuration. Hopefully it is set up for you in the installation with this version.
I don't disagree that we should keep an eye on china, but one point bares mentioning: a trade deficit does not necessarily mean that china is making more money from the relationship. This depends on the profit margin of the goods involved.
Trade deficits are a non-problem that have been cooked into a problem by the media.
Good grief, if Linux isn't collectivist, then I'll eat my shorts.
Only metaphorically and poorly at that. "Collectivism" is usually applied to a political system, which Linux is surely not. Even if you think of the people who use/contribute to Linux as a "collective", it is a collective in which individuals are free to come and go. This flys against the idea of a collective where individuals are subsumed into the whole. Perhaps you mean that the code is collective, in which case I'd agree, but faced with the mass subjegation of thousands of lines of code under the facist rule of the hard-line Torvalds, I'm hard pressed to feel any empathy for their predictament and possible mass extinction in yet another versioning pogrom.
Of course there is a correlation, but innovation and technical quality are not the only factors which allow commercial success. Marketing, organization, features, usability, and timing also are factors, to name a few.
I'm sorry, but my experience differs. Perhaps your "star programmer" generated garbage in large volumes. There are people who generate great code quickly. Indeed, they are rare.
No method fits every situation and coder. Pair programming (to differentiate this practice from the other facets of XP) might be useful when coders are either inexperienced or merely unexceptional. Pair programming will slow down the star programmer and frustrate his need to get into that solitary zone where the code flies out of his fingers faster than a greased pig on teflon.
Yes, verbal communication of URLs is a problem, even in english. Often they must be spelled.
Certainly learning one alphabet is easier than having to deal with the european character variations, not to mention the pictographic languages. Hopefully all sites with anything of interest to those outside their language region will have the foresight to register an ASCII equivalent, but I'm not sure this will happen if it is an additional expense, and lack of foresight will probably rule.
Is it just me? Is the whole idea of multilingual DNS names just completely dumb? The difficulty is in entering or communicating domain names that are not in one of your own languages. Rendering different languages is one thing, and IMO a good thing, but for domain names, where everyone sometimes needs to type one in, anyway you cut it ASCII is the worst solution, except for all the others. I can just imagine on a trip to china having to explain the local chinese domain name just to get someone to FTP me something.
The PIV has a tree of clock generaters with adjustable delays to handle clock skewing problems..this must have been a nightmare to design. Sounds like you almost have to go asyncronous in some fashion just to get the complexity down as the # of transisters heads toward the billions.
I don't think this thing is going to fly either, but after the first point, your objections are mainly just strawmen.
This concept, if it works, takes away my only objection to public transport - it never goes where I want to go.
About the only way I could think that this system could get off the ground is to have the first ones over the worst congested highways of a city, and initially mainly rent and lease the suckers, so people can try them out.
It couldn't be any more expensive than light rail, and nobody uses that unless it drops them near their destination.
Come the first good sized earthquake or uplifting wind shear, these light weight vehicles will be flying off the track. If there's not a flange at the top of the rail (hard to tell), there needs to be.
Otherwise, very cool idea, although the top speed needs to be about doubled for longer routes. 50 mph is way too slow.
True enough. Ideally users should be able to open a "tuning wizard" that would be able to help you tune the system for speed vs glitz, and slimness vs bloat.
But in the meantime, there's no reason why elite users like yourself can't figure out how to turn stuff like this off, is there?
Boucher's district is the western part of virginia, predominately rural, white and economically depressed--democrats do fine there, as long as they believe in god and aren't slick--character matters to these folks.
I used to live in boucher's district, and basically there is no big tech there for him to be heholden to. He's just an intelligent guy with a backbone.
If that's you on your homepage, I'd say the chances are good. NASA loves compact individuals. Just volunteer for the next experiment on the effect of zero g on mammal brain cell growth, and you're good to go.
nowhere in the constitution does it say you have a right to clean air!" as if that was some sort of a reason for the government not to work to provide clean air, an absurd point on its face
Don't put words into my mouth--That was not my point. A right to something is much stronger than "government should work toward". The former will be _guaranteed_ to each individual, the latter is a goal, and may not be achieved. To make collective goals into guaranteed individual rights is a recipe for disaster.
And I repeat, there is no right to clean air, never has been, and never will. It is impossible to guarantee. Do I think government should encourage clean air? Yes, and by any means except misusing its monopoly on legal force.
OT: you would be more interesting to argue with if you didn't assume so much about your opponent...and get it wrong to boot. LOL!
Slashdot Mirror
point 1: Class designers often do not know which methods will need to be overridden in derived classes, thus if they are kind they declare any usefully overridable method virtual. Now, dispite the C++ mythos of paying only for what you ask for, all clients of that class must now pay for the virtual table overhead even if nothing in their _particular_ application requires overloading of some of the virtual methods.
point 2: Only public/protected functions that are not marked to be un-overloadable would require this special processing. Most of the code generation could still be done at compile-time, but you'd have to allow for some flexibility w/respect to code layout and additional (small amounts) of code at final link. You definitely could not use existing object file formats.
Dynamic libraries are a difficulty with this scheme, but could be done by falling back to vptr tables for the classes that are exposted by the library.
point 3: As for virtual methods, a jump through a data table is more expensive because no speculative execution can be performed. This is true even for implementations that put jump instruction in the table. The pipeline is stalled until the vptr of the object is fetched. By contrast, even if the id of an object has not been fetched, decision trees can be speculatively executed, at least for small orders of overloading. Thus by the time the id is fetched, the correct code will most likely already be in the pipeline.
This ignores the idea that you want to be able to explicitly tell the compiler which functions should be allowed to be "virtualized." How would that work out if the compiler auto figured out which functions should be virtual? Would you replace virtual with a "no_virtual"
I think a keyword like "final" on a base method that you don't want to be overloaded, and a "overload" keyword on the method in the derived class would do what you want ( to avoid erronous overloading). With these kinds of changes, a new language would probably be required as it wouldn't be particularly backwards compatible.
Small Eiffel does some of this. Not that I advocate Eiffel per se. See:
http://smalleiffel.loria.fr/papers/papers.html
Not necessarily a good thing. Redundance catches errors.
The only errors this catches are discrepancies in the header and source, which of course would be avoided by this feature.
Definitely not a good thing, virtualness is important when reasoning about a class. After a call to a virtual function much more state is uncertain than after a call to a non-virtual call
I disagree. Virtual-ness is an implementation issue which is exposed in the base class because of linker limitations. There should however be an overload keyword for methods in the derived class to make the intent clear and avoid erronous overloading, as well as a way to keep base methods from being overloaded intentionally.
The type information has to be represented somehow, name mangling is not really different from other means.
However with sufficiently advanced linking technology, no mangling need be done at all. Its a kludge to get around old linkers.
I don't seriously think the C++ committee would make any of these changes a reality, but I can dream. More likely a new high performance language will be created soon. There are so many issues in C++ due to its heritage, any new language with similiar (or greater) performance, features and a C-ish feel would be instantly popular, and probably take away both Java and C++ "market share" very quickly. It's an opportunity waiting to happen.
Wow, so smug, and yet so wrong. Rather than explain in excruciating detail how narrow minded your response was, or possibly how poor or incomplete your education is, I'll forgo all that nastiness and help you out.
Headers are a kludge leftover from C++' C ancestory. They allow all sorts of nasty tricks, but generally are considered the simplest way to accomplish independent compilation units. A more complicated, but much more efficient and less error-prone way to do this is to devise a language in which you can annotate the methods, types, etc that you wish to be part of the interface for a unit. When the compiler compiles the unit source, a compact description of the unit's interface is stored _somewhere_ in your build environment. When you need to use the interface of another module, your compiler goes into that module's description and pulls out the information it needs without doing any parsing whatsoever. I would imagine you would get compilation speeds in excess of a simple language like C using this technique.
For a library supplier, they can use a simple tool to generate documentation from the source.
As for virtual methods, this is an implementation detail that really does not need to exposed in the language if it could optionally use better linker/object technology. The language implementation can decide which methods need to be virtual itself through global analysis at or before linkage. For any given method, it must be virtual if any derived class overloads it. Since current linker/object technology is incapable of maintaining this kind of information and some code generation would be required at linkage, a more flexible object code format and linking technology would need to be created, but we are talking about a new version of C++, aren't we?
Note that once you have the list of methods which overload a method, you can implement that method using a decision tree, each branch of which contains the code for the derived class. This avoids the pipeline stalls that you get with vptr virtual dispatch, which I might note is essentially forced upon the compiler writer because of inadequate linker technology.
All sorts of interestings things become possible and lots of C++ frustrations fall away when the antiquated C linkage mechanism is done away with. But I fear it is too radical a change or it can't be done in a backwards compatible way. So I'm not holding my breath.
No there are plenty more areas that warrant a gripe.
.h files. In fact, you would not need .h files anymore except for backwards compatibility. 'Course you'd lose the ability to make a header file do different things based on defined symbols, but that would be an advance IMHO.
The lack of an alternative to #include and 30+ year old linking technology sticks out in my mind as something that impacts both programmer and execution time. Fixing this would allow:
1. Losing the pointless duplication of declarations in
2. Virtual methods can be determined by the linker, so the programmer no longer needs to specify virtual-ness at all.
3. Virtual methods can be implemented by binary decision trees instead of jump tables. This speeds execution on pipelined CPUs. They can also be inlined when there are few overloads.
4. Inlining and template instatiation can be post poned until link given a sufficiently sophisticated intermediate format. In fact the compiler can inline any method or function.
5. No more name mangling.
6. Faster compiles -> no need to parse the same M header files N times for N files, once compiled, the intermediate format defines the interface to a module. Basically this is essentially global precompiled headers.
Could this be done and keep backwards compatability? I don't know, and I wouldn't care. I would personally convert all 5000+ of my companies C++ modules just for the performance benefit and future time saved.
The elevators make that Steve-Austin-in-action sound, I guess.
Errr, lt mousewheel support has been in there for some time, as long as you're willing to edit the X configuration. Hopefully it is set up for you in the installation with this version.
I don't disagree that we should keep an eye on china, but one point bares mentioning: a trade deficit does not necessarily mean that china is making more money from the relationship. This depends on the profit margin of the goods involved.
Trade deficits are a non-problem that have been cooked into a problem by the media.
Good grief, if Linux isn't collectivist, then I'll eat my shorts.
Only metaphorically and poorly at that. "Collectivism" is usually applied to a political system, which Linux is surely not. Even if you think of the people who use/contribute to Linux as a "collective", it is a collective in which individuals are free to come and go. This flys against the idea of a collective where individuals are subsumed into the whole. Perhaps you mean that the code is collective, in which case I'd agree, but faced with the mass subjegation of thousands of lines of code under the facist rule of the hard-line Torvalds, I'm hard pressed to feel any empathy for their predictament and possible mass extinction in yet another versioning pogrom.
Of course there is a correlation, but innovation and technical quality are not the only factors which allow commercial success. Marketing, organization, features, usability, and timing also are factors, to name a few.
I'm sorry, but my experience differs. Perhaps your "star programmer" generated garbage in large volumes. There are people who generate great code quickly. Indeed, they are rare.
No method fits every situation and coder. Pair programming (to differentiate this practice from the other facets of XP) might be useful when coders are either inexperienced or merely unexceptional. Pair programming will slow down the star programmer and frustrate his need to get into that solitary zone where the code flies out of his fingers faster than a greased pig on teflon.
Yeah but it would give MS Windows the correct kind of smell.
Heh...Stink-wrapped software.
..for a box of fucking condoms.
:)
Is there any other kind of condom?
Yes, verbal communication of URLs is a problem, even in english. Often they must be spelled.
Certainly learning one alphabet is easier than having to deal with the european character variations, not to mention the pictographic languages. Hopefully all sites with anything of interest to those outside their language region will have the foresight to register an ASCII equivalent, but I'm not sure this will happen if it is an additional expense, and lack of foresight will probably rule.
Is it just me? Is the whole idea of multilingual DNS names just completely dumb? The difficulty is in entering or communicating domain names that are not in one of your own languages. Rendering different languages is one thing, and IMO a good thing, but for domain names, where everyone sometimes needs to type one in, anyway you cut it ASCII is the worst solution, except for all the others. I can just imagine on a trip to china having to explain the local chinese domain name just to get someone to FTP me something.
The PIV has a tree of clock generaters with adjustable delays to handle clock skewing problems..this must have been a nightmare to design. Sounds like you almost have to go asyncronous in some fashion just to get the complexity down as the # of transisters heads toward the billions.
I don't think this thing is going to fly either, but after the first point, your objections are mainly just strawmen.
This concept, if it works, takes away my only objection to public transport - it never goes where I want to go.
About the only way I could think that this system could get off the ground is to have the first ones over the worst congested highways of a city, and initially mainly rent and lease the suckers, so people can try them out.
It couldn't be any more expensive than light rail, and nobody uses that unless it drops them near their destination.
Come the first good sized earthquake or uplifting wind shear, these light weight vehicles will be flying off the track. If there's not a flange at the top of the rail (hard to tell), there needs to be.
Otherwise, very cool idea, although the top speed needs to be about doubled for longer routes. 50 mph is way too slow.
True enough. Ideally users should be able to open a "tuning wizard" that would be able to help you tune the system for speed vs glitz, and slimness vs bloat.
But in the meantime, there's no reason why elite users like yourself can't figure out how to turn stuff like this off, is there?
Boucher's district is the western part of virginia, predominately rural, white and economically depressed--democrats do fine there, as long as they believe in god and aren't slick--character matters to these folks.
I used to live in boucher's district, and basically there is no big tech there for him to be heholden to. He's just an intelligent guy with a backbone.
Sure, and bald men have more testosterone.
If that's you on your homepage, I'd say the chances are good. NASA loves compact individuals. Just volunteer for the next experiment on the effect of zero g on mammal brain cell growth, and you're good to go.
nowhere in the constitution does it say you have a right to clean air!" as if that was some sort of a reason for the government not to work to provide clean air, an absurd point on its face
Don't put words into my mouth--That was not my point. A right to something is much stronger than "government should work toward". The former will be _guaranteed_ to each individual, the latter is a goal, and may not be achieved. To make collective goals into guaranteed individual rights is a recipe for disaster.
And I repeat, there is no right to clean air, never has been, and never will. It is impossible to guarantee. Do I think government should encourage clean air? Yes, and by any means except misusing its monopoly on legal force.
OT: you would be more interesting to argue with if you didn't assume so much about your opponent...and get it wrong to boot. LOL!