Hot answers tagged

19

You're confusing immutability of reference to object and immutability of the object itself. They are separate things. laptop.memory is just a reference (pointer) to the object. This can be modified, i.e. you can change the reference to point to a different object - which is exactly what you did - you created a second String object containing "2GB" and ...


7

A longer definition can be found in Martin Fowler's Refactoring book (page xvi). Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you ...


4

The obvious disadvantage would be that a node cannot belong to more than one list. The fact that nodes can belong to more than one list is typically critical in the implementation of persistent data structures through structural sharing. So, by making the node know about the list, you pretty much preclude making the list persistent, at least using the ...


4

The potential problem with the Node class knowing about and using the List class directly is that you create a circular dependency between Node and List. Circular dependencies can be acceptable if they're carefully contained to ensure you don't accidentally end up making all your classes circularly dependent on each other. This particular example is ...


3

Here's my opinion on the matter: consider whether both variants can actually be used in your case. reference_wrapper is, by design, not default-constructible. That means you will not be able, for example, to call container.resize() when using the reference wrapper. A shared_ptr, on the other hand, is default-constructed to an invalid/NULL state. So, for ...


3

If you're talking about variables of user-defined polymorphic types, then in C++ you need to use a pointer or a reference in order to achieve runtime polymorphism. The exact syntax you're describing is probably legal in C++ (hard to say since you didn't give a complete example), but results in "object slicing" rather than polymorphism. The reason is that a ...


2

It is not clear what you do with those objects. If you want to copy the non-copyable class, then using shared_ptr is fine as you did. If you want to copy objects, then return a value. If you just want to provide access to those objects, then use references : class Container { public: // ...other functions const Thing& GetThing() const; ...


2

Return/pass by const ref before turning to shared_ptr. They let you pass by reference without allowing them to change the object. This requires that you take care to maintain const-correctness throughout. class Container { public: // ...other functions const &Thing GetThing() const; &Thing GetThing(); const &std::vector<...


2

Mike Nakis wrote an excellent Java centric response. For other languages, you need to follow the similarly established conventions. Ruby, as an example, uses "::" for class methods, and "#" for instance methods. The point, however, is simply this: you are not writing the documentation for only your personal consumption, but for other programmers. ...


2

Actually, it is not an opinion poll, there is a clear answer mandated by the guidelines for writing doc comments, and followed by IDEs. From your sample code it is obvious that you are talking about Java. You pretty much have to use '#', since that's what is mandated by the standard, (see Oracle: How to Write Doc Comments for the Javadoc Tool) and that's ...


2

Have I not created a variable MyList of size double? With double[] MyList;, you've merely created a variable that can later refer to an array of doubles. You haven't created any doubles. It's essentially a pointer. Why is there an option of declaring an array, instead of creating it at once? Sometimes you won't want to create it at once. For example, ...


2

Under the hood, it might be implemented differently, but the visible effect of MyClass(const QByteArray & raw){ this->m_rawData =raw; } will be that the contents of raw get copied into m_rawData and will survive after raw has been destructed. This works because m_rawData is declared as being a value of type QByteArray. If it would have ...


1

You are running up against the challenges inherent to an ORM. ORM's are by definition leaky abstractions. Martin Fowler has an excellent article addressing your "moral and computer-sciency issues". http://martinfowler.com/bliki/OrmHate.html The truth is, ORM's are a pain and never feel right, especially for purists. This is because quite simply they are not ...


1

If you need to be able to assign a subclass instance to a variable in c++, and you need reassignment, then what you want is a pointer. private: State* current_state; If there's ownership involved, you should use a smart pointer like unique_ptr or shared_ptr. shared_ptr most closely matches the semantics of Java references, other than the fact that it ...


1

To me the biggest problem is: Increasing the size of a list node by an extra pointer (or references) for SLL, 3 for DLL. This might not affect performance that much if you're just sporadically allocating list nodes all over the memory space, since at that point it wouldn't matter much unless the node was just around 64 bytes, e.g., aligned to 64 byte ...


1

The Big Differences... While the pros & cons above are valid concerns, I don't care [too] much about them on a higher scale. Here are the pros & cons which determine whether I write in one paradigm or the other: Reference-Based Usually, this approach will lead you down paths you're not aware of. You will likely be coupling intensively -- and it ...


1

Java References and C pointers differ in exactly two points: There's no pointer-arithmetic for the former. And you cannot create a Java reference to whatever you want, you can only copy those saved somewhere accessible (static fields, fields of objects, local variables) or returned by function-invocations (like constructor-calls), which thus all refer to ...


1

It sounds like you are doing this because you want to modify the internal values inside Container. So you are doing something like: void foo(Container &container) { container.GetThing().SetFoo(12); } The problem is that you are not supposed to be modifying Container's internal state this way. Only methods on Container should modify it. So this ...


1

The question is one of ownership You make no mention of who owns the objects going into the container. Since the shared_ptr is an option, there is probably some form of shared ownership and dynamic storage allocation. A clear definition of who owns the objects and how they are observed (i.e. who can observe them) will frame much of the implementation. ...


1

It's mostly a question of lifetime and ownership. A container using reference_wrapper doesn't own its objects or manage their lifetime, a container using shared_ptr does. If your container shouldn't own its objects, then use reference_wrapper. If it should own its objects, then I'd take a third option. Boost.Pointer Container has template classes such as ...



Only top voted, non community-wiki answers of a minimum length are eligible