Comments by "MrAbrazildo" (@MrAbrazildo) on "ThePrimeTime"
channel.
-
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
-
1
-
1
-
1:36, I think that would better fit as definition of productivity. I think maintainability is more related to not mess what was already done, whenever you need to change part of it, either by making new feature, refactoring, upgrading, optimizing, exchanging strategy, and so on.
1:53, I don't have this issue. I may forget a bit about how things communicate between themselves, but I get the idea from some minutes to some hours. I may also change the style a little bit.
What's the secret for this? I don't know exactly, but I keep the code commented in every tiny thing suspected to cause problems in the future. And I keep documentation about the project as a whole, outside the code too, for both strategy and tactic approaches.
3:35, this shouldn't be happening. Despite it's impossible to know how the entire project works tactically (the exact variables and how they change) , it's viable to have both the strategy (how it works at all, high level) of overall data structs, how they communicate and their goals; and the tactics inside each f(). For this last 1, I use to write its goal, comments in almost every line and even 1 or 2 edge examples, in case of a complex f(). I discover this need by making a brief "brainstorm" about it, mainly focusing on the future readability.
This is 1 of the key reasons why I have a "spaghetti" style of horizontal code, putting comments at its right side. People take this as ugly and unreadable at 1st glance. But I think it's compact (most of my f()s can be seen in 1 screen) , encapsulated (no unnecessary extra f()s are made, just for the sake of been "readable") , and commented enough for the future, without pushing the code downwards (which I think it's awful and damages readability) .
1
-
4:55, I don't use to have much problems with types. In games, they use to be way different from each other. For instance, if you mem. some data in a class, it will sooner than later be packed into bits. If you put some other object, when that 1 was expected, a compiler error will arise.
6:47, games are too wild to not use OO. They require proper encapsulation, in a level that FP can't provide.
13:34, I think a better design is to have several containers, 1 for each type. So 1 could has 1 for the white-hat guys, other for black-hat dudes, other for things, and so on. And those holding just data control, small stuff on stack, 100x faster. Only for multimedia, really large data, those smart-pointers would apply.
So another container on the stacks holds inf. for composing the scene: the index and container of things present in a certain moment. So data for other containers will be reached via indexes, avoiding the pointer invalidation problem - and also being much faster, since most data were computed on the stack.
14:17, sure. But doing this it'll be horrendously slow. The idea is to avoid the reallocation, for at least 90% of the time. So std::vector::reserve preallocates enough memory for that.
24:44, I heard that zealling feelings attract them.
26:18, it's possible to create a macro for both - so that both are changed together.
1
-
1
-
1
-
1
-
0:10, ooh, this is awkward! The right way is to have a variable in a class, and just ask for it, not loosing performance nor getting complicated, trying to guess what it is. It's even better if, instead of a variable, this constant is given as a template argument, by a f().
3:49, this is a long discussion, but I think quite the opposite. Horizontal code means 1 will spend less time traveling throughout the code vertically, which spends more energy, and looses a bit of focus. Plus, eyes are widescreen, they were made to see things horizontally. And also reading code is an eye thing, not a hands 1. I use tab = 2, to put more things on the same line.
1
-
0:08, hm... I don't know. I use to fly with C++. Unless Rust dismisses tests, which is not true, I have some doubts...
C++ can be felt as slower when typing declarations vs languages that dismiss them, or when those language have an already existing lib/algo to solve things at once. These are the 2 most common cases I can remember now. Other than that, C++ dismisses writing defensive stuff (this should not take too long) and has a concise syntax, that can be even more using macros. Running the app with some inputs known to have certain results, it soon becomes clear if a mistake appears. So stop and fix it. For experts, just by the looks of the bug (from the report), there's ~90% chances to be pointed to the right track of it - yes, almost all bugs are pretty fast to catch, even with manual tests, let alone automatic ones.
3:03, agree. I use only FP, until I find that some variable would potentially create a mess, if changed on the wrong place. Only then I start to use class, to both protect and control that var. This is fast to type (not bloated with unnecessary classes) and easy to test (mostly f()s). And even if an environment of classes state needs to be tested, through macros (plus C++ concise syntax declarations) it's possible to compress wonderfully an entire situation (several classes) in 1 automated test, maybe in a single line, if lucky! And that conciseness encourages to write more tests.
1
-
8:56, true. I think my spaghetti code is clean, readable and kind beautiful. But it's just me.
11:53, performance uses to fight vs all others. So if a code got kind ugly, on an apparent necessary extent to deal with performance, I don't take it as ugly. I think a code should be judged having its goals in mind. Example: Rust or C++ specifiers, to get data fit into safety constraints, is not ugly.
17:20, I think they are bad when they expose content that should be "private" of a bigger f(). Otherwise, I think it's good to not pass 1 screen. Spaghetti style helps with that.
18:14, using IDEs, just leave mouse over the abstraction, and it shows what the abstraction means, how it was declared at least (enough for macros, lambdas, types).
21:13, well, if I had the chance to refactor it, I use to be satisfied for years.
22:59, spaghetti code is the right tool for the job. :elbowcough:
1
-
1
-
1