Comments by "MrAbrazildo" (@MrAbrazildo) on "The Downsides Of C++ | Prime Reacts" video.
-
14:09, this is good, not an issue, because it'd result in less refactoring, if changed, leading to more productivity.
14:20, 1st of all, this isn't real-life example. std::vector is a pretty fast data structure, that auto-manages its size internally. The compiler is so smart in optimizing it, that I often see it rivaling fixed size arrays.
14:47, I use msg or msn, to keep same letters as in portuguese.
15:00, what are you using? Vim? (kidding) :goodvibes:. On modern IDEs, Codeblocks for instance:
a) 1 can just leave the mouse over the f() name call (cursor not required), and 1s later it shows the f() signature.
b) Right click (on f() name) -> Go to declaration: it opens its header file, right at the f() signature.
c) If nothing of that worked (mostly due to not filling a cache yet) , add an absurd parameter on the f() call, and recompile. Compiler will say: this is stupid, look the f() signature: it opens a small log window from below, from which you can already see its signature, or left click on it, to open its file.
d) Write a tool: got_message could say what it changes, whenever called:
#ifdef SAY_WHAT_YOU_FUNC_CHANGES_WHENEVER_USER_DEFINED_THIS_MACRO
printf ("got_message changes size");
#endif
Then, on a click of a finger, 1 can disable this on the entire project, by just changing 1 line and recompiling it.
16:07, true, but I think the team should agree on defaults, before even start the project.
1
-
1:10, does anybody can explain to me what's the logic in calling enum a "sum type"? What's a sum type btw? 1:26, isn't std::tuple enough? 1:53, it's more comfortable than structs, due to possible accessing members via indexation. But I don't use it, because it generates too much assembly code, which leads to slower code.
2:00, are you sure? I know that acquiring/freeing resource are, and this is the main (and should be the only) goal for smart pointers. But raw pointers/iterators are pretty fast for memory accessing. All STL algorithms demand to use them (a few times as references).
4:58, but I'm, and I say it's the best language for crafting tools (more functionality/freedom). Whenever I face something risky around the corner, I build a tool to deal with that.
6:50, you can put declarations and definitions on the same header. I do this for small projects.
7:25, there's no issue about the private data being on the header file. It'll continue being forbidden for public access, unless otherwise expressed.
8:55, I rarely forget to type const. But I agree that const by default is useful. However, it's possible to create a convention for the team:
1) Create some prefix/suffix meaning const for the type, like 'int_'. 2) Do the same for 'mut'. 3) Config. to highlight them in the code editor. 4) Config. to NOT highlight the conventional types in the code editor. This way, the team will notice, at once, that something is wrong when they type 'int', and it doesn't highlight.
10:20, I think const_cast is always a mistake. There's an optimization the compiler does, by exchanging all const by literals, since the beginning, which might colide to that. Better is to go right away to the f(), fixing its const-less issue.
1
-
10:45, I guess the maintainers just opted for keeping the non-const iterator because it's a clue, of what the iterator will do inside the f().
11:53, "Move was a mistake. It should not be standardized. The compiler can see the allocators" - said a compiler maintainer. It can manage the movable things for us.
12:20, std::function is not mandatory. I would never use a runtime exception just to have it. 1 can use pointer to f(). Its only disadvantage over that class is its kind of annoying type syntax declaration, that can get worse. However, there are some turnarounds:
a) auto function = my_func_name; // By omitting the ( ), it's already a pointer to f() .
b) If receiving it in a template f(), doesn't even need to know what the type is: just pass the f() name, when calling the template f().
c) If it's not a template, and needs to know the type to declare it, just type another thing, not convertible: the compiler will halt, saying the type it deducted. Then copy/paste it right from the log.
12:42, as I said before, write a tool. For instance, why not put a printf on copy constructor? It'd warn you.
And non-primitive types can be send by copy. 1) Compiler may arrange things for you. 2) The size is more relevant than the type. For instance, I once had a 1-byte class. It had its f()s, but only 1-byte data. Passing it by copy on the entire project wasn't slower.
13:25, I don't think these are valid issues. It's just a call to a f(), when returning. If that's a concern, 1 can keep those values in a struct, dismissing calling f()s at returning. These "out parameters" may have a performance cost.
1