Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jai Language Primer

github.com

Post reply on HN
Print view View original

61–70 of 102 posts

Re: Jai Language Primer

#61

Post by pandaman »

gregstula wrote: post #55
pandaman wrote: post #46

Earlier quoted context omitted.

Games (I am talking about AAA here, have no idea about all possible games) are not written in the style that leaves place for constructors/desturctors. The data is better in tables (i.e. arrays) than spread all over the memory and accessible through a pointer network. The reasons being: a) walking an array is orders of magnitude faster than walking a pointer chain and b) heap allocation wastes more memory This, in tu…

Why couldn't you use a structure to encapsulate the table and then have the destructor to deallocate the the array? This is how vector works.

You could, but why? To compensate for the lack of construction/destruction of the array's elements?

Practically these arrays never go away so there is little point in deallocation anyways.

Re: Jai Language Primer

#62

Post by ilek »

gregstula wrote: post #21
ilek wrote: post #17

Earlier quoted context omitted.

Out of interest, why do you think the Handmade Hero code is atrocious? I haven't kept up with it so I don't have much of an opinion.

It's gross because it's written in "C with namespaces and overloading" Preferring #define for constants over constexpr is 100% the result of C++ bigotry. It's a laughable decision. constexpr gives you the power of typesafe, compile time evaluation of purely functional expressions with type deduction. #define gives you a compile time 1972-style copy-paste

I agree with things like these, I think Casey and other programmers like him are too far in the camp of C++ is just C with classes.

From what I have seen of the code and videos, I think his general structure of programs is off. I'm no advocate of "every function has to be at max N lines" or "every file has to be smaller than N lines". But I think there are issues there, and I don't think it can be defended just because it's a game, where a lot of general practices go out the window.

Re: Jai Language Primer

#63

Post by ilek »

w0utert wrote: post #23
ilek wrote: post #17

Earlier quoted context omitted.

Out of interest, why do you think the Handmade Hero code is atrocious? I haven't kept up with it so I don't have much of an opinion.

Listing all the things bad about it would take me the rest of the afternoon, and likely evoke many replies along the lines of "you don't understand why he does it that way, it's supposed to be handmade, so you can't have all the nice things", like last time I commented about the HH code. The executive summary would be that the code is basically full of unsafe code, pointer chasing, half-hearted argument/input validit…

Yeah from what I've seen I've noticed he jumps around a lot putting out fires when he changes anything. Like I said in another reply, he's too far in the camp of C++ being C with classes.

I think the sad thing will be people are learning C/C++ from him and so will try and program anything in these languages like this.

Re: Jai Language Primer

#64

Post by autoreleasepool »

pandaman wrote: post #61
gregstula wrote: post #55

Earlier quoted context omitted.

Why couldn't you use a structure to encapsulate the table and then have the destructor to deallocate the the array? This is how vector works.

You could, but why? To compensate for the lack of construction/destruction of the array's elements? Practically these arrays never go away so there is little point in deallocation anyways.

If you're using C++ you're still using default destructors even if you don't write them. In C, you at least get deterministic destruction for variables and structures on the stack. This isn't something you really opt out. It's there by default.

The parent was wrong about vector though, it won't safely free elements that do not have their own destructors to clean up their own resources. Another good reason to use RAII everywhere. It costs nothing, to encapsulate memory management.

> You could, but why?

Because there's zero overhead and you guarantee to be passively covered in the few edge cases where you do end up needing deallocation. Now you don't have to worry about special handling of edge cases and you have a more general purpose data structure.

A better question is, why not?

It's simply a better designed and more flexible container than a raw array. Other than a bias against C++isms, there's no good reason to avoid these useful features.

Re: Jai Language Primer

#65

Post by pandaman »

autoreleasepool wrote: post #64
pandaman wrote: post #61

Earlier quoted context omitted.

You could, but why? To compensate for the lack of construction/destruction of the array's elements? Practically these arrays never go away so there is little point in deallocation anyways.

If you're using C++ you're still using default destructors even if you don't write them. In C, you at least get deterministic destruction for variables and structures on the stack. This isn't something you really opt out. It's there by default. The parent was wrong about vector though, it won't safely free elements that do not have their own destructors to clean up their own resources. Another good reason to use RAII…

Default destructors are fine since they don't produce any code as long as you don't have any real destruction going on.

>There's zero overhead and you guarantee to be covered in the edge cases where you do end up needing deallocation.

If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible than have it covered. E.g. I prefer game crashing on out of memory rather soon than going on with thrashing the heap till it crashes 8 hours into the soak test due to the heap fragmentation.

>It's simply a better designed and more flexible container than a raw array.

Tastes differ. I ship games myself and almost all programmers I know do the same. I don't know anybody who would agree with this. Just to be clear, I am talking about destructor of an array. Wrapping arrays in structures is fine and everybody does this.

Re: Jai Language Primer

#66

Post by gregstula »

pandaman wrote: post #65
autoreleasepool wrote: post #64

Earlier quoted context omitted.

If you're using C++ you're still using default destructors even if you don't write them. In C, you at least get deterministic destruction for variables and structures on the stack. This isn't something you really opt out. It's there by default. The parent was wrong about vector though, it won't safely free elements that do not have their own destructors to clean up their own resources. Another good reason to use RAII…

Default destructors are fine since they don't produce any code as long as you don't have any real destruction going on. >There's zero overhead and you guarantee to be covered in the edge cases where you do end up needing deallocation. If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible th…

> I don't know anybody who would agree with this.

std::array is better than int arr[ARR_SIZE]

I don't know how you could disagree with that after looking at the facts. From what you're saying here, there seems to be a culture that favors "old school" C programming in games, but the reasons behind it seem like nothing more than a fear of the unknown. I don't mean to be disrespectful, it just seems like nothing but stubbornness to me.

> Just to be clear, I am talking about destructor of an array

Can you be clear about why this is bad?

Re: Jai Language Primer

#67

Post by [deleted] »

autoreleasepool wrote: post #64
pandaman wrote: post #61

Earlier quoted context omitted.

You could, but why? To compensate for the lack of construction/destruction of the array's elements? Practically these arrays never go away so there is little point in deallocation anyways.

If you're using C++ you're still using default destructors even if you don't write them. In C, you at least get deterministic destruction for variables and structures on the stack. This isn't something you really opt out. It's there by default. The parent was wrong about vector though, it won't safely free elements that do not have their own destructors to clean up their own resources. Another good reason to use RAII…

[deleted]

Re: Jai Language Primer

#68

Post by pandaman »

gregstula wrote: post #66
pandaman wrote: post #65

Earlier quoted context omitted.

Default destructors are fine since they don't produce any code as long as you don't have any real destruction going on. >There's zero overhead and you guarantee to be covered in the edge cases where you do end up needing deallocation. If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible th…

> I don't know anybody who would agree with this. std::array is better than int arr[ARR_SIZE] I don't know how you could disagree with that after looking at the facts. From what you're saying here, there seems to be a culture that favors "old school" C programming in games, but the reasons behind it seem like nothing more than a fear of the unknown. I don't mean to be disrespectful, it just seems like nothing but stu…

>std::array is better than int arr[ARR_SIZE] I don't know how you could disagree with that...

What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping.

>Can you be clear about why this is bad?

Useless code at best (if your game runs properly it will never be deallocated by your code), obscuring bugs at worst (if it starts deallocating at runtime it will take longer to fail).

Re: Jai Language Primer

#69

Post by autoreleasepool »

pandaman wrote: post #65
autoreleasepool wrote: post #64

Earlier quoted context omitted.

If you're using C++ you're still using default destructors even if you don't write them. In C, you at least get deterministic destruction for variables and structures on the stack. This isn't something you really opt out. It's there by default. The parent was wrong about vector though, it won't safely free elements that do not have their own destructors to clean up their own resources. Another good reason to use RAII…

Default destructors are fine since they don't produce any code as long as you don't have any real destruction going on. >There's zero overhead and you guarantee to be covered in the edge cases where you do end up needing deallocation. If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible th…

> I'd rather have it fail with as much noise as possible than have it covered...

RAII is orthogonal to contiguous storage in memory. You are not opting into heap fragmentation by moving your "dealloc struct" function from the global namespace to a destructor. It has nothing to do with the the memory layout. It has to do with preventing memory leaks and undefined behavior.

Re: Jai Language Primer

#70

Post by gregstula »

pandaman wrote: post #68
gregstula wrote: post #66

Earlier quoted context omitted.

> I don't know anybody who would agree with this. std::array is better than int arr[ARR_SIZE] I don't know how you could disagree with that after looking at the facts. From what you're saying here, there seems to be a culture that favors "old school" C programming in games, but the reasons behind it seem like nothing more than a fear of the unknown. I don't mean to be disrespectful, it just seems like nothing but stu…

>std::array is better than int arr[ARR_SIZE] I don't know how you could disagree with that... What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping. >Can you be clear about why this is bad? Useless code at best (if your game runs properly it will never be…

> What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping.

Guaranteed to be contiguous, and semantically equivalent to a C array in all cases.

If you don't trust your vendor's STL implementation take a look at the intrusive containers in EA's STL implementation. It's very very good for games. It's also safe, which is a good thing that doesn't obscure bugs it all.

https://github.com/electronicarts/EASTL

> e.g. can the GPU read from it at all? Can it write? What are cache policies?

Fun fact, you can write your own template container with specific features with no additional overhead from a C "array" that's also memory safe.

> if it starts deallocating at runtime it will take longer to fail).

It can't magically deallocate at runtime. It's deterministic. I don't think you understand you give up zero control. It's just a cleaner system with less room for human error.

> obscuring bugs

What's obscure about knowing exactly where are all memory management occurs without exception? C-style malloc and free scattered all over the project is way more prone to hiding bugs.

Post reply on HN