is that sometimes, you don't know the type of blah, or even blah::iterator. Grab a Google Groups, and search the archives of comp.lang.c++.moderated, comp.std.C++ and similar groups if you're interested in why this matters.
That's why I said "almost any": the GCC C++ compiler is one of the few exceptions that appears to avoid padding out to natural alignment by default, at least in any version I've seen. However, in my experience, it is in a small minority. Further, by failing to align the data members on natural boundaries, you typically take a performance hit.
By the way, I'm about to go into the office, where I work on an industry-leading, mathematically-intensive product whose whole purpose in life is the efficient manipulation of complex data structures to implement advanced mathematical algorithms with minimal run-time overhead. It's written in C++, and ships on a dozen different platforms (mostly 32-bit) using 15+ different compilers. So before you go telling people that they don't know what they're talking about, perhaps you should ask where their information came from, or consider checking more than a toy g++ program yourself if you're going to generalise.:-)
I'm confused by your arguments. I thought we were discussing whether UDTs could be value types, not some strange rule that even a lowly int must be accessed by reference. I will also repeat, since you seem to maintain that I'm disagreeing with you, that I think value types are very important in a language, and my only disagreement is your assessment of the performance penalty associated with using reference types.
How many heap space the following C++ code end up using on a standard 32bit machine? How many function calls does the allocation take? How much memory gets written to?
struct { signed char x; signed char y} P;
P *ps = new P[1000000];
(Hint: each P takes up 2 bytes inside the array.)
If you actually believe that hint to be true, I suggest you check again. On almost any current 32-bit platform, sizeof P will be 8 bytes, not 2. You will need around 8MB to store the array, as opposed to 12MB to store the equivalent data using an array of pointers/references to such objects. That's only a 50% addition, and you've carefully chosen the worst possible case: a large array of objects that are as trivial as they can possibly be without being built-ins. Once again, I don't disagree that it's better to have a value type available in such cases, but claiming some sort of radical performance difference in either memory footprint or execution time seems... excessive.
There are also relatively few uses of "main()"; however, that doesn't make that language feature any less important.
Of course it does. It means you should place far less emphasis on how to get main right than on how to write other functions, since you'll be writing other functions far more often, and consequently it requires more effort to repeatedly work around any problems with the mechanism.
Sorry, but you're wrong. A really smart, global optimizer can eliminate some heap allocations from some expressions, but it can't change array representations and it can't optimize this across most method or function calls.
You were talking about simple value types that were essentially created, accessed once, and then destroyed. Nothing in your paragraph above fits in that context. Value types that are placed in arrays or passed to functions typically do not fall into this category.
Of course. All my answers will be the [...] truth. No editorial input will be applied [unless deemed strictly necessary to guarantee appropriate standards of presentation -- Ed] between the time that [I] write the article and the time that [I] send it to [its recipient]. The PR guys promised. [No, we didn't.]
Come on, who're you kiddin'? Any reply from this guy, or anyone else writing on a subject so obviously controvserial, is going to be screened seventeen times over by PR weenies before it gets out into the wild.
Before I post this, let me start by saying that I've never disagreed with you that value classes are useful and more efficient than their reference equivalents. I'm simply contending that the difference isn't nearly as wide as you make out for most purposes.
The indirection may or may not be significant (it can kill you on cache effects),
Theoretically, yes, under some circumstances. In practice, it's unlikely.
but all those objects need to be allocated and deallocated, all that extra space needs to be initialized, etc.
Just as it does with value classes on the stack. The overhead is comparable in each case.
Most instances of value classes are created, their fields accessed once, and then they become garbage instantly.
Where you're using a declarative programming style and this occurs a lot, there's nothing to stop an optimiser from playing the same tricks with a reference class. Chances are neither ever makes it outside of registers and into RAM in many of these cases anyway.
The other place where value classes matter, inside arrays, they are packed tightly and use up a fraction of their reference equivalents.
But that's simply not true. It's very likely that your array will be padded so the offset of each element coincides with the natural alignment of the processor, for example. Many low-level-friendly languages explicitly provide for this (and/or a similar form of padding within structs/classes themselves) in their specifications.
As I said, I'm not contending in any way that value classes don't have their place. Obviously they do, particularly for trivial data types such as the integer, floating point or complex numbers you mentioned. However, there are usually relatively few such types in a program, even quite a large one. In contrast, if the program is built around a reasonably pure OO design, there will be many more complicated classes. It often makes sense to force these to be indirected for future-proofing purposes, rather than pretending they are used in the same sort of way as a genuine value class, which they typically are not.
Of course, that can improve performance as well. You no longer need to remember to pass a const MyType & in C++ just to avoid an implicit copy construction every time you pass a parameter by value, for example.
The point about arrays is well-taken, but that also relates to the underlying implementation of your type, and not to whether it has reference or value semantics.
No, it does not. You cannot even come close to the efficiency of a value class by fiddling around with the internal implementation of an object.
Um... Sorry, you've lost me. Manipulating an array of pointers-to-objects instead of objects in-place -- which is all that's required to support value semantics but an underlying indirection for polymorphism purposes -- requires exactly one extra indirection per array access. In isolation, that's negligible. If you're accessing the objects large numbers of times in a loop, it's potentially significant, but in that case it's possible to optimise away most of the overhead on the major processor architectures in use today. Claims of massive overhead due to polymorphism have been greatly exaggerated, and you certainly can get very close to the performance of your "value classes" while maintaining that level of indirection.
The expensive thing with polymorphic class types is the use of virtual methods (because they typically require at least two levels of indirection to look up, which is harder to optimise away in high frequency code) and multiple/virtual inheritance (where you potentially have a much larger number of indirections). Even then, though, it would require fairly contrived code for this to be a particularly significant overhead.
Yes, it is still there, however, the compiler can generate it automatically for you.
No it can't!
How can my compiler possibly know what a "deep copy" is for my particular data structure? How does it know which references are to be duplicated, and which are to a common database that all objects of this type share? How does it deal with circular data structures?
There is no generic way to write a deep copy operation, which is why you have the concept of this function in the first place. If all you want is trivial deep copying of everything, just use suitable smart pointer classes instead of raw pointers in C++ (which is almost always a good idea anyway) and then C++ will generate these things for you as well.
I didn't ask for virtual functions on them. These kinds of classes go with overloading and templates.
Sure, I appreciate that. I was just pointing out the big drawback to providing these types in an OO language if the rest of the feature set isn't geared up to work with them, not challenging the usefulness of the types themselves.
And yes, I realise that "value class" is a recent term. It goes along with "boxing" and such. They're all equally misrepresentative and horrible!:-)
you could implement value semantics quite sensibly for a class that is really
No, you couldn't. You can emulate immutability through an interface, but immutability is not the point.
Of course you can:
MyType x;
MyType y = DoSomethingWith(x);
Unless I tell you, you can't possibly know what the underlying model is for MyType, even if I tell you that all of the above uses pass/return-by-value and copy-on-assignment semantics. MyType could be a simple pair of co-ordinates on a stack, or a (hidden) pointer to a full-blown OO type with polymorphism and all the trimmings.
Immutability really has nothing to do with this, AFAICS. As you say, that's just a property of the interface you give your type, and it's orthogonal to the reference/value distinction. The point about arrays is well-taken, but that also relates to the underlying implementation of your type, and not to whether it has reference or value semantics.
Non-virtual methods in Java also involve no indirection. A non-virtual method is one that is private, final, or static. The only difference is:
...that in C++, you can have non-virtual methods that aren't one of the above?:-)
I see your point, but the difference is more than just whether methods are virtual by default. In C++, you can have a public (or protected) non-virtual method, for example, and a few OO idioms some people are currently experimenting with rely on this.
Derived classes can also override a non-virtual method; you then have different behaviour depending on whether your object is addressed directly or via a pointer-to-base, for example. Sometimes this can be useful, but it does provide for some unfortunate loopholes in the type system as well.
Does the RIAA/MPAA then try to regulate Internet traffic, i.e. go after ISPs that provide access to Sharman?
No-one seems to have noticed that, with all the Internet traffic logging major governments want in the name of fighting terrorism, it's a very short jump to "Your Honour, we, the RIAA, have identified an illegally copied version of our copyright protected product XYZ in circulation on the Internet at this point right here, and we request a warrant be issued to have the traffic logs reviewed to identify everyone who has received said version of product in the past seven days. We further request that a fixed penalty of $5 equivalent purchase costs plus $10 punitive damages be awarded against each of the offenders."
Of course, whether there's anything wrong with that idea is a different question. If someone is ripping them off, I'm all outta sympathy, sorry. You don't like their prices, you should vote with your wallet or contact your representative, not break the law.
In April WIPO will have a Summit on Intellectual Property and the Knowledge Economy in Beijing.
I nearly modded this up, but couldn't work out whether to mark it (+1, Informative) or (+1, Funny).
The difference between the US and China on IP issues is probably the single biggest example of the matter at hand.
On the one hand, we have China, where they barely acknowledge the concept of intellectual property, and thus produce a very significant fraction of all the bootleg CDs, DVDs and such we see back here in the West.
On the other hand, we have the US, where money apparently talks more than any sense of justice in major court rulings these days. You have companies like Disney who see the intellectual property world as a mechanism for scoring unbounded profits and nothing else, and will use every means at their disposal to further that end.
Unfortunately, neither of these accepts the simple reality: intellectual property is, in principle, a useful incentive for those who can create to do so, but it should be a fairly short term advantage to guarantee a reasonable return on investment, and nothing more. And as long as the biggest guns are held by arguably the two most extreme groups around, we're never going to get anywhere sensible with legislating to support that idea.
Why the creators of D think that providing value classes is a problem, I don't understand.
Providing what you're calling "value classes" isn't a problem. Nor is providing polymorphic behaviour with virtual functions. However, combining the two is a problem, and probably a top-5 cause of bugs in C++ programs.
As an aside, the term "value class" is slightly misleading, IMHO. I suspect what you mean is a class that can be stored in-place and accessed without indirection via a pointer, which isn't necessarily the same: you could implement value semantics quite sensibly for a class that is really always accessed via a (hidden) pointer. It would look the same in code, but the implementation would have the same increased flexibility and performance penalty assoicated with pointers to base classes and the like in today's C++.
Why they couldn't make structs a simple value type that didn't allow virtual methods, and classes a full-blown object type that always looked up a v-table before calling (even if it appeared to have identical value/reference semantics to a struct otherwise) I'll never know. That way, you could have most common uses available trivially, but guarantee safety without nasty things like slicing going on.
(Yes, yes, some classes have some virtual and some non-virtual methods, and you call the non-virtual ones a lot, so you'd take a performance hit making all of them virtual. However, falling back on the old-but-still-true cliche, this is almost always indicative of a misjudged design, IME. If you took away the ability to do it -- in exchange for removing some of the more horrible behaviour you can inadvertently get in C++ -- then people would simply design around it, with no great loss of expressive power than I can see.)
And he's wrong about removing the need for copy c-tors and assignment operators, of course (as he is about several other things he wants to change, such as the need to differentiate between . and ->, which breaks down in data structures that use more than one level of indirection). Fundamentally, you can copy a reference/pointer/other indirection to an object, or you can duplicate its value (whatever that means in context). If you choose to make the = operator of your language do the reference one, you just wind up needing a clone() method of some sort for the other case. It might have a different name, but it's still there.
You think that all that stuff you mentioned doesn't have overhead? C++ just hides all the overhead, which may or may not be the best for your application.
No. In C++, calling a non-virtual method involves no indirection. In languages such as Java, calling any method involves at least one level of indirection, and if you're calling that method all the time but it doesn't actually get overridden in derived classes, that's a potential performance killer.
If you do test-first development and continuous integration (backed up with good black-box integration testing), then the number of bugs you get should be low. In my experience, that's circa one shipped bug per man-month.
I envy you your success rate.:-)
Where I work, we are blessed with enlightened management and team leaders. Our tests are automated, and we have clean builds from the source control system and test runs overnight every night, with summaries generated and mailed to the team in time for the morning. To those who haven't adopted such an automated approach, I cannot advocate it enough. The difference between this and an environment where you're bogged down running numerous tests by hand according to different levels of test spec that took some poor soul weeks to write is staggering. This is from bitter, and then much happier, personal experience.
I'm not entirely convinced by the "test first" philosophy. That's always struck me as more of a political point than a practical one. Where we work, when we want to add a feature, someone first writes a proposal summarising the requirements. We then go through a very iterative development phase, effectively doing the design work by repeated prototyping, and then filling in the blanks.
The key thing we get right, I think, is that as we do this, and we're happy with the results, we actually generate the automated tests from what happens: our software can record the actions it's taken, and various checksum-type information about the results, and can later replay that recording and match (or not) against the previously saved checksums. Making a test is as simple as hitting the record button and then running through some actions that give the correct results, and running the test is as simple as playing back the test file that was previously generated.
It obviously requires a certain amount of effort to implement such a system: you effectively need some sort of "macro language" for the test files, and you need to have a checksumming facility to verify all the data in your system at a given moment and flag discrepancies. Furthermore, these do need to be updated when new features are added (extra macros) or new state is introduced into your model (extra info in the checksums). For the amount of time, and developer tedium, this saves, though, I'd guess it's an investment well worth making for many development shops. It's not even as much work as it first sounds, because many apps are essentially event-driven or based on some sort of command pattern architecture anyway, which means you've already got most of the framework in place.
Even with all of this in place, it's still quite possible to get bugs that are hard to find, though. Just because you know such a test failed, if that test was based on complicated processing, the fault could be anywhere within that process. Still, at least you can always look back at the overnight test records to pinpoint where something was checked in that caused the change.
The government would like to do that, and have tried to get the ability into law for some time. Such powers as they have come from the Regulation of Investigatory Powers Act and its brethren. However, in spite of widespread worry when that particular Act was passed, nothing much has come of it, mostly because the ISPs turned around en masse and told the government where to go and just how practical it was(n't) to keep all the records they were supposed to have on the terms they were supposed to have them.
We do have problems with Internet-related law in this country, with ISPs being in danger of having no tenable legal position one way or another, but fortunately, thus far the sort of harm we're talking about here has yet to materialise.
Does anyone know why interfaces have data members at all?
They wouldn't normally have state, but there might be constants relating to the interface itself, typically passed used when determining what parameters to pass to functions in that interface. Given Java's lack of enumerated types, this is particularly important to avoid passing magic numbers or arbitrary boolean parameters everywhere.
And soon, Java will have templates, too (in upcoming version 1.5).
Just to set the record straight... Java will have some support for generics (no bad thing), but none of the specs I've seen show the same power as C++ templates.
The biggest thing to remember, and this has been said again and again, is that this is beta silicon and beta drivers we're seeing.... nVidia has proven time and time again that they can get a hell of a lot more performance out of their cards with new drivers...
But the thing is, how long do they take to arrive? If you're looking at bleeding edge technology, perhaps because you're buying new this week, the FX isn't an option yet. If you're saying it'll be much better than a Radeon 9700 Pro in a few months, you have to ask what ATI will have by then? The Radeon 9000 series has been around for several months already, after all.
Interestingly, though, it's not the first time I've heard it. I haven't seen the code myself, but some of the other people who've suggested similar things to me probably have.
Given the somewhat... ahem... exaggerated claims that tend to appear on nVidia's web site, I find the theory credible, at least.
But as you say, what we need is someone who actually knows either way, for sure, from their own personal experience.
or maybe the geforceFX offers REAL performance, while the ATI just manages to cheat on benchmarks?;)
Hmm... I just bought a shiny new Radeon 9700 Pro. It's right here, in my hand, about to go in my new PC. Tell you what: I'll set mine up, you build the best GerforceFX-equipped PC you can, and let's test REAL performance. Fair?;-)
Hate to break it to you, but having just spent some days researching this, I concluded that there is nothing that the GeforceFX will support that the Radeon 9000 series won't. nVidia's web site may say differently, but that doesn't make it so.
The FX may do it faster (though this remains to be seen, of course) but it probably won't do it with better image quality. If anything, I'd say ATI cards have historically produced nicer output where there's any difference at all.
Hell, even the drivers for the Radeon 9700 are getting good reviews. I thought the season of miracles was a couple of weeks ago.;-)
It took about a week and a half to get her, but that's very acceptable considering it was right around the holidays. I think most of that was UPS's fault anyways.
Well, this time it'll be Slashdot's. Doesn't anyone ever think to mirror the article before taking out a small company's web site? Knowingly taking out a commercial site like that ought to be illegal.
Why would anybody be worried over this if they are not involved in anything fishy?
It doesn't matter if you are involved in something fishy. It only matters if you appear to be.
Unfortunately, history suggests that an awful lot of innocent people will take the heat for something completely benign if mass surveillance gets implemented. Governments already screw up like this when some techie analyst misunderstands what's happening in a picture, or looking at several sources concludes that 2+2=17.
What makes you think it'll be any different when your significant other, or your boss, or your parents see something that looks (but isn't) out of line?
[Aside: Hell, most western governments can't even manage a routine social security or tax database without screwing up all over the place. For three months, I was doing two full-time jobs on opposite sides of the UK according to the tax office, after someone there mistyped a number one day. I was overtaxed by several hundred pounds as a direct result. I called to fix this, was asked for my address and date of birth to confirm my ID, and was told that they were very sorry, but they couldn't deal with me any more, because what I'd told them didn't match their records. And this was something where obviously what their records said was actually impossible.]
Slashdot Mirror
The problem with
is that sometimes, you don't know the type of blah, or even blah::iterator. Grab a Google Groups, and search the archives of comp.lang.c++.moderated, comp.std.C++ and similar groups if you're interested in why this matters.
That's why I said "almost any": the GCC C++ compiler is one of the few exceptions that appears to avoid padding out to natural alignment by default, at least in any version I've seen. However, in my experience, it is in a small minority. Further, by failing to align the data members on natural boundaries, you typically take a performance hit.
By the way, I'm about to go into the office, where I work on an industry-leading, mathematically-intensive product whose whole purpose in life is the efficient manipulation of complex data structures to implement advanced mathematical algorithms with minimal run-time overhead. It's written in C++, and ships on a dozen different platforms (mostly 32-bit) using 15+ different compilers. So before you go telling people that they don't know what they're talking about, perhaps you should ask where their information came from, or consider checking more than a toy g++ program yourself if you're going to generalise. :-)
I'm confused by your arguments. I thought we were discussing whether UDTs could be value types, not some strange rule that even a lowly int must be accessed by reference. I will also repeat, since you seem to maintain that I'm disagreeing with you, that I think value types are very important in a language, and my only disagreement is your assessment of the performance penalty associated with using reference types.
If you actually believe that hint to be true, I suggest you check again. On almost any current 32-bit platform, sizeof P will be 8 bytes, not 2. You will need around 8MB to store the array, as opposed to 12MB to store the equivalent data using an array of pointers/references to such objects. That's only a 50% addition, and you've carefully chosen the worst possible case: a large array of objects that are as trivial as they can possibly be without being built-ins. Once again, I don't disagree that it's better to have a value type available in such cases, but claiming some sort of radical performance difference in either memory footprint or execution time seems... excessive.
Of course it does. It means you should place far less emphasis on how to get main right than on how to write other functions, since you'll be writing other functions far more often, and consequently it requires more effort to repeatedly work around any problems with the mechanism.
You were talking about simple value types that were essentially created, accessed once, and then destroyed. Nothing in your paragraph above fits in that context. Value types that are placed in arrays or passed to functions typically do not fall into this category.
Of course. All my answers will be the [...] truth. No editorial input will be applied [unless deemed strictly necessary to guarantee appropriate standards of presentation -- Ed] between the time that [I] write the article and the time that [I] send it to [its recipient]. The PR guys promised. [No, we didn't.]
Come on, who're you kiddin'? Any reply from this guy, or anyone else writing on a subject so obviously controvserial, is going to be screened seventeen times over by PR weenies before it gets out into the wild.
Before I post this, let me start by saying that I've never disagreed with you that value classes are useful and more efficient than their reference equivalents. I'm simply contending that the difference isn't nearly as wide as you make out for most purposes.
Theoretically, yes, under some circumstances. In practice, it's unlikely.
Just as it does with value classes on the stack. The overhead is comparable in each case.
Where you're using a declarative programming style and this occurs a lot, there's nothing to stop an optimiser from playing the same tricks with a reference class. Chances are neither ever makes it outside of registers and into RAM in many of these cases anyway.
But that's simply not true. It's very likely that your array will be padded so the offset of each element coincides with the natural alignment of the processor, for example. Many low-level-friendly languages explicitly provide for this (and/or a similar form of padding within structs/classes themselves) in their specifications.
As I said, I'm not contending in any way that value classes don't have their place. Obviously they do, particularly for trivial data types such as the integer, floating point or complex numbers you mentioned. However, there are usually relatively few such types in a program, even quite a large one. In contrast, if the program is built around a reasonably pure OO design, there will be many more complicated classes. It often makes sense to force these to be indirected for future-proofing purposes, rather than pretending they are used in the same sort of way as a genuine value class, which they typically are not.
Of course, that can improve performance as well. You no longer need to remember to pass a const MyType & in C++ just to avoid an implicit copy construction every time you pass a parameter by value, for example.
Um... Sorry, you've lost me. Manipulating an array of pointers-to-objects instead of objects in-place -- which is all that's required to support value semantics but an underlying indirection for polymorphism purposes -- requires exactly one extra indirection per array access. In isolation, that's negligible. If you're accessing the objects large numbers of times in a loop, it's potentially significant, but in that case it's possible to optimise away most of the overhead on the major processor architectures in use today. Claims of massive overhead due to polymorphism have been greatly exaggerated, and you certainly can get very close to the performance of your "value classes" while maintaining that level of indirection.
The expensive thing with polymorphic class types is the use of virtual methods (because they typically require at least two levels of indirection to look up, which is harder to optimise away in high frequency code) and multiple/virtual inheritance (where you potentially have a much larger number of indirections). Even then, though, it would require fairly contrived code for this to be a particularly significant overhead.
No it can't!
How can my compiler possibly know what a "deep copy" is for my particular data structure? How does it know which references are to be duplicated, and which are to a common database that all objects of this type share? How does it deal with circular data structures?
There is no generic way to write a deep copy operation, which is why you have the concept of this function in the first place. If all you want is trivial deep copying of everything, just use suitable smart pointer classes instead of raw pointers in C++ (which is almost always a good idea anyway) and then C++ will generate these things for you as well.
Sure, I appreciate that. I was just pointing out the big drawback to providing these types in an OO language if the rest of the feature set isn't geared up to work with them, not challenging the usefulness of the types themselves.
And yes, I realise that "value class" is a recent term. It goes along with "boxing" and such. They're all equally misrepresentative and horrible! :-)
Of course you can:
MyType x;
MyType y = DoSomethingWith(x);
Unless I tell you, you can't possibly know what the underlying model is for MyType, even if I tell you that all of the above uses pass/return-by-value and copy-on-assignment semantics. MyType could be a simple pair of co-ordinates on a stack, or a (hidden) pointer to a full-blown OO type with polymorphism and all the trimmings.
Immutability really has nothing to do with this, AFAICS. As you say, that's just a property of the interface you give your type, and it's orthogonal to the reference/value distinction. The point about arrays is well-taken, but that also relates to the underlying implementation of your type, and not to whether it has reference or value semantics.
...that in C++, you can have non-virtual methods that aren't one of the above? :-)
I see your point, but the difference is more than just whether methods are virtual by default. In C++, you can have a public (or protected) non-virtual method, for example, and a few OO idioms some people are currently experimenting with rely on this.
Derived classes can also override a non-virtual method; you then have different behaviour depending on whether your object is addressed directly or via a pointer-to-base, for example. Sometimes this can be useful, but it does provide for some unfortunate loopholes in the type system as well.
No-one seems to have noticed that, with all the Internet traffic logging major governments want in the name of fighting terrorism, it's a very short jump to "Your Honour, we, the RIAA, have identified an illegally copied version of our copyright protected product XYZ in circulation on the Internet at this point right here, and we request a warrant be issued to have the traffic logs reviewed to identify everyone who has received said version of product in the past seven days. We further request that a fixed penalty of $5 equivalent purchase costs plus $10 punitive damages be awarded against each of the offenders."
Of course, whether there's anything wrong with that idea is a different question. If someone is ripping them off, I'm all outta sympathy, sorry. You don't like their prices, you should vote with your wallet or contact your representative, not break the law.
I nearly modded this up, but couldn't work out whether to mark it (+1, Informative) or (+1, Funny).
The difference between the US and China on IP issues is probably the single biggest example of the matter at hand.
On the one hand, we have China, where they barely acknowledge the concept of intellectual property, and thus produce a very significant fraction of all the bootleg CDs, DVDs and such we see back here in the West.
On the other hand, we have the US, where money apparently talks more than any sense of justice in major court rulings these days. You have companies like Disney who see the intellectual property world as a mechanism for scoring unbounded profits and nothing else, and will use every means at their disposal to further that end.
Unfortunately, neither of these accepts the simple reality: intellectual property is, in principle, a useful incentive for those who can create to do so, but it should be a fairly short term advantage to guarantee a reasonable return on investment, and nothing more. And as long as the biggest guns are held by arguably the two most extreme groups around, we're never going to get anywhere sensible with legislating to support that idea.
Providing what you're calling "value classes" isn't a problem. Nor is providing polymorphic behaviour with virtual functions. However, combining the two is a problem, and probably a top-5 cause of bugs in C++ programs.
As an aside, the term "value class" is slightly misleading, IMHO. I suspect what you mean is a class that can be stored in-place and accessed without indirection via a pointer, which isn't necessarily the same: you could implement value semantics quite sensibly for a class that is really always accessed via a (hidden) pointer. It would look the same in code, but the implementation would have the same increased flexibility and performance penalty assoicated with pointers to base classes and the like in today's C++.
Why they couldn't make structs a simple value type that didn't allow virtual methods, and classes a full-blown object type that always looked up a v-table before calling (even if it appeared to have identical value/reference semantics to a struct otherwise) I'll never know. That way, you could have most common uses available trivially, but guarantee safety without nasty things like slicing going on.
(Yes, yes, some classes have some virtual and some non-virtual methods, and you call the non-virtual ones a lot, so you'd take a performance hit making all of them virtual. However, falling back on the old-but-still-true cliche, this is almost always indicative of a misjudged design, IME. If you took away the ability to do it -- in exchange for removing some of the more horrible behaviour you can inadvertently get in C++ -- then people would simply design around it, with no great loss of expressive power than I can see.)
And he's wrong about removing the need for copy c-tors and assignment operators, of course (as he is about several other things he wants to change, such as the need to differentiate between . and ->, which breaks down in data structures that use more than one level of indirection). Fundamentally, you can copy a reference/pointer/other indirection to an object, or you can duplicate its value (whatever that means in context). If you choose to make the = operator of your language do the reference one, you just wind up needing a clone() method of some sort for the other case. It might have a different name, but it's still there.
No. In C++, calling a non-virtual method involves no indirection. In languages such as Java, calling any method involves at least one level of indirection, and if you're calling that method all the time but it doesn't actually get overridden in derived classes, that's a potential performance killer.
I envy you your success rate. :-)
Where I work, we are blessed with enlightened management and team leaders. Our tests are automated, and we have clean builds from the source control system and test runs overnight every night, with summaries generated and mailed to the team in time for the morning. To those who haven't adopted such an automated approach, I cannot advocate it enough. The difference between this and an environment where you're bogged down running numerous tests by hand according to different levels of test spec that took some poor soul weeks to write is staggering. This is from bitter, and then much happier, personal experience.
I'm not entirely convinced by the "test first" philosophy. That's always struck me as more of a political point than a practical one. Where we work, when we want to add a feature, someone first writes a proposal summarising the requirements. We then go through a very iterative development phase, effectively doing the design work by repeated prototyping, and then filling in the blanks.
The key thing we get right, I think, is that as we do this, and we're happy with the results, we actually generate the automated tests from what happens: our software can record the actions it's taken, and various checksum-type information about the results, and can later replay that recording and match (or not) against the previously saved checksums. Making a test is as simple as hitting the record button and then running through some actions that give the correct results, and running the test is as simple as playing back the test file that was previously generated.
It obviously requires a certain amount of effort to implement such a system: you effectively need some sort of "macro language" for the test files, and you need to have a checksumming facility to verify all the data in your system at a given moment and flag discrepancies. Furthermore, these do need to be updated when new features are added (extra macros) or new state is introduced into your model (extra info in the checksums). For the amount of time, and developer tedium, this saves, though, I'd guess it's an investment well worth making for many development shops. It's not even as much work as it first sounds, because many apps are essentially event-driven or based on some sort of command pattern architecture anyway, which means you've already got most of the framework in place.
Even with all of this in place, it's still quite possible to get bugs that are hard to find, though. Just because you know such a test failed, if that test was based on complicated processing, the fault could be anywhere within that process. Still, at least you can always look back at the overnight test records to pinpoint where something was checked in that caused the change.
The government would like to do that, and have tried to get the ability into law for some time. Such powers as they have come from the Regulation of Investigatory Powers Act and its brethren. However, in spite of widespread worry when that particular Act was passed, nothing much has come of it, mostly because the ISPs turned around en masse and told the government where to go and just how practical it was(n't) to keep all the records they were supposed to have on the terms they were supposed to have them.
We do have problems with Internet-related law in this country, with ISPs being in danger of having no tenable legal position one way or another, but fortunately, thus far the sort of harm we're talking about here has yet to materialise.
They wouldn't normally have state, but there might be constants relating to the interface itself, typically passed used when determining what parameters to pass to functions in that interface. Given Java's lack of enumerated types, this is particularly important to avoid passing magic numbers or arbitrary boolean parameters everywhere.
Just to set the record straight... Java will have some support for generics (no bad thing), but none of the specs I've seen show the same power as C++ templates.
Why? What do you think the FX can do that the 9000 series can't?
But the thing is, how long do they take to arrive? If you're looking at bleeding edge technology, perhaps because you're buying new this week, the FX isn't an option yet. If you're saying it'll be much better than a Radeon 9700 Pro in a few months, you have to ask what ATI will have by then? The Radeon 9000 series has been around for several months already, after all.
You're right, it is a pretty serious allegation.
Interestingly, though, it's not the first time I've heard it. I haven't seen the code myself, but some of the other people who've suggested similar things to me probably have.
Given the somewhat... ahem... exaggerated claims that tend to appear on nVidia's web site, I find the theory credible, at least.
But as you say, what we need is someone who actually knows either way, for sure, from their own personal experience.
Hmm... I just bought a shiny new Radeon 9700 Pro. It's right here, in my hand, about to go in my new PC. Tell you what: I'll set mine up, you build the best GerforceFX-equipped PC you can, and let's test REAL performance. Fair? ;-)
Hate to break it to you, but having just spent some days researching this, I concluded that there is nothing that the GeforceFX will support that the Radeon 9000 series won't. nVidia's web site may say differently, but that doesn't make it so.
The FX may do it faster (though this remains to be seen, of course) but it probably won't do it with better image quality. If anything, I'd say ATI cards have historically produced nicer output where there's any difference at all.
Hell, even the drivers for the Radeon 9700 are getting good reviews. I thought the season of miracles was a couple of weeks ago. ;-)
Well, this time it'll be Slashdot's. Doesn't anyone ever think to mirror the article before taking out a small company's web site? Knowingly taking out a commercial site like that ought to be illegal.
It isn't, in itself. It becomes so when, for example, the "boss requiring evidence of sickness" scenario arrives.
It doesn't matter if you are involved in something fishy. It only matters if you appear to be.
Unfortunately, history suggests that an awful lot of innocent people will take the heat for something completely benign if mass surveillance gets implemented. Governments already screw up like this when some techie analyst misunderstands what's happening in a picture, or looking at several sources concludes that 2+2=17.
What makes you think it'll be any different when your significant other, or your boss, or your parents see something that looks (but isn't) out of line?
[Aside: Hell, most western governments can't even manage a routine social security or tax database without screwing up all over the place. For three months, I was doing two full-time jobs on opposite sides of the UK according to the tax office, after someone there mistyped a number one day. I was overtaxed by several hundred pounds as a direct result. I called to fix this, was asked for my address and date of birth to confirm my ID, and was told that they were very sorry, but they couldn't deal with me any more, because what I'd told them didn't match their records. And this was something where obviously what their records said was actually impossible.]