Is a certain percentage of bugs that result from the interaction of two or more otherwise bug free components?
If two components interact and the resulting behavior is buggy, then I would say that one of the components must have had bugs that were not readily apparent before. Perhaps the specs for the interfaces of the components were incorrect or incomplete, but that's still a bug.
To take a ridiculous example, someone I know was instructed to develop an application that parsed and interpreted a subset of Java at runtime for certain aspects of program logic. When he pointed out that it would be easier and more reliable to dynamically load real.class files, he was told that that was no good as the class files would be "executables" and therefore need a formal software change notice, but the slapped-together interpreter would be reading "config files" which could be changed more easily. The manager in charge of the project, of course, was several layers below the managers that dictated the procedures, and found it easier to design round the restrictions than to change them.
I know that situation sounds absurd, but I work for a large defense firm, and I have heard of very similar situations. I've even heard of some projects where scripts written in bona fide interpreted languages (e.g. Perl) were classified as data instead of code because it made dealing with the processes of managing them simpler. The "embedded Java interpreter" is an interesting extension to this idea. I suppose one could always go to the extreme and ship any given product with a C compiler, eh? Ah, the crazy things to which bureaucracy and excessive process can drive you...
"The Kodak EasyShare LS633 zoom digital camera is designed for photographers who want to capture and share photos while enjoying the benefits of advanced technology."
Criminy, who writes this crap -- Kodak's marketing division?
Well, they are beating around the bush, but I think that they are trying to say that the camera provides a robust, enterprise-ready turn-key camera implementation for advanced photographers, which enables them to rapidly develop and deploy high-quality, customer-oriented photographic solutions to their clients.
Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?
I used to work with an older fellow who developed software long before I was born. He would complain that decomposing subroutines into smaller, bite-sized subroutines made the program logic harder to follow. He was used to having very long subroutines that performed complicated tasks. He liked to read functions from start to finish and thought that jumping from subroutine to "utility" subroutine and back again was confusing. At the time, I thought that his complaint was ludicrous, mostly because I was so used to having smaller functions that made the high-level logic simpler. To understand decomposed code, instead of thinking in terms of lines of code (execute line 1, then 2, then 3, then 4... then N etc) and understanding each simple line as it appeared in the program, one should think in terms of larger code blocks (execute a simple utility function whose responsibilities I understand, then line 2, then another simple utility function whose responsibilities I understand, etc).
Your complaint about OO programming sounds somewhat similar. Yes, it is true that dynamically bound functions make the program's flow nonlinear, but when the interface to a method or class is well-defined, this isn't a problem. If method A's responsibilities are clearly documented, then it should not matter whether method A is dynamically bound or not. Instead of thinking (for example) "after code block X, execute code block Y", one should think "after performing some operation X whose interface is defined in this way, perform some operation Y whose interface is defined in that way".
That being said, I do not understand the benefit of aspects. I have read all of the examples, but I have not been able to change my way of looking at software so that I may understand how aspects can improve development. I'm still stuck asking myself "what's the point?".
Weak Dynamic typing: Perl5 (no, really, test it, it's scary - worst of both worlds!)
That's why the first thing every Perl programmer should type (ok, after the hash-bang line) is "use strict; use warnings;". (Or s/use warnings;/something else that enables warnings/). The Perl interpreter will happily process your mistakes without blinking if you don't take precautionary measures. For example:
# use strict; # use warnings;
$foo = "bar"; $foo += 3; print $foo, "\n";
If uncommented, the "use strict;" line will cause the interpreter to complain about $foo not being associated with a package (guards against typos). The "use warnings" line will cause the interpreter to print a warning message when it executes $foo += 3 ("Argument "bar" isn't numeric in addition (+) at..."). With both commented out, the interpreter happily executes the code and prints (on my system) "3". I agree that this behavior is horrendous. So remember kids, "use strict" and enable warnings!
char* x, y; - what is y? char *x, y; - ah, now we see what y is.
As a general rule, I don't mix "pointer-to-sometype" variable declarations with "sometype" declarations, because they only save keystrokes at the expense of potential confusion. For the above code, it is probably best to separate the declarations of x and y.
char * x; char y;
I admit that this is a relatively minor issue that doesn't greatly influence the overall readability of code.
The ISA paradigm sees classes as nouns (e.g. an Image IS A collection of pixels.) I think that classes can also be adjectives - so for example I might have a 'Rotatable' class, so then my Image class IS A (collection of pixels) and IS rotatable
class Image : public std::vector, public Rotatable {... };
Try to remember that the container classes provided in the C++ standard library were not designed for use as public base classes. In fact, Stepanov (designer of the STL) does not even like OOP, calling it technically and philosophically unsound. Unfortunately, this code uses inheritance to expose an _implementation detail_ (the usage of std::vector for storing its elements) that it should keep hidden. The std::vector class provides no added benefit to classes that derive from it because it has no virtual member functions and no (standard) protected members. The code, as it stands, is essentially equivalent to
class Image : public Rotatable {
public: std::vector<Something> elems; };
with the difference being that one writes code like a.size() for the first example and a.elems.size() for the second example (not a huge difference, in the grand scheme of things).
You should avoid exposing implementation details, so, at the very least, write a PixelCollection class if you want to expose a pixel collection in a class interface. The PixelCollection class would then _contain_ a private vector to store its elements. That way, you will hide the storage implementation and be able to change it later. At that point, whether or not PixelCollection should be a private member of the class or a public base is another matter that needs to be dealt with...
I'm a bit confused here. Are you seriously suggesting that the addition of a heap-allocated dynamically-resized string type is more important than inheritance?
One of them is a few kilobytes of library code; the other is a fundamental change to the language semantics.
What difference does that make when it comes to importance? I also think that C++'s standard library is a great asset, but I think it's silly to compare apples to oranges. Besides, weren't you the one that felt that inheritance is really just a bunch of function pointer code that should be written by hand?;)
Previously, concerning C++ vs C:Inheritance breaks encapsulation. If I want to pass around function points, I'll pass around function pointers; I'll not have the compiler doing it behind my back.
Now:If you override both CharArray.insert and CharArray.prefix, you'll end up updating Length twice when CharArrayLength.prefix is called; but you have no way of knowing this unless you can see how CharArray.prefix is implemented. Even worse, if someone later changes the implementation of CharArray (for example, to make CharArray.prefix perform the insert itself, instead of calling.insert), it will break your subclass.
It is important to differentiate between the interface of a class and its implementation details. If you examine the implementation of a module and then write code that depends on that implementation, then, from a design perspective, you are committing a programming sin, whether you are using OO methodologies or not.
This whole argument is rather ridiculous, for a few reasons:
a) In C++, member functions can only be overridden if the base class (or a base class of that class, etc) declares the function virtual. Inheritance alone does not allow one to override functions. However, I do admit that inheritance is questionable if the base class has no virtual functions.
b) You do not need to know the implementation details of the base class to override its functions; you only need to understand the interface of that class and its requirements. Even if you disagree with me on that point...
c) The base class can have no implementation at all (like Java interfaces), and that eliminates any gripes about a potential dependency on the implementation of the base. Many people, including myself, prefer this separation of interface and implementation. For example:
class MyInterface {
public: void foo() = 0; };
Now, MyInterface can be viewed like a "function pointer", but its derived class can also contain some data, transparently adding extra functionality to the "function pointer". Now, what's the problem?
Yes, that is true - but, interestingly, the number of lines of code written by a programmer in a day stays roughly constant - regardless of language used - so the more verbose the language, the less your programmer is doing.
The verbosity of the language has little or nothing to do with programmer productivity; it's the libraries that make the difference. Java, for example, tends to be very verbose (mostly because of methodNamesThatGoOnForever), but its large library makes it very easy to write useful applications. I think that your conclusion should read: so the more code that your programmer has to write because it is not already covered by libraries that are readily available to him/her, the less your programmer is doing.
My specific issue has to do with code that looks like this:
class C { public:
C(const string& s = "some string"); };
icc wants code that looks like this:
class C { public:
C(const string& s = string("some string")); };
The only real difference I see between the two is the explicit creation of a temporary. Now, as to why GCC doesn't complain is another issue --- maybe its diagnostics for temporaries aren't turned on with -Wall (perhaps -pedantic fixes that); however, I have this feeling that GCC's constructor elision is the trick here. To be honest, I'm very curious to find out why this happens.
Constructor elision trick? The code
const std::string& s = "some string";
implicitly constructs a temporary std::string and binds it to the reference s. I don't know how the compiler could eliminate the construction of the temporary each time the function is called, unless it compiled it to something like the following:
// C.hpp #include <string> class C {
static const std::string S_DEFAULT; public:
C(const std::string& s = S_DEFAULT); };
You may wish to rewrite your code in this manner because it virtually guarantees that the std::string for the default parameter is constructed once and only once. It also provides an added benefit: if the value of the default changes (from, say, "some string" to "some other string"), then only the C class's translation unit needs to be recompiled.
Since you don't manage your own memory on Java or C#, the concept of buffer overflow doesn't really apply. While the array construct still exists in both languages, you can't overflow an array without going out of bounds.
That first sentence does not make sense. Garbage collection avoids memory leaks; it has nothing to do with buffer overflows.
Don't throw the baby out with the bathwater. All we really need is a "safer" array construct. Unfortunately, programmers still use unsafe constructs in their code, and that can be attributed mostly to inertia.
C++: You can use "+", but you still have to manage the memory. [It's possible to do better if you overload "=" to do reference counting. But if you don't like overloading "+", you really won't like that.]
Vector temp = x+y; Vector w = temp+z; ~temp();
Not only is that invalid C++ code, but you seem to be complaining about a non-existant problem. Your class should look something like this:
int main() {
Vector a(10); Vector::size_type i;
for ( i = 0; i < a.size(); ++i ) a[i] = i;
Vector a2 = a + a;
for ( i = 0; i < a2.size(); ++i ) {
if ( a2[i] != a[i] + a[i] )
std::cerr "a2 is not a + a" std::endl;
}// Note: no cleanup necessary here }
Then it will work when n==0, and continue to have the same behavior for all n > 0 as well. I like strlcpy()'s interface better, though, because the "number" parameter is the number of elements in the destination array, whereas my_strncpy takes one less than the number of elements in that array.
This is an interesting point. I know a good bit of C++, but I don't often code in it. Why? Because I spend twice as much time looking up methods and classes than I do actually coding. Half the time I still later discover that I reinvented the wheel.
I find your comment somewhat ironic, considering that the articles are mostly about Java, whose library dwarfs C++'s. What is your preferred language? C? Or are you suggesting that Java's library is simpler than C++'s?
A large library can be overwhelming, but it is a great tool to have at one's disposal. I learned C++ before I learned Java, and, at first, Java's mammoth library confounded me. These days, I consider it almost indispensible. I felt the same way when I transitioned from C to C++.
Re:Not very well-explained nor convincing
on
Concept Programming
·
· Score: 1
The Maximum example goal is to illustrate how not having the right tool leads to having to workaround. Being more verbose is the problem. If you are more verbose by a factor of 4 on something that simple, what about something more complicated?
Verbosity is not an effective measure of complexity. *cough*Perl*cough*
I am glad you responded and updated your web site, because I feel like I have a better understanding of "Concept Programming". I still don't understand exactly what methodologies are considered "concept-oriented". I understand that, according to "Concept Programming", program code should represent application concepts, but what programming techniques are utilized to achieve that goal? Is it nothing more than a goal? For "Concept Programming", it almost seems like a programmer would have to use a language that supports every possible programming construct with a syntax that is simple and intuitive to the domain. To do this, one would probably require an extensible language. It sounds like extensibility truly is a goal, or at least a requirement to reach your goal.
Re:Not very well-explained nor convincing
on
Concept Programming
·
· Score: 1
Several comments were along these lines. Now a challenge for all you Java experts who discuss my sanity:-) Please give me a good representation of the "Maximum" concept in Java.
The comparator/container approach is probably the best way to implement this "concept". I agree that the Java solution is more verbose than the XL solution, but I am not convinced that this matters much. Java tends to be verbose, but it is still a very easy and readable language.
"Concept Programming", as I understand it, mainly focuses on extensibility. The web site shows a derivation example, where the language has essentially been extended, allowing it to "properly reflect the concept" of derivation in the source code. While the concept of an extensible language is somewhat interesting, I don't think that altering the fundamentals of a language to suit the current problem is a great idea. Doing so makes the common programmer a language designer, and raises issues concerning complexity, maintenance, and readability. Elegance is nice, but it doesn't necessarily help programmers do their job any better.
Re:Not very well-explained nor convincing
on
Concept Programming
·
· Score: 1
The first example discusses the concept of "Maximum", and shows how you would implement that concept in Java, followed by the allegedly superior XL way to do it. The Java "class" makes no sense, and really would not be the way to go about it. YOu would never want to model the concept of Maximum in that way, but if you did, you would use the already-existing Comparable interface and creating a static method called "Max" of some class that takes a list of comparable objects.
I agree that the Java implementation was idiotic at best. One would think that the author was somehow convinced that "maximum", being a noun, would therefore be implemented as its own object in an OO design. Of course, competent OO programmers do not merely select random nouns from sentences to formulate their design, because doing so leads to backwards implementations, as the author has demonstrated. Unfortunately, because the implementation chosen in the Java example was so unrealistic, and the implementation differences are the basis for the comparison, the entire comparison between Concept Programming and OO Programming is worthless.
I find it interesting that the "conceptual" implementation looks suspiciously similar to C++'s std::max_element(). In fact, it almost seems like the comparison is really between Generic Programming and OO Programming. I think that page needs to contain better examples to illustrate its point.
For example, just today I noticed a dangerous situation when I initialized a callback function table with:
somestructtype myfuncs = {myFuncA, myFuncB};
While this works quite nicely, it's secure only if the struct always contains the two items. If a new item is added to the struct, all uses of the structure would have to be updated, but the compiler might not warn about this situation. In this case, the result would probably be a program crash. A more secure way would be:
I don't see how that approach is any better. If you write a pseudo-constructor, then you can avoid the error you mentioned.
somestructtype CreateStruct (
FuncType a,
FuncType2 b ) {
somestructtype ret = {a,b};
return ret; }
Then, adding or removing a parameter from the function will cause compilation errors, assuming that you always use the function to create the struct.
It is rarely appropriate to use memset(). In fact, pointers are not necessarily set to NULL if you memset() them to zero (at least, you cannot assume that it will do so on all platforms).
Some ANSI C code of mine (this is simple stuff -- i've only been working with C on-and-off for a year or so -- I'm a Visual Basic refugee) compiles perfectly with gcc, which isn't surprising since I wrote it for gcc & linux. However, trying to do a Windows port of my program (shameless plug) [sourceforge.net] with only Visual C++ available to me right now is a *real* pain. It compiles, but certain perfectly acceptable C statements get somehow FUBARed, and the program turns out weird numbers. I'm not enough of a Windows programmer to understand what's wrong, sadly. Maybe cygwin...
Welcome to C, where undefined behavior can cause your program to work properly at times and completely screw up at other times. Here are a few problems that I found after about 2 minutes of examination:
main.c, line 97: The arrays aiBoard/humanBoard have BOARD_MAX elements when the rest of the code expects them to have BOARD_MAX + 1 elements. Undefined behavior because the last valid element is at index BOARD_MAX - 1, but the code writes/reads from index BOARD_MAX.
main.c, lines 147, 155: Using scanf("%s"...) to read a single character. Undefined behavior, even if the user enters only one character, because scanf will attempt to null-terminate the "string" and write to memory beyond the character passed.
main.c, line 164: user could overflow human_name by entering a name that is longer than 99 characters (nitpick comment).
Don't blame Visual C++. The code has some serious flaws, and just happens to behave as expected in gcc under linux.
Uh, they DIED when they expired. Probably not a good thing to let your web server die over a long holiday weekend.
Interesting analogy, eh?
Slashdotter A: Apparently there's this idea that software should expire, kinda like coupons. Slashdotter B: Huh? Slashdotter A: You know, like a driver's license. You have to get a new one after a certain amount of time. Slashdotter B:... Slashdotter A: Hmmm... like Bladerunner's replicants? Slashdotter B: Oooohhhh...
Re:Valgrind and memory leaks
on
KDE 3.0 is Out
·
· Score: 3, Informative
Both of the concepts you mentioned are implemented in boost's library (http://www.boost.org). Actually, std::auto_ptr is implemented in the C++ standard library, but boost has many different pointer types, including reference-counted pointers, weak-referenced pointers, and plain-jane scoped pointers. The library is robust and easy to use, and I highly recommend it.
1) You have to code in this one window that seems to have the problem pinned to the top of it. In a Java applet. With a half assed vi. I'd want to be able to code the thing in vim (or editor of choice), in multiple windows. I know as a programmer I am attached to the way I code (and really attached to regex searches and s/xxx/yyy in vi) and wouldn't want to code on a time limit in an awkward environment.
I participate in TopCoder contests (and do rather poorly these days, but oh well). You don't have to use the java applet if you don't want to. I always write the code in an IDE and then paste the results into the applet, so I can program in the environment that I'm accustomed to.
2) It says if you use C++, you are restricted to using C++ strings (null terminated char * I guess?) which is cool, but vectors must be STL Vectors. Why not let you do what ever you want (i.e. vectors are just arrays)
If you don't want to use STL containers in your code, you don't have to, except for the arguments they pass in. The containers (such as std::string, not character arrays, and std::vectors) make the interface for the class much simpler, so you don't have any extra parameters like the length of the array, etc. I prefer it this way, since STL containers aren't as error-prone as their C equivalents.
3) It seems like it gives you the classes/methods you should use. I see this makes judging it simpler, but it seems sort of like CS 101 projects on a time limit. I don't like coding into someone elses architecture, or worrying about using classes well when I am doing a quick and dirty solution and just want to hack out some procedural stuff.
They don't force you to do much. They tell you to write a class that has a single member function that does X. The class isn't really necessary at all (I think it's because Java requires classes, so they just make the C++ programmers write one as well for constistency). The approach can be procedural, and most often is. The only classes that you are required to use are the ones that are passed in as arguments (if any), which are standard library classes.
This contest seems to concentrate more on the coding than the problem solving. (Hence the name TopCoder I guess).
Not really. The problems generally require some thought, and the harder ones usually require knowledge of algorithms. They really force you to think when they pose a problem that has a very large "N", since the execution time must be under six seconds on their server.
It's pretty fun. It takes a couple of hours, they hold competitions biweekly (usually), and you get money if you win. I highly recommend participating, as long as you don't end up competing against me;-)
(Joel) It's not true for the software that I've written, because I tend to refactor and clean things up regularly. Half the time when I go into a function to fix a little bug, I figure out a cleaner way to rewrite the whole function, so over time it gets better and better. (End Joel)
In other words, his code decays MUCH faster than anyone elses. Glad he doesn't work for me. At "half the time", that means he's costing any project 50% more in his time/dollar worth. Ouch!
"Half the time" is probably an estimate, and I'm pretty sure that he is not saying that half of his time is spent improving old functions. He is saying that he often finds himself cleaning up older code by refactoring it. And I seriously doubt that the time is wasted, as your cost analysis seems to assume.
(Joel) Don't even talk to me about spending money replacing something that works. (End Joel)
No, he doesn't replace an application at one time, it does it over a period of time, one function at a time. LOL!
He is arguing against complete rewrites, and favors refactoring the code as it is being updated. Is there something wrong with this? I don't see anything in there worth laughing about.
Slashdot Mirror
Is a certain percentage of bugs that result from the interaction of two or more otherwise bug free components?
If two components interact and the resulting behavior is buggy, then I would say that one of the components must have had bugs that were not readily apparent before. Perhaps the specs for the interfaces of the components were incorrect or incomplete, but that's still a bug.
To take a ridiculous example, someone I know was instructed to develop an application that parsed and interpreted a subset of Java at runtime for certain aspects of program logic. When he pointed out that it would be easier and more reliable to dynamically load real .class files, he was told that that was no good as the class files would be "executables" and therefore need a formal software change notice, but the slapped-together interpreter would be reading "config files" which could be changed more easily. The manager in charge of the project, of course, was several layers below the managers that dictated the procedures, and found it easier to design round the restrictions than to change them.
I know that situation sounds absurd, but I work for a large defense firm, and I have heard of very similar situations. I've even heard of some projects where scripts written in bona fide interpreted languages (e.g. Perl) were classified as data instead of code because it made dealing with the processes of managing them simpler. The "embedded Java interpreter" is an interesting extension to this idea. I suppose one could always go to the extreme and ship any given product with a C compiler, eh? Ah, the crazy things to which bureaucracy and excessive process can drive you...
"The Kodak EasyShare LS633 zoom digital camera is designed for photographers who want to capture and share photos while enjoying the benefits of advanced technology."
Criminy, who writes this crap -- Kodak's marketing division?
Well, they are beating around the bush, but I think that they are trying to say that the camera provides a robust, enterprise-ready turn-key camera implementation for advanced photographers, which enables them to rapidly develop and deploy high-quality, customer-oriented photographic solutions to their clients.
Or something.
Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?
I used to work with an older fellow who developed software long before I was born. He would complain that decomposing subroutines into smaller, bite-sized subroutines made the program logic harder to follow. He was used to having very long subroutines that performed complicated tasks. He liked to read functions from start to finish and thought that jumping from subroutine to "utility" subroutine and back again was confusing. At the time, I thought that his complaint was ludicrous, mostly because I was so used to having smaller functions that made the high-level logic simpler. To understand decomposed code, instead of thinking in terms of lines of code (execute line 1, then 2, then 3, then 4... then N etc) and understanding each simple line as it appeared in the program, one should think in terms of larger code blocks (execute a simple utility function whose responsibilities I understand, then line 2, then another simple utility function whose responsibilities I understand, etc).
Your complaint about OO programming sounds somewhat similar. Yes, it is true that dynamically bound functions make the program's flow nonlinear, but when the interface to a method or class is well-defined, this isn't a problem. If method A's responsibilities are clearly documented, then it should not matter whether method A is dynamically bound or not. Instead of thinking (for example) "after code block X, execute code block Y", one should think "after performing some operation X whose interface is defined in this way, perform some operation Y whose interface is defined in that way".
That being said, I do not understand the benefit of aspects. I have read all of the examples, but I have not been able to change my way of looking at software so that I may understand how aspects can improve development. I'm still stuck asking myself "what's the point?".
That's why the first thing every Perl programmer should type (ok, after the hash-bang line) is "use strict; use warnings;". (Or s/use warnings;/something else that enables warnings/). The Perl interpreter will happily process your mistakes without blinking if you don't take precautionary measures. For example:If uncommented, the "use strict;" line will cause the interpreter to complain about $foo not being associated with a package (guards against typos). The "use warnings" line will cause the interpreter to print a warning message when it executes $foo += 3 ("Argument "bar" isn't numeric in addition (+) at..."). With both commented out, the interpreter happily executes the code and prints (on my system) "3". I agree that this behavior is horrendous. So remember kids, "use strict" and enable warnings!
I can't wait! Next thing I want:
System.out.println("YES!") if (a==b);
if (that==pointless) System.out.println("forget it");
This always annoys me...
char* x, y; - what is y?
char *x, y; - ah, now we see what y is.
As a general rule, I don't mix "pointer-to-sometype" variable declarations with "sometype" declarations, because they only save keystrokes at the expense of potential confusion. For the above code, it is probably best to separate the declarations of x and y.
char * x;
char y;
I admit that this is a relatively minor issue that doesn't greatly influence the overall readability of code.
The ISA paradigm sees classes as nouns (e.g. an Image IS A collection of pixels.) I think that classes can also be adjectives - so for example I might have a 'Rotatable' class, so then my Image class IS A (collection of pixels) and IS rotatable
...
class Image : public std::vector, public Rotatable
{
};
Try to remember that the container classes provided in the C++ standard library were not designed for use as public base classes. In fact, Stepanov (designer of the STL) does not even like OOP, calling it technically and philosophically unsound. Unfortunately, this code uses inheritance to expose an _implementation detail_ (the usage of std::vector for storing its elements) that it should keep hidden. The std::vector class provides no added benefit to classes that derive from it because it has no virtual member functions and no (standard) protected members. The code, as it stands, is essentially equivalent to
class Image : public Rotatable {
public: std::vector<Something> elems;
};
with the difference being that one writes code like a.size() for the first example and a.elems.size() for the second example (not a huge difference, in the grand scheme of things).
You should avoid exposing implementation details, so, at the very least, write a PixelCollection class if you want to expose a pixel collection in a class interface. The PixelCollection class would then _contain_ a private vector to store its elements. That way, you will hide the storage implementation and be able to change it later. At that point, whether or not PixelCollection should be a private member of the class or a public base is another matter that needs to be dealt with...
I'm a bit confused here. Are you seriously suggesting that the addition of a heap-allocated dynamically-resized string type is more important than inheritance?
;)
One of them is a few kilobytes of library code; the other is a fundamental change to the language semantics.
What difference does that make when it comes to importance? I also think that C++'s standard library is a great asset, but I think it's silly to compare apples to oranges. Besides, weren't you the one that felt that inheritance is really just a bunch of function pointer code that should be written by hand?
Previously, concerning C++ vs C: Inheritance breaks encapsulation. If I want to pass around function points, I'll pass around function pointers; I'll not have the compiler doing it behind my back.
.insert), it will break your subclass.
Now: If you override both CharArray.insert and CharArray.prefix, you'll end up updating Length twice when CharArrayLength.prefix is called; but you have no way of knowing this unless you can see how CharArray.prefix is implemented. Even worse, if someone later changes the implementation of CharArray (for example, to make CharArray.prefix perform the insert itself, instead of calling
It is important to differentiate between the interface of a class and its implementation details. If you examine the implementation of a module and then write code that depends on that implementation, then, from a design perspective, you are committing a programming sin, whether you are using OO methodologies or not.
This whole argument is rather ridiculous, for a few reasons:
a) In C++, member functions can only be overridden if the base class (or a base class of that class, etc) declares the function virtual. Inheritance alone does not allow one to override functions. However, I do admit that inheritance is questionable if the base class has no virtual functions.
b) You do not need to know the implementation details of the base class to override its functions; you only need to understand the interface of that class and its requirements. Even if you disagree with me on that point...
c) The base class can have no implementation at all (like Java interfaces), and that eliminates any gripes about a potential dependency on the implementation of the base. Many people, including myself, prefer this separation of interface and implementation. For example:
class MyInterface {
public: void foo() = 0;
};
Now, MyInterface can be viewed like a "function pointer", but its derived class can also contain some data, transparently adding extra functionality to the "function pointer". Now, what's the problem?
Yes, that is true - but, interestingly, the number of lines of code written by a programmer in a day stays roughly constant - regardless of language used - so the more verbose the language, the less your programmer is doing.
The verbosity of the language has little or nothing to do with programmer productivity; it's the libraries that make the difference. Java, for example, tends to be very verbose (mostly because of methodNamesThatGoOnForever), but its large library makes it very easy to write useful applications. I think that your conclusion should read: so the more code that your programmer has to write because it is not already covered by libraries that are readily available to him/her, the less your programmer is doing.
My specific issue has to do with code that looks like this:
// C.hpp
// C.cpp
class C {
public:
C(const string& s = "some string");
};
icc wants code that looks like this:
class C {
public:
C(const string& s = string("some string"));
};
The only real difference I see between the two is the explicit creation of a temporary. Now, as to why GCC doesn't complain is another issue --- maybe its diagnostics for temporaries aren't turned on with -Wall (perhaps -pedantic fixes that); however, I have this feeling that GCC's constructor elision is the trick here. To be honest, I'm very curious to find out why this happens.
Constructor elision trick? The code
const std::string& s = "some string";
implicitly constructs a temporary std::string and binds it to the reference s. I don't know how the compiler could eliminate the construction of the temporary each time the function is called, unless it compiled it to something like the following:
#include <string>
class C {
static const std::string S_DEFAULT;
public:
C(const std::string& s = S_DEFAULT);
};
#include "C.hpp"
#include <iostream>
const std::string C::S_DEFAULT("some string");
C::C(const std::string& s) {
std::cout << "C::C() called with: " << s << std::endl;
}
You may wish to rewrite your code in this manner because it virtually guarantees that the std::string for the default parameter is constructed once and only once. It also provides an added benefit: if the value of the default changes (from, say, "some string" to "some other string"), then only the C class's translation unit needs to be recompiled.
Since you don't manage your own memory on Java or C#, the concept of buffer overflow doesn't really apply. While the array construct still exists in both languages, you can't overflow an array without going out of bounds.
That first sentence does not make sense. Garbage collection avoids memory leaks; it has nothing to do with buffer overflows.
Don't throw the baby out with the bathwater. All we really need is a "safer" array construct. Unfortunately, programmers still use unsafe constructs in their code, and that can be attributed mostly to inertia.
C++: You can use "+", but you still have to manage the memory. [It's possible to do better if you overload "=" to do reference counting. But if you don't like overloading "+", you really won't like that.]
// Note: no cleanup necessary here
Vector temp = x+y;
Vector w = temp+z;
~temp();
Not only is that invalid C++ code, but you seem to be complaining about a non-existant problem. Your class should look something like this:
#include <stddef.h>
#include <assert.h>
#include <algorithm>
#include <iostream>
class Vector {
double * d_; size_t nElems_;
public:
typedef size_t size_type;
Vector( size_type n ) : d_(new double[n]), nElems_(n)
{ std::fill_n( d_, n, 0.0 ); }
Vector( const Vector& v ) : d_(new double[v.nElems_]), nElems_(v.nElems_)
{ std::copy( v.d_+0, v.d_+nElems_, d_ ); }
double& operator[]( size_type i )
{ assert( i < nElems_ ); return d_[i]; }
Vector& operator=( const Vector& v ) {
if( v.nElems_ > nElems_ ) {
double * tmp = new double[v.nElems_]; delete[] d_; d_ = tmp;
}
nElems_ = v.nElems_;
std::copy( v.d_+0, v.d_+nElems_, d_ );
return *this;
}
Vector& operator+=( const Vector& v ) {
assert( v.nElems_ == nElems_ );
for( size_type i = 0; i < nElems_; ++i ) d_[i] += v.d_[i];
return *this;
}
size_type size() const { return nElems_; }
~Vector() { delete[] d_; }
};
Vector operator+( const Vector& lhs, const Vector& rhs )
{ Vector tmp(lhs); tmp += rhs; return tmp; }
int main() {
Vector a(10); Vector::size_type i;
for ( i = 0; i < a.size(); ++i ) a[i] = i;
Vector a2 = a + a;
for ( i = 0; i < a2.size(); ++i ) {
if ( a2[i] != a[i] + a[i] )
std::cerr "a2 is not a + a" std::endl;
}
}
void my_strncpy(char *s, const char *t, int n){ while((*s++ = *t++) && --n) ; *s = '\0'; }
If written
void my_strncpy(char *s, const char *t, int n){ while(n-- && (*s++ = *t++)) ; *s = '\0'; }
Then it will work when n==0, and continue to have the same behavior for all n > 0 as well. I like strlcpy()'s interface better, though, because the "number" parameter is the number of elements in the destination array, whereas my_strncpy takes one less than the number of elements in that array.
This is an interesting point. I know a good bit of C++, but I don't often code in it. Why? Because I spend twice as much time looking up methods and classes than I do actually coding. Half the time I still later discover that I reinvented the wheel.
I find your comment somewhat ironic, considering that the articles are mostly about Java, whose library dwarfs C++'s. What is your preferred language? C? Or are you suggesting that Java's library is simpler than C++'s?
A large library can be overwhelming, but it is a great tool to have at one's disposal. I learned C++ before I learned Java, and, at first, Java's mammoth library confounded me. These days, I consider it almost indispensible. I felt the same way when I transitioned from C to C++.
The Maximum example goal is to illustrate how not having the right tool leads to having to workaround. Being more verbose is the problem. If you are more verbose by a factor of 4 on something that simple, what about something more complicated?
Verbosity is not an effective measure of complexity. *cough*Perl*cough*
I am glad you responded and updated your web site, because I feel like I have a better understanding of "Concept Programming". I still don't understand exactly what methodologies are considered "concept-oriented". I understand that, according to "Concept Programming", program code should represent application concepts, but what programming techniques are utilized to achieve that goal? Is it nothing more than a goal? For "Concept Programming", it almost seems like a programmer would have to use a language that supports every possible programming construct with a syntax that is simple and intuitive to the domain. To do this, one would probably require an extensible language. It sounds like extensibility truly is a goal, or at least a requirement to reach your goal.
Several comments were along these lines. Now a challenge for all you Java experts who discuss my sanity :-) Please give me a good representation of the "Maximum" concept in Java.
The comparator/container approach is probably the best way to implement this "concept". I agree that the Java solution is more verbose than the XL solution, but I am not convinced that this matters much. Java tends to be verbose, but it is still a very easy and readable language.
"Concept Programming", as I understand it, mainly focuses on extensibility. The web site shows a derivation example, where the language has essentially been extended, allowing it to "properly reflect the concept" of derivation in the source code. While the concept of an extensible language is somewhat interesting, I don't think that altering the fundamentals of a language to suit the current problem is a great idea. Doing so makes the common programmer a language designer, and raises issues concerning complexity, maintenance, and readability. Elegance is nice, but it doesn't necessarily help programmers do their job any better.
The first example discusses the concept of "Maximum", and shows how you would implement that concept in Java, followed by the allegedly superior XL way to do it. The Java "class" makes no sense, and really would not be the way to go about it. YOu would never want to model the concept of Maximum in that way, but if you did, you would use the already-existing Comparable interface and creating a static method called "Max" of some class that takes a list of comparable objects.
I agree that the Java implementation was idiotic at best. One would think that the author was somehow convinced that "maximum", being a noun, would therefore be implemented as its own object in an OO design. Of course, competent OO programmers do not merely select random nouns from sentences to formulate their design, because doing so leads to backwards implementations, as the author has demonstrated. Unfortunately, because the implementation chosen in the Java example was so unrealistic, and the implementation differences are the basis for the comparison, the entire comparison between Concept Programming and OO Programming is worthless.
I find it interesting that the "conceptual" implementation looks suspiciously similar to C++'s std::max_element(). In fact, it almost seems like the comparison is really between Generic Programming and OO Programming. I think that page needs to contain better examples to illustrate its point.
For example, just today I noticed a dangerous situation when I initialized a callback function table with:
somestructtype myfuncs = {myFuncA, myFuncB};
While this works quite nicely, it's secure only if the struct always contains the two items. If a new item is added to the struct, all uses of the structure would have to be updated, but the compiler might not warn about this situation. In this case, the result would probably be a program crash. A more secure way would be:
somestructtype myfuncs;
memset (&myfuncs, 0, sizeof (myfuncs));
myfuncs->func1 = myFuncA;
myfuncs->func2 = myFuncB;
This is much safer.
I don't see how that approach is any better. If you write a pseudo-constructor, then you can avoid the error you mentioned.
somestructtype CreateStruct
(
FuncType a,
FuncType2 b
)
{
somestructtype ret = {a,b};
return ret;
}
Then, adding or removing a parameter from the function will cause compilation errors, assuming that you always use the function to create the struct.
It is rarely appropriate to use memset(). In fact, pointers are not necessarily set to NULL if you memset() them to zero (at least, you cannot assume that it will do so on all platforms).
Some ANSI C code of mine (this is simple stuff -- i've only been working with C on-and-off for a year or so -- I'm a Visual Basic refugee) compiles perfectly with gcc, which isn't surprising since I wrote it for gcc & linux. However, trying to do a Windows port of my program (shameless plug) [sourceforge.net] with only Visual C++ available to me right now is a *real* pain. It compiles, but certain perfectly acceptable C statements get somehow FUBARed, and the program turns out weird numbers. I'm not enough of a Windows programmer to understand what's wrong, sadly. Maybe cygwin...
Welcome to C, where undefined behavior can cause your program to work properly at times and completely screw up at other times. Here are a few problems that I found after about 2 minutes of examination:
main.c, line 97:
The arrays aiBoard/humanBoard have BOARD_MAX elements when the rest of the code expects them to have BOARD_MAX + 1 elements. Undefined behavior because the last valid element is at index BOARD_MAX - 1, but the code writes/reads from index BOARD_MAX.
main.c, lines 147, 155:
Using scanf("%s"...) to read a single character. Undefined behavior, even if the user enters only one character, because scanf will attempt to null-terminate the "string" and write to memory beyond the character passed.
main.c, line 164:
user could overflow human_name by entering a name that is longer than 99 characters (nitpick comment).
Don't blame Visual C++. The code has some serious flaws, and just happens to behave as expected in gcc under linux.
Uh, they DIED when they expired. Probably not a good thing to let your web server die over a long holiday weekend.
...
Interesting analogy, eh?
Slashdotter A: Apparently there's this idea that software should expire, kinda like coupons.
Slashdotter B: Huh?
Slashdotter A: You know, like a driver's license. You have to get a new one after a certain amount of time.
Slashdotter B:
Slashdotter A: Hmmm... like Bladerunner's replicants?
Slashdotter B: Oooohhhh...
Both of the concepts you mentioned are implemented in boost's library (http://www.boost.org). Actually, std::auto_ptr is implemented in the C++ standard library, but boost has many different pointer types, including reference-counted pointers, weak-referenced pointers, and plain-jane scoped pointers. The library is robust and easy to use, and I highly recommend it.
1) You have to code in this one window that seems to have the problem pinned to the top of it. In a Java applet. With a half assed vi. I'd want to be able to code the thing in vim (or editor of choice), in multiple windows. I know as a programmer I am attached to the way I code (and really attached to regex searches and s/xxx/yyy in vi) and wouldn't want to code on a time limit in an awkward environment.
;-)
I participate in TopCoder contests (and do rather poorly these days, but oh well). You don't have to use the java applet if you don't want to. I always write the code in an IDE and then paste the results into the applet, so I can program in the environment that I'm accustomed to.
2) It says if you use C++, you are restricted to using C++ strings (null terminated char * I guess?) which is cool, but vectors must be STL Vectors. Why not let you do what ever you want (i.e. vectors are just arrays)
If you don't want to use STL containers in your code, you don't have to, except for the arguments they pass in. The containers (such as std::string, not character arrays, and std::vectors) make the interface for the class much simpler, so you don't have any extra parameters like the length of the array, etc. I prefer it this way, since STL containers aren't as error-prone as their C equivalents.
3) It seems like it gives you the classes/methods you should use. I see this makes judging it simpler, but it seems sort of like CS 101 projects on a time limit. I don't like coding into someone elses architecture, or worrying about using classes well when I am doing a quick and dirty solution and just want to hack out some procedural stuff.
They don't force you to do much. They tell you to write a class that has a single member function that does X. The class isn't really necessary at all (I think it's because Java requires classes, so they just make the C++ programmers write one as well for constistency). The approach can be procedural, and most often is. The only classes that you are required to use are the ones that are passed in as arguments (if any), which are standard library classes.
This contest seems to concentrate more on the coding than the problem solving. (Hence the name TopCoder I guess).
Not really. The problems generally require some thought, and the harder ones usually require knowledge of algorithms. They really force you to think when they pose a problem that has a very large "N", since the execution time must be under six seconds on their server.
It's pretty fun. It takes a couple of hours, they hold competitions biweekly (usually), and you get money if you win. I highly recommend participating, as long as you don't end up competing against me
(Joel)
It's not true for the software that I've written, because I tend to refactor and clean things up regularly. Half the time when I go into a function to fix a little bug, I figure out a cleaner way to rewrite the whole function, so over time it gets better and better.
(End Joel)
In other words, his code decays MUCH faster than anyone elses. Glad he doesn't work for me. At "half the time", that means he's costing any project 50% more in his time/dollar worth. Ouch!
"Half the time" is probably an estimate, and I'm pretty sure that he is not saying that half of his time is spent improving old functions. He is saying that he often finds himself cleaning up older code by refactoring it. And I seriously doubt that the time is wasted, as your cost analysis seems to assume.
(Joel)
Don't even talk to me about spending money replacing something that works.
(End Joel)
No, he doesn't replace an application at one time, it does it over a period of time, one function at a time. LOL!
He is arguing against complete rewrites, and favors refactoring the code as it is being updated. Is there something wrong with this? I don't see anything in there worth laughing about.