5

Review points: removeFirst on an empty list should be a no-op, (or throw an exception). last was dangling. Setting things to null of the removed first node, is not done in OOP, is left to the garbage collection. This also removes the need for an extra variable. And the resulting binary code is smaller. So: public void removeFirst() { if (first != null)...


5

About the code: List& operator =(const List<T>&)=default; and List(const List<T>&)=default; provide excellent opportunity to get double delete with 100% chance of success. Your linked list required data to be copyable and it copies it on usage. It is bad, since now you cannot store data like std::unique_ptr that are not copyable. ...


4

Winning Bug When the board is at this stage and the user gets the next move: | | X | O | X | | ---------------------- | | | O | | | ---------------------- | | O | X | X | | And the user enters 5, the game bugs ...


4

This code is pretty neat. One major improvement would be the addition of some magic methods, like __iter__, __getitem__, __setitem__ and __str__. iter The magic method you'll use the most wil be __iter__. It will allow you to do for node in linked_list def __iter__(self): current = self.head while current: yield current current = ...


4

Design: OK initial attempt at abstraction main() does not expose struct q_9 members. Design: .tail is not needed Present function set has no benefit from the tail member. It is removable. Even delete_last() walks down the list. Design: Global variables not needed This is a major change, so will assume this code is using the simple one linked-list as ...


4

__getitem__, __setitem__, and __delitem__ should share index-validation and repair code. In __delitem__ you check the type of index as well as its algebraic sign (whether it's negative). In __getitem__ and __setitem__, you check only the algebraic sign; did you intend to not check the type of index in those two functions? If so, you should comment on why. If ...


2

So you need to separate the construction of that class from the class itself? This is the Factory Pattern. Data class Boil down to your DTO to ... well the data. public class MassiveDTO { private final List<String> company; private final List<String> partners; private final List<String> biodata; /** * @see ...


2

The code looks nice! Here are my suggestions. Testing Your code passes your test, but there are quite a few bugs that can be easily caught by testing! Make sure that every functionality is tested so you don't miss some bugs. The compiler flags Right now, you are using this command to compile the code: g++ -std=c++17 -g -Wall main.cpp -o main There ...


2

Notes Currently I'm aware that each node is created on the Heap. No such thing as heap in C++ (or stack technically). You mean dynamically allocated memory in the situation. Note: Though the language does not specify the need for a stack most implementations will use one. But the concept itself is not useful for thinking about C++ objects. You should ...


2

Overview I don't like that a LL is a node. A linked list contains nodes. But the list itself is not a node. The LL missed the rule of three. LL x; LL y(x); // You did not define a copy constructor // But this is still allowed (look up rule of three). // Normally this is an advantage. BUT if your class // contains RAW owned ...


1

from_iterable Based on my answer to this linked list question def from_iterable(iterable: Iterable[T]) -> Tuple[_Node[T], _Node[T], int]: """Constructs a node-list from an iterable. Returns a tuple of (head, last_node, list_length). head and last_node will be None if iterable is empty.""" it = iter(iterable) try: head = current =...


1

Using a dummy node is one way to simplify the logic in _Node.from_iterable and LinkedList.remove. We incur a constant-space cost of one extra node, and in return we don't need to write a separate branch of logic to handle the empty/null head case: @dataclass class _DummyNode(_Node[T]): data: Optional[T] = None tail: Optional[_Node[T]] = None @...


1

If one wants abstraction, then the interface (the menu) should be in a different file then the linked-list implementation, and should expose only function prototypes which are necessary in a header file, (the rest can be static.) The one with main should drive your linked list; the linked list should have no main. That way, code would be interchangeable into ...


1

OK, so what I understand, class MassiveDTO will be instantiated sometimes in your application, but those 3 lists can be static and won't change. So solution is create classes with static hard coded lists (3 classes) and just use static reference them in MassiveDTO: public class MassiveDTO { private List<String> company = CompanyDataHolder....


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