Search Results

Search found 51 results on 3 pages for 'fredoverflow'.

Page 1/3 | 1 2 3  | Next Page >

  • Do we still have a case against the goto statement? [closed]

    - by FredOverflow
    Possible Duplicate: Is it ever worthwhile using goto? In a recent article, Andrew Koenig writes: When asked why goto statements are harmful, most programmers will say something like "because they make programs hard to understand." Press harder, and you may well hear something like "I don't really know, but that's what I was taught." For that reason, I'd like to summarize Dijkstra's arguments. He then shows two program fragments, one without a goto and and one with a goto: if (n < 0) n = 0; Assuming that n is a variable of a built-in numeric type, we know that after this code, n is nonnegative. Suppose we rewrite this fragment: if (n >= 0) goto nonneg; n = 0; nonneg: ; In theory, this rewrite should have the same effect as the original. However, rewriting has changed something important: It has opened the possibility of transferring control to nonneg from anywhere else in the program. I emphasized the part that I don't agree with. Modern languages like C++ do not allow goto to transfer control arbitrarily. Here are two examples: You cannot jump to a label that is defined in a different function. You cannot jump over a variable initialization. Now consider composing your code of tiny functions that adhere to the single responsibility principle: int clamp_to_zero(int n) { if (n >= 0) goto n_is_not_negative: n = 0; n_is_not_negative: return n; } The classic argument against the goto statement is that control could have transferred from anywhere inside your program to the label n_is_not_negative, but this simply is not (and was never) true in C++. If you try it, you will get a compiler error, because labels are scoped. The rest of the program doesn't even see the name n_is_not_negative, so it's just not possible to jump there. This is a static guarantee! Now, I'm not saying that this version is better then the one without the goto, but to make the latter as expressive as the first one, we would at least have to insert a comment, or even better yet, an assertion: int clamp_to_zero(int n) { if (n < 0) n = 0; // n is not negative at this point assert(n >= 0); return n; } Note that you basically get the assertion for free in the goto version, because the condition n >= 0 is already written in line 1, and n = 0; satisfies the condition trivially. But that's just a random observation. It seems to me that "don't use gotos!" is one of those dogmas like "don't use multiple returns!" that stem from a time where the real problem were functions of hundreds or even thousand of lines of code. So, do we still have a case against the goto statement, other than that it is not particularly useful? I haven't written a goto in at least a decade, but it's not like I was running away in terror whenever I encountered one. 1 Ideally, I would like to see a strong and valid argument against gotos that still holds when you adhere to established programming principles for clean code like the SRP. "You can jump anywhere" is not (and has never been) a valid argument in C++, and somehow I don't like teaching stuff that is not true. 1: Also, I have never been able to resurrect even a single velociraptor, no matter how many gotos I tried :(

    Read the article

  • Prefer algorithms to hand-written loops?

    - by FredOverflow
    Which of the following to you find more readable? The hand-written loop: for (std::vector<Foo>::const_iterator it = vec.begin(); it != vec.end(); ++it) { bar.process(*it); } Or the algorithm invocation: #include <algorithm> #include <functional> std::for_each(vec.begin(), vec.end(), std::bind1st(std::mem_fun_ref(&Bar::process), bar)); I wonder if std::for_each is really worth it, given such a simple example already requires so much code. What are your thoughts on this matter?

    Read the article

  • Where did the notion of "one return only" come from?

    - by FredOverflow
    I often talk to Java programmers who say "Don't put multiple return statements in the same method." When I ask them to tell me the reasons why, all I get is "The coding standard says so." or "It's confusing." When they show me solutions with a single return statement, the code looks uglier to me. For example: if (blablabla) return 42; else return 97; "This is ugly, you have to use a local variable!" int result; if (blablabla) result = 42; else result = 97; return result; How does this 50% code bloat make the program any easier to understand? Personally, I find it harder, because the state space has just increased by another variable that could easily have been prevented. Of course, normally I would just write: return (blablabla) ? 42 : 97; But the conditional operator gets even less love among Java programmers. "It's incomprehensible!" Where did this notion of "one return only" come from, and why do people adhere to it rigidly?

    Read the article

  • Design patterns: when to use and when to stop doing everything using patterns

    - by honeybadger
    This question arises due to comment of FredOverflow in my previous post. Design pattern used in projects I am quite confused by the comment. I know design pattern help in making code reusable and readable (may lack in efficiency a bit). But when to use design patterns and most importantly when to stop doing everything using patterns or carried away by it ? Any comments from you will be helpful. tagging programing languages too to cover broader audience.

    Read the article

  • Language-agnostic term for typed things that need memory

    - by FredOverflow
    Is there an accepted general term that subsumes the concepts of variables, class instances and arrays? Basically "any typed thing that needs memory". In C++, such a thing is called an object, but I'm looking for a more language-agnostic term. § 1.8 The C++ object model 1 The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is a region of storage. [...] An object can have a name (Clause 3). An object has a storage duration (3.7) which influences its lifetime (3.8). An object has a type (3.9).

    Read the article

  • Throwing a new exception while throwing an old exception

    - by FredOverflow
    If a destructor throws in C++ during stack unwinding caused by an exception, the program terminates. (That's why destructors should never throw in C++.) If a finally block is entered in Java because of an exception in the corresponding try block and that finally block throws another exception, the first exception is silently swallowed. This question crossed my mind: Could a programming language handle multiple exceptions being thrown at the same time? Would that be useful? Have you ever missed that ability? Is there a language that already supports this? Is there any experience with such an approach? Any thoughts?

    Read the article

  • How do boost operators work?

    - by FredOverflow
    boost::operators automatically defines operators like + based on manual implementations like += which is very useful. To generate those operators for T, one inherits from boost::operators<T> as shown by the boost example: class MyInt : boost::operators<MyInt> I am familiar with the CRTP pattern, but I fail to see how it works here. Specifically, I am not really inheriting any facilities since the operators aren't members. boost::operators seems to be completely empty, but I'm not very good at reading boost source code. Could anyone explain how this works in detail? Is this mechanism well-known and widely used?

    Read the article

  • Official names for pointer operators

    - by FredOverflow
    What are the official names for the operators * and & in the context of pointers? They seem to be frequently called dereference operator and address-of operator respectively, but unfortunately, the section on unary operators in the standard does not name them. I really don't want to name & address-of anymore, because & returns a pointer, not an address. (A pointer is a language mechanism, while an address is an implementation detail. Addresses are untyped, while pointers aren't, except for void*.) The standard is very clear about this: The result of the unary & operator is a pointer to its operand. Symmetry suggests to name & reference operator which is a little unfortunate because of the collision with references in C++. The fact that & returns a pointer suggests pointer operator. Are there any official sources that would confirm these (or other) namings?

    Read the article

  • non-class rvalues always have cv-unqualified types

    - by FredOverflow
    §3.10 section 9 says "non-class rvalues always have cv-unqualified types". That made me wonder... int foo() { return 5; } const int bar() { return 5; } void pass_int(int&& i) { std::cout << "rvalue\n"; } void pass_int(const int&& i) { std::cout << "const rvalue\n"; } int main() { pass_int(foo()); // prints "rvalue" pass_int(bar()); // prints "const rvalue" } According to the standard, there is no such thing as a const rvalue for non-class types, yet bar() prefers to bind to const int&&. Is this a compiler bug? EDIT: Apparently, this is also a const rvalue :)

    Read the article

  • Exceptions in constructors

    - by FredOverflow
    In C++, the lifetime of an object begins when the constructor finishes successfully. Inside the constructor, the object does not exist yet. Q: What does emitting an exception from a constructor mean? A: It means that construction has failed, the object never existed, its lifetime never began. [source] My question is: Does the same hold true for Java? What happens, for example, if I hand this to another object, and then my constructor fails? Foo() { Bar.remember(this); throw new IllegalStateException(); } Is this well-defined? Does Bar now have a reference to a non-object?

    Read the article

  • Syntax for specializing function templates

    - by FredOverflow
    Is there a difference between the following approaches? // approach 1 namespace std { template<> void swap<Foo>(Foo& x, Foo& y) // note the <Foo> { x.swap(y); } } // approach 2 namespace std { template<> void swap(Foo& x, Foo& y) { x.swap(y); } } I stumpled upon this when I tried to specialize swap for my own string type and noticed that swap<::string> doesn't work, but for a completely different reason :)

    Read the article

  • Throwing an exception while handling an exception

    - by FredOverflow
    If a destructor throws in C++ during stack unwinding caused by an exception, the program terminates. (That's why destructors should never throw in C++.) If a finally block is entered in Java because of an exception in the corresponding try block and that finally block throws another exception, the first exception is silently swallowed. This question crossed my mind: Could a programming language handle multiple exceptions being thrown at the same time? Would that be useful? Have you ever missed that ability? Is there a language that already supports this? Is there any experience with such an approach? Any thoughts?

    Read the article

  • std::string x(x);

    - by FredOverflow
    std::string x(x); This crashes very badly on my compiler. Does this mean I should test for this != &that in my own copy constructors, or can I assume that no client will ever be so stupid?

    Read the article

  • Move from *this in an rvalue method?

    - by FredOverflow
    In C++0x, methods can be overloaded on whether or not the expression that denotes the object on which the method is called is an lvalue or an rvalue. If I return *this from a method called via an rvalue, do I need to explicitly move from *this or not? Foo Foo::method() && { return std::move(*this); // Is this move required or not? } Unfortunately, I can't simply test this on my compiler since g++ does not support this feature yet :(

    Read the article

  • Statements and state

    - by FredOverflow
    Is there any deeper meaning in the fact that the word "statement" starts with the word "state", or is that just a curious coincidence? Note that english is not my native language, so the answer might be obvious to you, but not me ;)

    Read the article

  • Making swap faster, easier to use and exception-safe

    - by FredOverflow
    I could not sleep last night and started thinking about std::swap. Here is the familiar C++98 version: template <typename T> void swap(T& a, T& b) { T c(a); a = b; b = c; } If a user-defined class Foo uses external ressources, this is inefficient. The common idiom is to provide a method void Foo::swap(Foo& other) and a specialization of std::swap<Foo>. Note that this does not work with class templates since you cannot partially specialize a function template, and overloading names in the std namespace is illegal. The solution is to write a template function in one's own namespace and rely on argument dependent lookup to find it. This depends critically on the client to follow the "using std::swap idiom" instead of calling std::swap directly. Very brittle. In C++0x, if Foo has a user-defined move constructor and a move assignment operator, providing a custom swap method and a std::swap<Foo> specialization has little to no performance benefit, because the C++0x version of std::swap uses efficient moves instead of copies: #include <utility> template <typename T> void swap(T& a, T& b) { T c(std::move(a)); a = std::move(b); b = std::move(c); } Not having to fiddle with swap anymore already takes a lot of burden away from the programmer. Current compilers do not generate move constructors and move assignment operators automatically yet, but as far as I know, this will change. The only problem left then is exception-safety, because in general, move operations are allowed to throw, and this opens up a whole can of worms. The question "What exactly is the state of a moved-from object?" complicates things further. Then I was thinking, what exactly are the semantics of std::swap in C++0x if everything goes fine? What is the state of the objects before and after the swap? Typically, swapping via move operations does not touch external resources, only the "flat" object representations themselves. So why not simply write a swap template that does exactly that: swap the object representations? #include <cstring> template <typename T> void swap(T& a, T& b) { unsigned char c[sizeof(T)]; memcpy( c, &a, sizeof(T)); memcpy(&a, &b, sizeof(T)); memcpy(&b, c, sizeof(T)); } This is as efficient as it gets: it simply blasts through raw memory. It does not require any intervention from the user: no special swap methods or move operations have to be defined. This means that it even works in C++98 (which does not have rvalue references, mind you). But even more importantly, we can now forget about the exception-safety issues, because memcpy never throws. I can see two potential problems with this approach: First, not all objects are meant to be swapped. If a class designer hides the copy constructor or the copy assignment operator, trying to swap objects of the class should fail at compile-time. We can simply introduce some dead code that checks whether copying and assignment are legal on the type: template <typename T> void swap(T& a, T& b) { if (false) // dead code, never executed { T c(a); // copy-constructible? a = b; // assignable? } unsigned char c[sizeof(T)]; std::memcpy( c, &a, sizeof(T)); std::memcpy(&a, &b, sizeof(T)); std::memcpy(&b, c, sizeof(T)); } Any decent compiler can trivially get rid of the dead code. (There are probably better ways to check the "swap conformance", but that is not the point. What matters is that it's possible). Second, some types might perform "unusual" actions in the copy constructor and copy assignment operator. For example, they might notify observers of their change. I deem this a minor issue, because such kinds of objects probably should not have provided copy operations in the first place. Please let me know what you think of this approach to swapping. Would it work in practice? Would you use it? Can you identify library types where this would break? Do you see additional problems? Discuss!

    Read the article

  • initializer_list and move semantics

    - by FredOverflow
    Am I allowed to move elements out of a std::initializer_list<T>? #include <initializer_list> #include <utility> template<typename T> void foo(std::initializer_list<T> list) { for (auto it = list.begin(); it != list.end(); ++it) { bar(std::move(*it)); // kosher? } } Since std::intializer_list<T> requires special compiler attention and does not have value semantics like normal containers of the C++ standard library, I'd rather be safe than sorry and ask.

    Read the article

  • How does volatile actually work?

    - by FredOverflow
    Marking a variable as volatile in Java ensures that every thread sees the value that was last written to it instead of some stale value. I was wondering how this is actually achieved. Does the JVM emit special instructions that flush the CPU cashes or something?

    Read the article

  • Wildcards vs. generic methods

    - by FredOverflow
    Is there any practical difference between the following approaches to print all elements in a range? public static void printA(Iterable<?> range) { for (Object o : range) { System.out.println(o); } } public static <T> void printB(Iterable<T> range) { for (T x : range) { System.out.println(x); } } Apparently, printB involves an additional checked cast to Object (see line 16), which seems rather stupid to me -- isn't everything an Object anyway? public static void printA(java.lang.Iterable); Code: 0: aload_0 1: invokeinterface #18, 1; //InterfaceMethod java/lang/Iterable.iterator:()Ljava/util/Iterator; 6: astore_2 7: goto 24 10: aload_2 11: invokeinterface #24, 1; //InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object; 16: astore_1 17: getstatic #30; //Field java/lang/System.out:Ljava/io/PrintStream; 20: aload_1 21: invokevirtual #36; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V 24: aload_2 25: invokeinterface #42, 1; //InterfaceMethod java/util/Iterator.hasNext:()Z 30: ifne 10 33: return public static void printB(java.lang.Iterable); Code: 0: aload_0 1: invokeinterface #18, 1; //InterfaceMethod java/lang/Iterable.iterator:()Ljava/util/Iterator; 6: astore_2 7: goto 27 10: aload_2 11: invokeinterface #24, 1; //InterfaceMethod java/util/Iterator.next:()Ljava/lang/Object; 16: checkcast #3; //class java/lang/Object 19: astore_1 20: getstatic #30; //Field java/lang/System.out:Ljava/io/PrintStream; 23: aload_1 24: invokevirtual #36; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V 27: aload_2 28: invokeinterface #42, 1; //InterfaceMethod java/util/Iterator.hasNext:()Z 33: ifne 10 36: return

    Read the article

1 2 3  | Next Page >