On Wed, Sep 17, 2014 at 06:29:01AM +0200, Christoph Lohmann wrote: > On Wed, 17 Sep 2014 06:29:01 +0200 Maxime Coste <frrr...@gmail.com> wrote: > > On Tue, Sep 16, 2014 at 11:02:40PM +0200, Christoph Lohmann wrote: > > > This is programming and not your playground. Avoid fancy code. > > > > I guess that is a matter of taste, I just know m1 + m2 calls > > operator+(Matrix, Matrix). > > Which is, like in other answers stated, not obvious. You have to look up > the definition to read the source. Hint: Here complexity in the system > can be avoided completely.
In what exactly is that different from seing mat_add(m1, m2, &m3) ? you see m3 = m1 + m2, you know a + b is syntactic sugar for operator+(a, b). That is all. It seems to me that you are saying 'to someone used only to C, C++ operator overloading is confusing', on that I can only answer yes, as pointer arithmetic is confusing for people not used to C or C++. > > What is your strategy in C when you need to apply the same logic on > > different types ? > > That doesn’t happen that often to justify overloading. Hint: Avoided > complexity in the system *beforehand*. That goes back to the linked list/array thing, you dont have generics, so you use the easy thing without generics: linked lists, which are almost always a poor choice. > > > > > Get your complexity right, inserting in a dynamic array is O(n), the > > > > eventual > > > > need for an allocation is amortized (whereas you always end up doing a > > > > malloc > > > > for your linked lists). Another thing you should look up is modern cpu > > > > architectures and caches, in practice the much better locality of > > > > reference > > > > of arrays makes them *way* better on operation like insert/erase in the > > > > middle > > > > than lists even though complexity theory says otherwise. (Remember, > > > > complexities > > > > are asymptotic, you need huuuuuge number of elements). > > > > > > When you work close to the metal much of your theory can be optimized > > > out. I won’t tell you how. > > > > The best you can do is store your linked list in an array, and sort it at > > certain > > point so that elements end up linearly in memory. But when you've done that > > you > > already have a dynamic array implementation. > > No, the best is to apply whichever data structure you need at the mo‐ > ment. Discussing which array to use makes no sense without the actual > problem defined. As I said, in practice you almost always have better performances with dynamic arrays than lists, hence it should be your default list structure. But as it is a pain to implement in C, because you cannot implement it generically, linked lists stay the default implementation. > You are too young, if you think .NET is the problem. The problem arose > before that with C++ in the Windows world and X11 in Unix. Let’s see > which wrong logic answer you will apply to the last argument. Yay, X11 is a well known C++ program. Seriously, there are a lot of bad design decision in Windows, as there a are a lot in modern linux userland, and they do not seems to stem from the implementation language. the 90s where the time of OOP everywhere, and we learned a lot since them. But rejecting the tools because they were overused makes no sense. the C for construct can be overused as well, we now have guidelines on that, and they are not 'for loops are evil'. > Conclusion: You try to force your work experience into the suckless phi‐ > losophy, which does not work due to different basic principles. Next you > are fail to accept that reading source code in Open Source is more im‐ > portant than your abstraction of reusing code between hating and oppor‐ > tunity‐seeking programmer groups in corporate lifes. Please come down > from your throne. I'm merely trying to defend the fact that I would like to post about a C++ project on the suckless mailing list and have it judged on its own merits rather than on dogmatic ideas about its implementation language. Cheers, Maxime.
