www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++ traps that D2 doesn't avoid yet?

reply bearophile <bearophileHUGS lycos.com> writes:
This page lists a lot of C++ traps and pitfalls in a short space. I assume D
has to avoid or render meaningless a quite high percentage of them.
I'd like to list what of them D2 doesn't improve/fix yet, but my limited
knowledge of C++ lets me understand only a certain percentage of such list of
items (probably less than 75%) so probably I am not qualified yet to compare
that with the D situation. Later I may try to write such differential list
anyway...

http://www.johndeacon.net/Cpp/trapsAndPitfalls.asp

The nice thing of that list is that I think most (maybe 80-90%) of those traps
and pitfalls (and several others that aren't listed, like allowing simple
syntactical mistakes like putting a & where a && was requires or vice versa,
etc) can be avoided by a language like D with little or no penalty in running
space and time (and actually D avoids several of them already), but to avoid
some of them you have to pay the price of sometimes having to step away from
C/Java syntax, or probably worse having to assign a different semantics to some
C syntaxes (Walter has explained that this is sometimes dangerous because most
programmers know C/C++/Java and not D, but seeing the huge troubles C++ has
gone to be as much compatible as possible with C I'd say that keeping the
original C semantics when it is known to cause troubles is _always_ bad. In
such situations I prefer a language that acts correctly than one that acts
badly just to be like C, and maybe I don't even like a language that doesn't
use some handy C syntax just because the semantics is now different).

Bye,
bearophile
Nov 05 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 or
 probably worse having to assign a different semantics to some C
 syntaxes (Walter has explained that this is sometimes dangerous
 because most programmers know C/C++/Java and not D, but seeing the
 huge troubles C++ has gone to be as much compatible as possible with
 C I'd say that keeping the original C semantics when it is known to
 cause troubles is _always_ bad. In such situations I prefer a
 language that acts correctly than one that acts badly just to be like
 C, and maybe I don't even like a language that doesn't use some handy
 C syntax just because the semantics is now different).
The trouble with this is when translating code. For example, take the md5 algorithm which is published in C, and translate it to D. It has some fairly complex arithmetic expressions in them. Do you know how they work? I don't. I have no idea. I doubt hardly anyone interested in translating them does. This means that if the meaning of an expression *silently* is altered by transliterating them to D, the new md5.d will give wrong results and it will be very difficult for the programmer to figure out where the problem is. This is why when D changes the semantics, it tries to restrict itself to changes that will produce compile time errors if the C is not transliterated correctly. For example, the C-style cast gives an error when it appears in D code, which prompts the user that some changes are necessary.
Nov 05 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 This page lists a lot of C++ traps and pitfalls in a short space. I
 assume D has to avoid or render meaningless a quite high percentage
 of them. I'd like to list what of them D2 doesn't improve/fix yet,
 but my limited knowledge of C++ lets me understand only a certain
 percentage of such list of items (probably less than 75%) so probably
 I am not qualified yet to compare that with the D situation. Later I
 may try to write such differential list anyway...
 
 http://www.johndeacon.net/Cpp/trapsAndPitfalls.asp
At a glance, D does resolve a lot of them. But preparing a detailed response to his list is many hours of work.
Nov 05 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 At a glance, D does resolve a lot of them. But preparing a detailed 
 response to his list is many hours of work.
I have removed the most obvious ones and cleaned up the list a little: 1) C++ is officially based on C. C features like name hiding can interfere with C++ features like function overriding. 2) Function name overloading is convenient and good when appropriate; but confusing if misused. Be careful that overloading and name hiding don't interfere. 3) Primitive operands, arguments and returns get converted to their operators' and functions' expectations. 4) The presence of templates means that class member declarations involving a pointer to a template parameter might be interpreted as multiplication if you don't disambiguate with "typename". 5) Because the default for both objects and primitives is to pass to and from functions by copy, copy constructors are called more often than one might first imagine. 6) The special functions will be used more than a sub-guru C++er would imagine. C++ makes copies and temporaries under several circumstances. Special functions have even more reason than usual to avoid side-effects and to be very careful about throwing. (And never throw from a destructor.) 7) C++ doesn't take the attitude that incorrect primitive operand or argument types should be compile errors; it assumes you meant what you wrote and want the operands and arguments to be converted. 8) Although you can start an identifier with an underscore, you shouldn't. Leading underscores are added to identifiers by C++ translators. 9) You might find bizarre things happening if you have an identifier like bitor or compl. They are alternative keyword forms of | and ~. 10) Tidying up columns of numbers with leading zeroes turns them into octal (base 8) numbers. 11) It's not an error to have two character symbols within the single quote marks of a char literal (constant). 12) The encodings for char and wchar_t are not defined. Don't assume ASCII or Unicode. 13) Literal floating-point values (constants) do not have type float; they have type double. 14) Dividing by zero doesn't result in an exception. It results in undefined behavior. You must check your divisors yourself. 15) Because assignment expressions are expressions and evaluate to values, and because values can frequently be converted to bool, accidentally using assignment where you meant comparison will almost always compile and fail silently at run-time 16) The order in which operands are evaluated is not defined. The fact that, for example, addition is defined to be left-associative, doesn't necessarily mean that the operands of the addition operator are evaluated from the left. 17) The operands of logical and and logical or are evaluated from the left; however, there is a new uncertainty: not all the operands need be evaluated at all. 18) Variables can hold values or pointers; and this applies to objects of class type as well as primitives. Be careful you don't assign to a pointer thinking it's a value, or vice-versa. Consider "Hungarian naming". 19) Under assignment, when a pointer to an object is assigned another pointer to an object, they end up pointing at the same object. However, if an object-holding variable (or a reference to an object) is assigned another object, it becomes some kind of copy. 20) The increment (but not the decrement) operator can be applied to bool! It will set it to true whatever it was. 21) The precedence order of some operators including the assignment operators and the conditional (arithmetic if) was changed in ISO C++. 22) Whether you use curly brackets or not, selection and iteration statements control blocks. And the block begins at the opening parenthesis, not at the opening curly bracket (if there is one). 23) Selection and iteration statements should be controlled by boolean expressions, but it is not a compile error to put in numeric expression. 24) Although the (somewhat redundant) parentheses that hold the control logic are mandatory, curly brackets are not. Don't leave traps for maintenance programmers always put the curly brackets in. 25) The = symbol is actually the assignment operator, so it's all too easy to say "if I can assign b to a" rather than "if a is equal to b". In C++, because numeric results can be converted to bool, such mistakes usually compiles, to fail silently later. 26) If you don't put the curly brackets into an "if", it will be difficult to tell which "if" an "else" belongs to, if the "if" is, or ever becomes, nested. 27) The switch statement is really a slightly-tarted-up goto. This hints that maybe the switch should be avoided. 28) The switch statement involves just one block. The sections within are demarcated only with statement labels. You will need break statements after each (including the last for maintainers) section. 29) Accidentally drop one of the colons (:s) of a scope resolution operator, and you might just end up with a labeled statement. 30) A switch gets exponentially more difficult to maintain. One new type to be handled can involve updating many, many switch statements. Contrast this with adding a new class behind a polymorphic type. Prefer object-orientation over switches. 31) Many, many examples of the for statement have i++ to increment the loop counter. If i is an int, it's not really significant, but there's always a chance that it might become an iterator, and then ++i is more efficient and here does just the same as i++. 32) A C++ compiler isn't required to report an error if a value-returning function has no return statement. 33) (-PI <= theta <= PI) is always true, because the first comparison results in true or false which then convert to 0 or 1 which are both less than PI. In languages that don't convert boolean the expression is thankfully a compile error. 34) This is almost an anti-trap since consts are nearly always good. However, if you forget to make your query-only member functions const, then const objects of your class won't be able to accomplish much. 35) Applying delete to a pointer doesn't set it to zero; but you should probably consider doing so. 36) Incorrectly accessing an array of arrays (when simulating a multi-dimensional array) as arr[i, j] instead of arr[i][j] is not a compile error even though it won't do what you probably expect. 37) References create aliases for identifiers. Be careful not to end up doing daft things like self-assignment. Self assignment might go horribly wrong for classes with badly-written copy assignment operators. 38) Do not return via references unless you are absolutely sure that you know exactly what you are doing. (And make sure you know if and how your compiler supports the return value optimization.) 39) Don't try to be tidy by including empty parentheses when initializing object in variables via the default constructor. You will actually declaring parameterless functions instead. 40) Don't think of public as meaning the same for data and function members. Public data members can be accessed; but public member functions can't be called. Public member functions define the signatures of messages that all other objects can send. 41) Unlike, say, Smalltalk, C++ has class-level encapsulation. An object isn't prevented from accessing the private data members of another instance of its class. Apart from the copy constructor and the copy assignment operator, don't allow one instance to access the data of another instance. 42) C++ doesn't enforce the private access category for data members. One day you'll be tempted to make a data member of a base class protected. Resist. Don't do it. From that moment on, the base class becomes unmaintainable. 43) Object instance arguments are passed by value, i.e. by copying. But forget to provide the copy constructor and one will be provided for you. And Finagle's Law says that anytime you do forget, the implicit copy constructor's behavior won't be right. 44) Forgotten parentheses on an argumentless message or call will often compile because a function's address is a valid numeric expression. 45) Const objects can change. While passing out a pointer (or reference) to a data member is hardly a subtle trap, data members can be declared mutable however; so we hope that such data member have been designed to be undetectable from outside their object. 46) Static data members are close to global. Static member function uses are close to calls (rather than messages). Overusing static members takes one away from object-orientation and towards the less useful class-orientation. 47) Never mix up the two initialization syntax schemes of "=" and "()". Try to always use ()-style initialization. Never, ever allow the initialization of an object of class type to involve = and () at the same time. 48) The C memory mechanisms malloc and free still exist in C++, of course. It's not a compile mistake to free() something newed or to delete something malloc()ed; just lethal. 49) It's not a compile error to "delete" (rather than "delete[]") something that was "new []"ed. It's almost certainly a memory problem though. 50) To realize how quickly it could become impossible to decide who takes out the garbage, one only has to recall that the default argument passing and return mechanisms are by-copy; and that the implicit copy constructor does shallow copy. 51) Looking for smart pointers to help with garbage collection and with polymorphic collections, one turns to the library. But the smart pointer one finds there auto_ptr mustn't be used for either of those purposes. 52) Don't pass an auto_ptr to a function by value. The auto_ptr will be copied and the copy will become the owner When the function finishes, the local copied auto_ptr goes out of scope and it will delete what it was pointing at. 53) Almost uniquely among languages today, C++ allows one to store entire objects in variables. This leads to no end of complications; and certainly leads to the special functions being special. 54) A class without constructors may well have implicit constructors. There are only two circumstance when an implicit copy constructor wouldn't be provided; and only a few more where a default constructor wouldn't. And the implicit ones are public. 55) People sometimes try to call one constructor from another. Don't. You can write something that looks like it might just be a call to a constructor but it won't be. Constructors are always declaration statement stuff rather than expression statement stuff. 56) A one-argument constructor will be implicitly used as a conversion function (argument type to class type) unless you say not to with the "explicit" keyword. And constructors with default parameter values might be also be considered single-argument. 57) Another reason not to use the = sign in declaration/initialization is to avoid encouraging the mistaken belief that the copy assignment operator would be used. It wouldn't be. The copy constructor will be used for both = style and () style initialization. 58) The implicit copy constructor effectively does shallow copy it copies pointers but not pointees. 59) Lulled into complacency by constructor chaining, you might imagine that the copy assignment operator automatically chains as well. It doesn't. You will probably want to though. 60) Data members holding objects of class type are default constructed before the constructor's code block runs. Initialize them via the member initialization list instead. 61) If you initialize an object of class type via {} expression lists, almost any change to the class will invalidate such an initialization. 62) The order of initializers in a member initialization list is irrelevant. Don't try, in a member intiailzation list, to initialize one member in terms of another unless you know the initialization order rules. 63) Although destructors can be called explicitly, it is an exotic and probably dangerous thing to do. Be happy with automatic calling of destructors. 64) The implicit destructor is non-polymorphic (non-virtual). Just about everyone, just about all the time must consider whether their destructor should be polymorphic (virtual); and probably conclude that it should be. 65) You might not think you need a destructor, but unless you can prove that your class could never be a base class, you should provide a virtual (not pure virtual) destructor, even it is has an empty code block. 66) Remember that neither the number of arguments nor their position contribute to the "name" of a member function. So an overload of unary +, say, in a derived class would hide a binary + in a base class. 67) Operator overloads are inherited but the implicit copy assignment operator usually hides any base class copy assignment operator. 68) You can't make && or || (or ,) operator overloads work intuitively, so don't provide them. (You can't mimic guaranteed operator evaluation order or lazy evaluation with member functions.) 69) You might be tempted to provide operator bool in order that your objects can easily be tested for validity. But beware that once your objects can be converted to bool, they can also be converted to int. 70) [Well known but] Not only is int converted to long, for example, but long is converted to int, and float is even converted to int. If you're lucky, a friendly compiler will issue a warning. So treat C++ compiler warnings as though they were errors. 71) Inheritance of implementation has not turned out to be the labor-saving device we thought it would be. (Unlike composition, it doesn't function through low-coupling, program-by-contract messages.) 72) While the maintainability of the derived classes goes up because of factoring, the maintainability of the base class rapidly goes down. So be sure your code is stable before you start introducing inheritance of implementation. 73) Given the fragility of base classes, they should always be destined and designed to be base classes. A class should never just slip into becoming a base class. Design your concrete, derived classes so that they could never become base classes. So why don't we ban inheritance? Because there's something more important than implementation to inherit. Public inheritance gives objects extra types; it supports polymorphism. 74) Private data members are present in the instances of derived classes. They just can't be accessed by derived class code (which is a good thing). 75) The class keyword brings private access for the members. But that includes inheritance; and private inheritance is not the object-oriented way. Private inheritance is the (now not very popular) mixin way. 76) Don't be trapped into mentioning base class names any more than you have to. Use the "typedef BaseClass super" trick to avoid it. And don't use any class name as part of a function name. 77) [As mentioned earlier] Beware if you think you're overloading a member function from a base class. A derived class member function with the same name as a base class member function name-hides the base class one. A using declaration can sort this out. 78) Unless you use virtual member functions, C++ doesn't give you polymorphic behavior. By default C++ uses the pointer type to select member functions. That way lies redundant overriding and inconsistent binding. 79) Don't be misled into thinking that there's anything "ghostly" or "not really there" about virtual member functions. Pronounce "virtual" as "polymorphic". (The ghostly ones are the pure virtuals.) 80) It's not a compile error to forget to pass a derived class object by pointer or reference, when the parameter declaration was for a base class object. What will happen is that the derived bits will be "sliced" off as the argument is copied onto the stack. 81) Although making a member function polymorphic (virtual) means that the object selects the member function, it's still the pointer type that selects the access category. If you override a member function in a different access category, a) we hope you've done it to be more restrictive, not less, and b) the type of the pointer chooses the access category determining class. 82) Don't be misled by the unforgivably obscure syntax (= 0) into thinking that pure virtual member functions are some dark and dusty corner that is to be ignored. They are pivotal to good OO. 83) Don't imagine that a class with no code and no data members is worthless. A class with nothing but pure virtual member functions (a pABC) is an excellent and simple type that classes can implement. 84) Don't by misled by some books (or even libraries and frameworks) into thinking it's OK to instantiate base classes. It's almost never a good idea you end up with a class doing three jobs, and two is bad enough. 85) If you disregard the earlier advice to allow one or none of your base classes to have implementation, you will also and always have to consider whether your inheritance should be virtual inheritance. 86) Don't imagine that because the RTTI (run-time type identification) was introduced, you should use it. Treat "What's your class?" as a rude question and use it only once in a blue moon. Overuse of the RTTI probably indicates an architecture that is failing not having enough 1:m association relationships or the 1:m association relationships having the wrong types. 87) It's not an afterthought (I hope) that the type_info object supports one in avoiding mentioning a class by name. Avoid building class names into anything but declarations. And even in declarations avoid concrete class names as types. 88) Putting "using namespace std" makes a very large set of unseen names available to clash in "what on earth's going on" kinds of ways with your identifiers - particularly at some point in the future. 89) There might be more namespaces than you thought in which C++ will look for a function. C++ also searches for a function in the namespaces in which any of a function's arguments of class type are defined. 90) If any function you call (or that it calls, or ...) could throw, you need to be an order of magnitude more careful a programmer than you would otherwise have needed. 91) A derived object catcher that follows a catcher for its base class can never be reached. 92) Although you don't have to catch exception objects by reference, getting into the habit of doing anything else is asking for trouble. See bit slicing. This list isn't complete, there are several things we have discussed in the past that aren't listed there. And then, there are other traps/troubles not listed there because specific of D and probably absent from C++. Bye, bearophile
Nov 06 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 This list isn't complete, there are several things we have discussed
 in the past that aren't listed there.
For one thing, it doesn't mention concurrency gotchas.
Nov 06 2008
prev sibling next sibling parent reply ore-sama <spam here.lot> writes:
bearophile Wrote:

 This page lists a lot of C++ traps and pitfalls in a short space. I assume D
has to avoid or render meaningless a quite high percentage of them.
 The nice thing of that list is that I think most (maybe 80-90%) of those traps
and pitfalls (and several others that aren't listed, like allowing simple
syntactical mistakes like putting a & where a && was requires or vice versa,
etc) can be avoided by a language like D
 but seeing the huge troubles C++ has gone to be as much compatible as possible
with C I'd say that keeping the original C semantics when it is known to cause
troubles is _always_ bad. In such situations I prefer a language that acts
correctly
Most of these pitfalls are actually features, not bugs and are used massively. Like implicit casts, & instead of &&, assignment instead of comparison etc. These are pitfalls for novice programmers. Why bother? Everything is a pitfall for a novice programmer. You can safely say that every feature is a pitfall because programmer can make mistake in any place. I saw a man writing a program randomly typing something on the keyboard :) And he's not alone. What will be a pitfall for such programmers? ps why there was a need to reinvent identity operator, I wonder? It already was in JavaScript.
Nov 06 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"ore-sama" wrote
 bearophile Wrote:

 This page lists a lot of C++ traps and pitfalls in a short space. I 
 assume D has to avoid or render meaningless a quite high percentage of 
 them.
 The nice thing of that list is that I think most (maybe 80-90%) of those 
 traps and pitfalls (and several others that aren't listed, like allowing 
 simple syntactical mistakes like putting a & where a && was requires or 
 vice versa, etc) can be avoided by a language like D
 but seeing the huge troubles C++ has gone to be as much compatible as 
 possible with C I'd say that keeping the original C semantics when it is 
 known to cause troubles is _always_ bad. In such situations I prefer a 
 language that acts correctly
Most of these pitfalls are actually features, not bugs and are used massively. Like implicit casts, & instead of &&, assignment instead of comparison etc. These are pitfalls for novice programmers. Why bother?
They can be made more difficult to do mistakenly. Even experienced developers fall into some of these traps. I know I occasionally fell into this trap: if(x); x->doSomething(); But no more with D, because it's not allowed. Those kinds of things can be easily prevented, and are common mistakes by all programmers. I appreciate any effort by the compiler to not compile code that can be definitively declared as invalid. It saves me time and bugs, and that is worth a lot. -Steve
Nov 06 2008
next sibling parent reply ore-sama <spam here.lot> writes:
Steven Schveighoffer Wrote:

 I appreciate any effort by the compiler to not compile code that can be 
 definitively declared as invalid.  It saves me time and bugs, and that is 
 worth a lot.
You said "definitely". Your example is meaningful, but this doesn't affect my examples.
Nov 06 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"ore-sama" wrote
 Steven Schveighoffer Wrote:

 I appreciate any effort by the compiler to not compile code that can be
 definitively declared as invalid.  It saves me time and bugs, and that is
 worth a lot.
You said "definitely". Your example is meaningful, but this doesn't affect my examples.
Yes, you are probably right. Those can be valid either way, much more than my example. To be honest though, I more disagree with your assertion that only novice programmers are affected. I sometimes make these types of mistakes, and I definitely don't consider myself a novice ;) -Steve
Nov 06 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 To be honest though, I more disagree with your assertion that only novice 
 programmers are affected.  I sometimes make these types of mistakes, and I 
 definitely don't consider myself a novice ;)
The if(e); is illegal in D because back in the 80's, the best programmer in the company came to me asking me why his for loop executed only once: for (i = 0; i < N; i++); ... He had spent all afternoon chasing this problem, first isolating it to the loop and then trying to figure it out. He was sure it was a compiler bug. I stared at it for a while, mystified too, until I saw the ;. There is no advantage to having the language accept such code, and even if the programmer wrote it on purpose, it *looks* like a bug. Code that looks right should be right, and code that looks wrong should be wrong.
Nov 06 2008
prev sibling parent reply Janderson <ask me.com> writes:
Steven Schveighoffer wrote:

 To be honest though, I more disagree with your assertion that only 
novice programmers are affected. I sometimes make these types of mistakes, and I definitely don't consider myself a novice ;)
 -Steve
A good point. We seem to have a lot of super programmers who don't make simple mistakes ever and know C++ back to front. That's Great! For myself, after programming in C++ for 7 years (and other languages before that) I still find myself making coding typo's and discovering new things about C++. Keeping an open mind is key to getting better. I bet even Bjarne Stroustrup himself does not know all the pitfalls he left in the language. A couple of quotes to put names to: "Anyone who has never made a mistake has never tried anything new." "...it's essential to keep an open mind, and to be willing--better yet, eager--to try new things." "The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it." -Joel
Nov 08 2008
next sibling parent reply ore-sama <spam here.lot> writes:
Janderson Wrote:

 We seem to have a lot of super programmers who don't make simple 
 mistakes ever and know C++ back to front.  That's Great!
 For myself, after programming in C++ for 7 years (and other languages 
 before that) I still find myself making coding typo's and discovering 
 new things about C++.  Keeping an open mind is key to getting better.
Yeah, C++ is a continuous discovery, may be because of this C++ pros can't get used to if statement syntax? I thought, fingers know syntax, not brain... well, it's C++ after all :3
Nov 09 2008
parent Janderson <ask me.com> writes:
ore-sama wrote:
 Janderson Wrote:
 
 We seem to have a lot of super programmers who don't make simple 
 mistakes ever and know C++ back to front.  That's Great!
load of restrictions that help detect possible gotchas that you don't get with C++. They could be removed to allow for more "expressive" code but then you'd have C++. For example, trying to change the size of an
 
 For myself, after programming in C++ for 7 years (and other languages 
 before that) I still find myself making coding typo's and discovering 
 new things about C++.  Keeping an open mind is key to getting better.
Yeah, C++ is a continuous discovery, may be because of this C++ pros can't get used to if statement syntax? I thought, fingers know syntax, not brain... well, it's C++ after all :3
Nov 09 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Janderson wrote:
 "The trouble with having an open mind, of course, is that people will 
 insist on coming along and trying to put things in it."
"An open mind is an empty mind." -- Mark Stroberg
Nov 09 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 Even experienced developers fall into some of these traps.  I know I 
 occasionally fell into this trap:
 
 if(x);
   x->doSomething();
 
 But no more with D, because it's not allowed.  Those kinds of things can be 
 easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
Nov 06 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 Steven Schveighoffer wrote:
 
 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:
 
 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
 
Here's another fun one: printf("%d\n", 8l); What does that print?
8
Nov 06 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"BCS" wrote
 Reply to Walter,

 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
On little endian systems, yes. On big endian it would print 0. -Steve
Nov 06 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 Reply to Walter,
 
 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
If I hadn't said it was a trap, I bet you'd have said "81".
Nov 06 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Nov 6, 2008 at 5:07 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 BCS wrote:
 Reply to Walter,

 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
If I hadn't said it was a trap, I bet you'd have said "81".
I wouldn't've, because I use a font that actually distinguishes things 1, I, l, and | properly. <_<
Nov 06 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 On Thu, Nov 6, 2008 at 5:07 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 BCS wrote:
 Reply to Walter,

 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
If I hadn't said it was a trap, I bet you'd have said "81".
I wouldn't've, because I use a font that actually distinguishes things 1, I, l, and | properly. <_<
0 and O is another fun one. In any case, 8l is legal C, but illegal D.
Nov 06 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Nov 7, 2008 at 7:37 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 On Thu, Nov 6, 2008 at 5:07 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 BCS wrote:
 Reply to Walter,

 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
If I hadn't said it was a trap, I bet you'd have said "81".
I wouldn't've, because I use a font that actually distinguishes things 1, I, l, and | properly. <_<
0 and O is another fun one. In any case, 8l is legal C, but illegal D.
Threre are various good programmer fonts out there today that are designed to make the 1 l | and 0 O distinctions clear. I use the Proggy fonts. http://www.proggyfonts.com/index.php?menu=download These days I'd say if you're not using one of these fonts for programming you're being an extremely silly person. --bb
Nov 06 2008
next sibling parent reply Lars Kyllingstad <public kyllingen.NOSPAMnet> writes:
Bill Baxter wrote:
 On Fri, Nov 7, 2008 at 7:37 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 On Thu, Nov 6, 2008 at 5:07 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 BCS wrote:
 Reply to Walter,

 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
If I hadn't said it was a trap, I bet you'd have said "81".
I wouldn't've, because I use a font that actually distinguishes things 1, I, l, and | properly. <_<
0 and O is another fun one. In any case, 8l is legal C, but illegal D.
Threre are various good programmer fonts out there today that are designed to make the 1 l | and 0 O distinctions clear. I use the Proggy fonts. http://www.proggyfonts.com/index.php?menu=download These days I'd say if you're not using one of these fonts for programming you're being an extremely silly person. --bb
I use and recommend the DejaVu Sans Mono font. With this font there is no chance of confusing those troublesome characters, and it's very easy on the eyes. Also, the DejaVu fonts are available in the repositories of many (most?) Linux distributions. http://dejavu.sourceforge.net/ -Lars
Nov 07 2008
parent Mike Parker <aldacron gmail.com> writes:
Lars Kyllingstad wrote:
 Bill Baxter wrote:
 On Fri, Nov 7, 2008 at 7:37 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 On Thu, Nov 6, 2008 at 5:07 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 BCS wrote:
 Reply to Walter,

 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I 
 know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of 
 things
 can be easily prevented, and are common mistakes by all 
 programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
If I hadn't said it was a trap, I bet you'd have said "81".
I wouldn't've, because I use a font that actually distinguishes things 1, I, l, and | properly. <_<
0 and O is another fun one. In any case, 8l is legal C, but illegal D.
Threre are various good programmer fonts out there today that are designed to make the 1 l | and 0 O distinctions clear. I use the Proggy fonts. http://www.proggyfonts.com/index.php?menu=download These days I'd say if you're not using one of these fonts for programming you're being an extremely silly person. --bb
I use and recommend the DejaVu Sans Mono font. With this font there is no chance of confusing those troublesome characters, and it's very easy on the eyes. Also, the DejaVu fonts are available in the repositories of many (most?) Linux distributions. http://dejavu.sourceforge.net/ -Lars
I was surprised to learn I already have several versions of Deja Vu installed (on Windows). I've configured all of my text editors and even Thunderbird to use it now. What a difference! Thanks for pointing it out.
Nov 07 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 These days I'd say if you're not using one of these fonts for
 programming you're being an extremely silly person.
That's great, but one doesn't always have control over the fonts.
Nov 07 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Nov 6, 2008 at 7:02 PM, Bill Baxter <wbaxter gmail.com> wrote:
 Threre are various good programmer fonts out there today that are
 designed to make the 1 l | and 0 O distinctions clear.
 I use the Proggy fonts.  http://www.proggyfonts.com/index.php?menu=download

 These days I'd say if you're not using one of these fonts for
 programming you're being an extremely silly person.
ProggyCleanSZ, thankyouverymuch. Code doesn't look like code unless it's in that font ;)
Nov 06 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:
 ProggyCleanSZ, thankyouverymuch.  Code doesn't look like code unless
 it's in that font ;)
I use this (it's free) and I'm very happy of it, but note it requires a bigger size than Proggy, so if you want to program with a little font this isn't good: http://www.levien.com/type/myfonts/inconsolata.html Bye, bearophile
Nov 06 2008
prev sibling parent Don <nospam nospam.com> writes:
Walter Bright wrote:
 Jarrett Billingsley wrote:
 On Thu, Nov 6, 2008 at 5:07 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 BCS wrote:
 Reply to Walter,

 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
If I hadn't said it was a trap, I bet you'd have said "81".
I wouldn't've, because I use a font that actually distinguishes things 1, I, l, and | properly. <_<
0 and O is another fun one. In any case, 8l is legal C, but illegal D.
In CompSci1 we had use some ridiculous Mac editor where 0 and O were 100% identical, I,l, | and 1 also. It was an incredible source of bugs. We had to write a parser/emulator for some stupid imaginary asm language they'd invented, where O01 was output register 1. Plus, whitespace was significant, but it wasn't a monospaced font... It was like the whitespace programming language.
Nov 07 2008
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 6 Nov 2008 17:14:13 -0500, Jarrett Billingsley wrote:

 On Thu, Nov 6, 2008 at 5:07 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 BCS wrote:
 Reply to Walter,

 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
If I hadn't said it was a trap, I bet you'd have said "81".
I wouldn't've, because I use a font that actually distinguishes things 1, I, l, and | properly. <_<
Same here. I thought the 'trap' was using %d with a *long* value. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Nov 07 2008
parent "Nick Sabalausky" <a a.a> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:16rwvaqsxxzdx.hzsh3le743yv$.dlg 40tude.net...
 On Thu, 6 Nov 2008 17:14:13 -0500, Jarrett Billingsley wrote:

 On Thu, Nov 6, 2008 at 5:07 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 BCS wrote:
 Reply to Walter,

 Steven Schveighoffer wrote:

 Even experienced developers fall into some of these traps.  I know I
 occasionally fell into this trap:

 if(x);
 x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
8
If I hadn't said it was a trap, I bet you'd have said "81".
I wouldn't've, because I use a font that actually distinguishes things 1, I, l, and | properly. <_<
Same here. I thought the 'trap' was using %d with a *long* value.
In my newsgroup client, the lower-case 'L' renders as a straight vertical line with no serif or anything else. I can't remember ever seeing a (non-oddball) font where the "one" digit looked like that, so I instinctively saw it as "8L" and thought the intended gotcha was a mismatched number of bits causing a zero on a system of the wrong endianness. That said, I do still like D's requirement that the "L" suffix be capitalized.
Nov 07 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 06 Nov 2008 23:34:55 +0300, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 Even experienced developers fall into some of these traps.  I know I  
 occasionally fell into this trap:
  if(x);
   x->doSomething();
  But no more with D, because it's not allowed.  Those kinds of things  
 can be easily prevented, and are common mistakes by all programmers.
Here's another fun one: printf("%d\n", 8l); What does that print?
Yay, it is hardly distiguishable even at 500% zoom (Courier New)!
Nov 06 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:
 Even experienced developers fall into some of these traps.  I know I 
 occasionally fell into this trap:
 if(x);
   x->doSomething();
 But no more with D, because it's not allowed.  Those kinds of things can be 
 easily prevented, and are common mistakes by all programmers.
In Delight it's also quite difficult to fall in that trap: if x: x->doSomething() Many variants of that syntax are all disallowed: if x x->doSomething() if x: x->doSomething() if x x->doSomething() etc. So instead of making the language more confusing, it actually has the opposite effect. Bye, bearophile
Nov 06 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
ore-sama:
 These are pitfalls for novice programmers. Why bother?<
I want D to be a little more novice-friendly than C++. After 8 hours of coding, when I'm tired, I'm a novice myself, and I can appreciate any help the compiler can offer. Bye, bearophile
Nov 06 2008
prev sibling parent reply ore-sama <spam here.lot> writes:
bearophile Wrote:

 After 8 hours of coding, when I'm tired, I'm a novice myself, and I can
appreciate any help the compiler can offer.
 
Can tired programmer think about business process? It tends to be more complex than syntax and usually if tired programmer writes compilable code, this code is wrong (not because of syntax errors, but because of logical errors in business process).
Nov 07 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
ore-sama:
 Can tired programmer think about business process?
I can answer you that I use the first hours to think more and the later hours to program more. But what I've just said can't help you see why it's so important for the compiler to help avoid as many bugs as possible. I can't explain such essential concept in few lines here, so I suggest you to keep programming and reading, eventually you will probably get it. Later, bearophile
Nov 07 2008
parent reply ore-sama <spam here.lot> writes:
bearophile Wrote:

 But what I've just said can't help you see why it's so important for the
compiler to help avoid as many bugs as possible. I can't explain such essential
concept in few lines here, so I suggest you to keep programming and reading,
eventually you will probably get it.
 
it's clearly understandable that we don't need bugs. My point is to not let compiler prevent programmer from writing expressive code. If you force programmer to write a lot of text to make compiler happy, this in turn can cause bugs.
Nov 07 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
ore-sama escribió:
 bearophile Wrote:
 
 But what I've just said can't help you see why it's so important for the
compiler to help avoid as many bugs as possible. I can't explain such essential
concept in few lines here, so I suggest you to keep programming and reading,
eventually you will probably get it.
it's clearly understandable that we don't need bugs. My point is to not let compiler prevent programmer from writing expressive code. If you force programmer to write a lot of text to make compiler happy, this in turn can cause bugs.
if(x); doSomething Cool, you can express this: test something, and do nothing if true. Do you really need that expressiveness? Another one: the Eclipse Java compiler would tell if you might get a NullPointerException since at the beginning of a method you assign some variable to null, then you might change it to something non-null in some path, but you might not realize that you didn't make sure to set it to something non-null in all paths. So there goes Eclipse and tells you: in this specific line, that variable might be null. Do you want to be able to express "I probably have a bug here"?
Nov 07 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:
 Do you want to be able to express "I probably have a bug here"?
Even if the code is correct, if it looks like a bug, it will cause problems by repeatedly being flagged by others doing a code review.
Nov 07 2008
parent Derek Parnell <derek psych.ward> writes:
On Fri, 07 Nov 2008 07:34:26 -0800, Walter Bright wrote:

 Ary Borenszweig wrote:
 Do you want to be able to express "I probably have a bug here"?
Even if the code is correct, if it looks like a bug, it will cause problems by repeatedly being flagged by others doing a code review.
Yes, that is one more item in the "cost of maintenance". My mantra for many, many years now has been that programming languages exist to serve people rather than serve computers, and their greatest service is to reduce the cost of maintenance. Initial coding is a once-off price and after that the (long) time following we must pay the piper (like the 2nd law of thermodynamics insomuch as everything decays over time unless energy is added to stop it decaying) There are many things in the D programming langauge that helps us reduce maintenance costs, but more can still be done. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Nov 07 2008
prev sibling parent reply Janderson <ask me.com> writes:
ore-sama wrote:
 bearophile Wrote:

 But what I've just said can't help you see why it's so important for 
the compiler to help avoid as many bugs as possible. I can't explain such essential concept in few lines here, so I suggest you to keep programming and reading, eventually you will probably get it.

 it's clearly understandable that we don't need bugs. My point is to 
not let compiler prevent programmer from writing expressive code. If you force programmer to write a lot of text to make compiler happy, this in turn can cause bugs. Writing extra code to tell the compiler what you really mean is not necessarily a bad thing. Think about where you actually spend most of your time. If you are working on a small project, maybe you spend more of your time typing out the code. I think this is why scripting languages are loved for getting some done fast but grow unwieldy as the program gets larger. For me I can code something up pretty fast once I know what I want. How it interacts with the rest of the system is the difficult part. Particularly as a game programmer (I imagine its the same for other factions). I spend most of my time debugging and integrating with other peoples code. It's more difficult to spot a bug that someone else wrote. Lets take game AI for instance. The team can do their best to plan out a good AI for a character however when you hit the run button the AI appears to take on a life of its own. Why does the character decide to pick this target over this other target? Why does the character go left instead of right in this particular situation? Why does it only happen in release? I don't want spend hours tracking down the issue only to find its (for example) - an un-initialized variable or - a change introduced by Joe which changed how a particular class was designed to work. Note: unit tests are great here to enforce things continue to work the same way. Just a general question to everyone. Do you sometimes take conscious notes of what you spend your time doing? Then try to figure out ways to improve on it? I have found that there's things I didn't expect that I was spending time on. Even simple things like: - adding commonly used code fragments to visuals assists intellisense - using programs like distCC or incredibuild if your build is slow - not reinventing the wheel - Cheats and macros to improve debugging time. - Always fixing a bug and making sure it can't be repeated without at least a highly visible warning. - Making classes invariant so they can't be used in a wrong way ... go a long way to improving productivity. -Joel
Nov 09 2008
next sibling parent reply ore-sama <spam here.lot> writes:
Janderson Wrote:

 I spend most of my time debugging and integrating with other 
 peoples code.  It's more difficult to spot a bug that someone else wrote.
Millions of lines by novice programmers? I heard. Nothing will save you. :3
 however when you hit the run button the AI 
 appears to take on a life of its own.
Souldn't it do so?
Nov 09 2008
parent reply Janderson <ask me.com> writes:
ore-sama wrote:
 Janderson Wrote:
 
 I spend most of my time debugging and integrating with other 
 peoples code.  It's more difficult to spot a bug that someone else wrote.
Millions of lines by novice programmers? I heard. Nothing will save you. :3
:) Everyone who is better then me is an expert everyone who is below me is a novice. One day everyone but me will be a novice :)
 
 however when you hit the run button the AI 
 appears to take on a life of its own.
Souldn't it do so?
:) The point was that AI can be very complex when you add all the bits and pieces together. In a game you want the AI to look intelligent but also make the game fun. Sometimes these to ideals don't meet. -Joel
Nov 09 2008
parent "Chris R. Miller" <lordsauronthegreat gmail.com> writes:
Janderson wrote:
 ore-sama wrote:
 Janderson Wrote:

 I spend most of my time debugging and integrating with other peoples
 code.  It's more difficult to spot a bug that someone else wrote.
Millions of lines by novice programmers? I heard. Nothing will save you. :3
:) Everyone who is better then me is an expert everyone who is below me is a novice. One day everyone but me will be a novice :)
 however when you hit the run button the AI appears to take on a life
 of its own.
Souldn't it do so?
:) The point was that AI can be very complex when you add all the bits and pieces together. In a game you want the AI to look intelligent but also make the game fun. Sometimes these to ideals don't meet.
I smell a disappointed GR:AW player.
Nov 09 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Janderson wrote:
 however when you hit the run button the AI appears to take on a life of its
own.
Please tell me you don't work for Cyberdyne Systems!
Nov 09 2008