Timeline for Console Library System in C++
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 21, 2022 at 22:24 | vote | accept | Pham Long | ||
| Jan 5, 2022 at 14:49 | comment | added | ades |
Recommendations to use '\n' over std::endl seems like dogma at this point. Avoid premature optimisations and just use std::endl - ensuring that output is flushed is a good thing, not a bad thing.
|
|
| Dec 14, 2021 at 20:16 | comment | added | Alexis Wilke |
I don't know enough about Java, but C has fflush(stdout); as the equivalent to the C++ std::flush (C++ calls the C function internally).
|
|
| Dec 14, 2021 at 17:24 | history | edited | jdt | CC BY-SA 4.0 |
small typo
|
| Dec 14, 2021 at 17:03 | comment | added | G. Sliepen |
@A.Smoliak Yes. If Book just holds a bunch of information about a book, I'd expect it to be copyable and movable. If a Book represents a unique instance of a book though, I think it is fine if it is non-movable. Instead, ownership of a Book can then be moved by storing it in std::unique_ptrs. I'll see if I can update my answer to explain this difference.
|
|
| S Dec 14, 2021 at 16:55 | history | suggested | jiwopene | CC BY-SA 4.0 |
For some people, using `\n` is easier to read.
|
| Dec 14, 2021 at 16:54 | review | Suggested edits | |||
| S Dec 14, 2021 at 16:55 | |||||
| Dec 14, 2021 at 11:15 | comment | added | A. Smoliak | making members const will disable move semantics, I suggest omitting const | |
| Dec 13, 2021 at 18:49 | comment | added | Pham Long | Most of these are the things that I noticed but always forgot along the way. Thank you for the very detailed feedback ^_^ | |
| Dec 13, 2021 at 16:30 | comment | added | Matthieu M. | I was surprised I had to scroll down this far for someone to finally point out that logic and I/O should be separated, thanks Sir! Beyond the obvious Single Responsibility Principle, I would also emphasize testability. The OP didn't show any test, so I guess they don't have any in the first place; however I've many time seen large "upper" layers too tied to I/O to be tested and everyone just shrugging it off as "it cannot be tested"... and that's a poor habit to get into. | |
| Dec 13, 2021 at 15:56 | comment | added | Toby Speight |
The other factor that influences the choice is whether you want the objects to be assignable. const members inhibit the automatic generation of operator=() for the class. As nothing here uses it, that's fine; it does lead us to ask some design questions (such as whether we care about object identity or value, for instance). I'm a bit stretched today, or I might write my own answer looking at that.
|
|
| Dec 13, 2021 at 14:23 | comment | added | G. Sliepen |
@TobySpeight Thanks, I forgot about that. I changed the wording, I hope this is better. Now I wonder whether making a Book's properties immutable is the right thing to do, or if it's better to just have getters and no setters.
|
|
| Dec 13, 2021 at 14:20 | history | edited | G. Sliepen | CC BY-SA 4.0 |
added 199 characters in body
|
| Dec 13, 2021 at 11:23 | history | answered | G. Sliepen | CC BY-SA 4.0 |