Live data from Hacker News

Understanding the Odin programming language

odinbook.com

161–163 of 163 posts

Re: Understanding the Odin programming language

#161

Earlier quoted context omitted.

> Also one separate function being different than the operator is not a language level feature, it is how that one library data structure is made. That's not so much the point: the point is that even when calling a regular method conveniently as ptr->methodname() , you are calling the method name not on a pointer expression but on a value expression. ptr->methodname() is effectively (*ptr).methodname() .

That's not so much the point: It is the point since you compared two things that have different uses, then said you can't call an operator on a pointer, which is wrong.

[deleted]

Re: Understanding the Odin programming language

#162

Earlier quoted context omitted.

> Also one separate function being different than the operator is not a language level feature, it is how that one library data structure is made. That's not so much the point: the point is that even when calling a regular method conveniently as ptr->methodname() , you are calling the method name not on a pointer expression but on a value expression. ptr->methodname() is effectively (*ptr).methodname() .

That's not so much the point: It is the point since you compared two things that have different uses, then said you can't call an operator on a pointer, which is wrong.

You don't get it. That's because you still don't understand some basic things about the language. There is no method call here on a pointer expression. There is only a call on a value expression.

Re: Understanding the Odin programming language

#163

Earlier quoted context omitted.

> Again you can make these bold statements but saying pointer chasing has no performance impact is what people say when they don't understand the cost of TLB misses and caches misses. You are right to call this out but I did not mean to imply that it would not increase load on the cache at all . The most important optimization is keeping data structures simple, flat, and coherent. Making many micro optimizations can…

If you blindly embed everything by value religiously, you deserve neither flexibility nor correctness nor performance. I don't know what 'deserve' is supposed to mean, but I just showed how to get all three. don't forget to group data by access patterns and write patterns Values on the stack are going to be grouped together and they are going to be in cache. You realize using two heap allocations means twice the free…

You don't understand even the first things of what I say. That's because you apply beginner level concepts and understand to argue, and are not looking for nuance or deeper understanding at all.
Post reply on HN