My C++ standard library & its "reddit discussion"

I recently released my personal, minimal C++ standard library alternative and I thought I share it for others who may like to use it too. It's still experimental and in development.


I got quite a bad slash for saying I was not using OOP at all (except in one cast which I may change later to not be) and that I thought that OOP was never the best tool for the job.

Reddit Post - Minimal C++ standar... geared towards game development.

Some people were agreeing with me but in general, most were not. I don't know if I was defending my case very well or not. I know everyone's opinion differs and I probably have a different opinion to most people on /r/gamedev (this is probably because most people are C#, Java, and other OOP-language developers).

The main discussion was not really about the library but my stance on OOP. Even if I didn't talk about why I didn't use OOP, someone was most likely to ask why something wasn't a method.

I was wondering what you guys thought about this "discussion", if my reasons were valid or not, and if I was just arguing to the wrong crowd.

Regards,
Bill

and his rant

Edited by Ginger Bill on
I think there's a certain amouint of Stockholm Syndrome and reflexively defending of things you've spent a lot of time doing. So rather than wondering why someone might dislike OOP, people jump the gun and argue that you must be using it wrong.

I'm knee-deep in working on handmadedev.org, so I haven't had the time to look through either your code or that thread in detail, but it wouldn't surprise me if that's what's going on.

It's not that different from the trouncing Leonard Ritter (Paniq) got on Reddit when introducing his Lispy language called None. Most people didn't want to discuss the language at all, or why it might be useful and in what circumstances. Instead they just vented their preconceptions about Lisp and concluded it couldn't possibly have any use. It seems to be a bit of a Reddit thing to not look beyond your own little part of the universe and conclude everyone else must be doing it wrong.
Yeah I don't think you want to argue with OOP-heads. If someone is at the point where they still think Object Oriented Programming is good, then you know already that they aren't far enough along in understanding programming. So it's usually best to either let them go along their way and continue to program poorly, and either A) never hear from them again, or B) hear from them when they finally come to the realization later :)

- Casey
On another note, I was having a discussion with someone about the performance of my gb::Array<T> vs std::vector<T> for POD types. It turns out that gb::Array<T> is about 3 to 8 times faster in debug mode than std::vector<T> (-Od -MDd -EHsc) (using malloc).

With the compiler optimizations on (-O2 -EHsc), std::vector<T> was faster by about 2 times for smallish allocations (<10000 ints) but slower for larger allocations (>10000 ints).

I think this is probably due to std::vector has numerous optimizations at the small allocation end.

If you reserve the allocation before hand, they are virtual identical in terms of performance (which I hope so).

---

I just hope OOP fades soon and people realize that there are much better approaches. I cannot wait for Jon's language as it already makes things so much better!



Regards,
Bill
Bug in comments:
1
defer (fclose());

should be:
1
defer (fclose(file));


This seems very wrong:
1
2
3
4
5
6
7
internal_linkage void*
thread_proc(void* arg)
{
	local_persist s32 result = -1;
	result = thread::run(static_cast<Thread*>(arg));
	return (void*)&result;
}

If result value will be used by somebody (pthread_join) then this is a race condition. You could move result into Thread class to avoid race condition. Or if result value is not supposed to be used then what's the point returning something else than 0?

Edited by Mārtiņš Možeiko on
Thanks for catching the typo.

With regards to the Thread design. I cannot believe I did this but I have been working with windows so I haven't really tested the POSIX code really.

Would you think this a better idea:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
using Thread_Function = void(void*);

...

internal_linkage void
run(Thread* t)
{
    semaphore::post(&t->semaphore);
    t->function(t->data);
}

#if defined(GB_SYSTEM_WINDOWS)
internal_linkage DWORD WINAPI
thread_proc(void* arg)
{
	thread::run(static_cast<Thread*>(arg));
	return 0;
}

#else
internal_linkage void*
thread_proc(void* arg)
{
	thread::run(static_cast<Thread*>(arg));
	return nullptr;
}
#endif


This would remove the race condition. I think I will have to implement some sort of `pthread_exit()` abstraction as that was the whole point of the return value.
Yeah, that looks fine.
Had a quick look at the code and noticed comments in the assert macro. Instead of deref null ptr for break you can use __debugbreak() with msvc, and __builtin_trap() with gcc.