Notepad

[Yousaf99]

Create a notepad that allows the user to write text on the console. For this purpose, the user should be
able to control and track the movement of the cursor. The user can access, add and delete any part of
the text. To add or delete a text, the user can take the cursor to that location (using the arrow keys) and
perform the required operation. The working of the program (i.e. the movement of the cursor, add and
delete operation) must be consistent with the working of the real notepad. However, you do not have
to handle word wrapping.

Internally, the notepad is composed of two-dimensional doubly linkedlist. Its implementation is just
like a doubly linked list with an additional property that it can grow in two dimensions. Since text can
be written on multi lines, each row of the 2D-linkedlist represents one line. Each node contains four
links which it uses to connect to node before, after, below and above it. In addition each node can store
a character.

I just want to know the structure of this question?

[Yousaf99]

It shoud be?

c-c-c-NULL
| | |
c-c-c-c-NULL

Or it shoud be?


c-c-c-c-
| | | |
-c-c-c-c

kindly somone explain this

[Golden Lizard]

Think of it as a list of lists. Every sub-list will be a line and each node a character. To pass from a line to another, you just go into the next or previous node of the main list. You can try to visualize it first with arrays, it will be easier to get the logic then and switching to lists won't be difficult.

main list
|
*
L i n e 1 ----|
L i n e 2 ----|---- sublists
L i n e 3 ----|

[gunnerfunner]

struct Node in a one-dimensional LL has 2 pointer data members - next and previous, so here you'd have 4 - next, previous, up and down
similarly the struct linkedList (based on struct Node) in a one-dimensional LL has 2 named nodes - head/tail, start/end etc and again in this case there'd be four - topLeft, topRight, bottomLeft, bottomRight etc
Here's some code from a oneD LL modified to take these into a/c in case they help you get started:

template <typename T>
struct Node
{
    T m_info;
    shared_ptr<Node<T>> m_next;
    shared_ptr<Node<T>> m_prev;
    shared_ptr<Node<T>> m_up;
    shared_ptr<Node<T>> m_down;

    Node<T> (): m_next(nullptr), m_prev (nullptr), m_up (nullptr), m_down(nullptr) {}
    Node<T> (shared_ptr<Node<T>> next = nullptr, shared_ptr<Node<T>> prev = nullptr,
             shared_ptr<Node<T>> up = nullptr, shared_ptr<Node<T>> down = nullptr)
        : m_next (next), m_prev (prev), m_up (up), m_down(down) {}
    Node<T> (T t, shared_ptr<Node<T>> next = nullptr, shared_ptr<Node<T>> prev = nullptr,
             shared_ptr<Node<T>> up = nullptr, shared_ptr<Node<T>> down = nullptr)
        : m_info (t), m_next (next), m_prev (prev), m_up (up), m_down(down) {}
};
template <typename T>
struct List
{
    shared_ptr<Node<T>> m_topLeft;
    shared_ptr<Node<T>> m_topRight;
    shared_ptr<Node<T>> m_bottomLeft;
    shared_ptr<Node<T>> m_bottomRight;

    List () : m_topLeft (nullptr), m_topRight (nullptr), m_bottomLeft (nullptr), m_bottomRight (nullptr) {}
    //now think of the usual methods that a oneD LL has and try and come up with their twoD counterparts
    //Good luck!
}

[mbozzi]

@gunnerfunner
That's very prone to leaking memory.

[gunnerfunner]

Kindly explain? I'd like to learn more. Thanks

[cire]

Kindly explain? I'd like to learn more. Thanks

In most linked list scenarios a node has no business owning (or sharing in the ownership of) another node. Assuming a list with at least two elements, every node will continue to exist when the list is destroyed, because every node owns or shares in the ownership of up to 4 other nodes. Memory leak.

[gunnerfunner]

which bit of the code are you referring to that shares ownership of (with) another node?

[cire]

which bit of the code are you referring to that shares ownership of (with) another node?

shared_ptr is used for shared ownership.

[gunnerfunner]

Copy assignment is deleted for std::unique_ptr, std::shared_ptr is thus used (instead of move semantics). These may be used for shared ownership but is there anything in the code snippet to suggest that they are being so?

[cire]

These may be used for shared ownership but is there anything in the code snippet to suggest that they are being so?

You mean besides the fact that you're using something fabricated specifically for sharing ownership and are sharing ownership by using them?

http://stackoverflow.com/questions/7657718/when-to-use-shared-ptr-and-when-to-use-raw-pointers

[gunnerfunner]

from the very link you sent:

I have seen people advocating the use of shared_ptr even in non-shared environments,

...
i'm still waiting for the answer to my original question - where in the post snippets was there a memory leak

[cire]

from the very link you sent:
I have seen people advocating the use of shared_ptr even in non-shared environments,

Snipping the context which included this: ...this is still shared ownership even if it was not meant to be suggests you missed the point.

i'm still waiting for the answer to my original question - where in the post snippets was there a memory leak

See: http://ideone.com/HwkrEZ
which contains a simplified version of your code that illustrates resources not being released.

[gunnerfunner]

Snipping the context which included this: ...this is still shared ownership even if it was not meant to be suggests you missed the point.

not so, it just shows that it is a matter of opinion, not fact

[gunnerfunner]

which contains a simplified version of your code that illustrates resources not being released

again this is incorrect, my code was just bare-bones declaration and ctors, there was nothing attached to it and you interpreted it as you wished

[mbozzi]

Your solution proposed a doubly linked list of nodes.
A cycle of nodes which simultaneously own each other would leak memory.

The problem is the cycle:
If A owns B and B owns A, A will remain alive until B is destroyed, and B will remain alive until A is destroyed -- in effect, each object ends up waiting for its own destruction. It's not specific to shared ownership, any owning reference has the same problem.

One potential solution would be to use shared_ptr in two directions (e.g., towards the bottom right) and observer_ptr (a raw pointer) in the other two. That way you can use the non-owning pointers to go back through the list without creating an ownership cycle.

[cire]

not so, it just shows that it is a matter of opinion, not fact

You can stick your head in the sand all you want, I suppose.

Here's something from the standard:

20.7.2.2
...shared_ptr implements semantics of shared ownership; the last remaining owner of the pointer is responsible for destroying the object, or otherwise releasing the resources associated with the stored pointer....

Emphasis added by me.

Or perhaps you'd prefer to hear it from Bjarne Stroustrup?
http://www.stroustrup.com/C++11FAQ.html#std-shared_ptr

The shared in the name was enough for me.

again this is incorrect, my code was just bare-bones declaration and ctors, there was nothing attached to it and you interpreted it as you wished

Fair enough - I should've said "design" in lieu of "code."

The prepared code was in response to your query to mbozzi as to why the code was prone to error and the subsequent discussion (leading to a more specific issue, ie. memory leak,) and was intended to highlight how that was so. You are of course free to present a counter-example rather than posturing. How is your design not prone to error and/or memory leak?

[Yousaf99]

Is this doable using console????

if it is how to delete/remove character from the console screen??