Use clang-format, they said!
Updated my
.clang-format and ran it on all the files, it broke a lot of things.I had to spend hours going through all the changes one by one.
After doing this, I surprised myself; I didn't expect to have written this much code over the past few years.
Turns out I missed some bugs: the issue
My tests are crashing,
- but only in clang, (reasonable, right?)
- and not if each unit test run individually (but, how??)
How does it know I'm filtering the tests?
- but only in clang, (reasonable, right?)
- and not if each unit test run individually (but, how??)
How does it know I'm filtering the tests?
Truth will prevail after I force some gdb/lldb serum down its throat.
👍1👀1
Web++: A C++ Web Framework
My tests are crashing, - but only in clang, (reasonable, right?) - and not if each unit test run individually (but, how??) How does it know I'm filtering the tests? Truth will prevail after I force some gdb/lldb serum down its throat.
This media is not supported in your browser
VIEW IN TELEGRAM
Upgraded it to crash on GCC as well 😅
Oooph, that's it for today 😬
Oooph, that's it for today 😬
😁1
2 problems with using standard containers with stack-based allocators:
1. No allocator, or resource exists for it that's not monotonic (
2. Containers allocate more than needed, thus making it hard to guess the stack size
Writing a memory resource like
But for the second problem, any solve for that requires knowledge of the containers being used which means tightly coupling the containers with the stack size being used which is not a good solution in my opinion.
What do you think?
Compiler Explorer link 1
Compiler Explorer link 2
1. No allocator, or resource exists for it that's not monotonic (
monotonic_buffer_resource that actually deallocates)2. Containers allocate more than needed, thus making it hard to guess the stack size
Writing a memory resource like
monotonic_buffer_resource that does deallocate is not that hard (I might write one), so the first problem is easily resolvable.But for the second problem, any solve for that requires knowledge of the containers being used which means tightly coupling the containers with the stack size being used which is not a good solution in my opinion.
What do you think?
Compiler Explorer link 1
Compiler Explorer link 2
Web++: A C++ Web Framework
2 problems with using standard containers with stack-based allocators: 1. No allocator, or resource exists for it that's not monotonic (monotonic_buffer_resource that actually deallocates) 2. Containers allocate more than needed, thus making it hard…
Huh,
monotonic_buffer_resource is the one with growth factor! I did not expect this one at all!I pretty much removed my whole allocator-pack system just because I forgot to add
I totally wouldn't have done it if I knew the problem had nothing to do with allocators, but I'm happy I removed a ton of complicated allocator-related code!
This pains me, I really spent too much time developing the allocator pack idea but now I had to remove it.
std::initializer_list there.I totally wouldn't have done it if I knew the problem had nothing to do with allocators, but I'm happy I removed a ton of complicated allocator-related code!
This pains me, I really spent too much time developing the allocator pack idea but now I had to remove it.
👍2
Well sh*t, one of these again!
I'm not getting that on my local machine though, should I ignore? 😅
I'm not getting that on my local machine though, should I ignore? 😅
I wasted hours debugging this.
The bug?
I named it
If you name a type
But, if that's true, statements like these will fail because they expect the constructor to take an allocator as well, but you haven't defined one:
The bug?
I named it
allocator_type instead of literally anything else.If you name a type
allocator_type, it'll make this statement true:std::uses_allocator_v<TYPE>
But, if that's true, statements like these will fail because they expect the constructor to take an allocator as well, but you haven't defined one:
std::allocator_traits<allocator_type>::construct(alloc, ptr, new_val);
stl::make_obj_using_allocator<T>(alloc, args...);
So, DON'T NAME YOUR TYPES allocator_type without providing constructors accepting allocator of that type!.
Web++: A C++ Web Framework
The story went on to the point that I made a template new type called "dynamic" which is an allocator-aware type. The problem that I got with it right now is that where I tend to use that type is where the 1th template parameter will be an incomplete type.…
After a year of dilemma, I made an "initialize" tag to get around this issue, it makes more sense this way because I also want the "dynamic" to
1. default construct the object
2. and still not construct anything if the type is incomplete
I initially wanted
to point to
to default construct
It is possible to have the second example the default too and for the first example do something like this:
Which one do you think is better? and why?
-
-
1. default construct the object
2. and still not construct anything if the type is incomplete
I initially wanted
dynamic<incomplete_type> obj;
to point to
nullptr, whiledynamic<complete_type> obj;
to default construct
complete_type; but that seems confusing for users, so I HAD TO make the effect of the first example the default.It is possible to have the second example the default too and for the first example do something like this:
dynamic<incomplete_type> obj{no_init};Which one do you think is better? and why?
-
initialize tag?-
no_init tag?
Web++: A C++ Web Framework
Huh, monotonic_buffer_resource is the one with growth factor! I did not expect this one at all!
Turns out I was wrong about monotonic buffer resource.
It seems I was wrongly assumed that growth factor is being used inside "do_allocate", it's not; so it's not monotonic's fault that we can't know the required size.
I had to re-check the monotonic buf res's implementation and write a few tests.
Tweet Link | Compiler Explorer Code | Source Code of the tests
Do you have a cooler way of optimizing away certain cases of a switch statement with an if-constexpr?
These things affect the generated assembly.
These things affect the generated assembly.
Parsing IPv4 in a host of a URL requires different algorithm than the good old
So I now have both of them implemented; of course I have to benchmark them.
Turns out on GCC, the newly URL's Host's IPv4 Parser is faster; which is just weird to me since the IPv4s in the URLs are looser and have a bit more features (which I don't think they should have in the first place).
The IPv4s in the URLs:
- can have Hexadecimal numbers
- can have Octal numbers
- the last octet can hold the value of the remaining ocets
This means, all of these are invalid in
inet_pton4 (which I have implemented before).So I now have both of them implemented; of course I have to benchmark them.
Turns out on GCC, the newly URL's Host's IPv4 Parser is faster; which is just weird to me since the IPv4s in the URLs are looser and have a bit more features (which I don't think they should have in the first place).
The IPv4s in the URLs:
- can have Hexadecimal numbers
- can have Octal numbers
- the last octet can hold the value of the remaining ocets
This means, all of these are invalid in
inet_pton4, but valid in the URLs:"0000000.0.0.0"
"0x000000.0.0.0"
"0X0000.0x.0.0"
"0"
"0x"
"0X
"00000"
"0x0000"
""
"."
"127.0.0.1"
"0x7f.1"
"0x7f000001"
"0x0000000007f.0x1"
"127.0.0x0.1"
"127.0x0.0x0.1"
"127.0x0.0x0.0x1"
"127.0.0x0.0x0001"
"0x7f.0x0000001"
"0x0007f.0x0001"
"0x007f.0.0x00001"
"0x7f.0.0.0x1"
"0x7f.0.0x000.0x1"
"2130706433"
"127.1"
"127.0x00.1"
"127.0x000000000000000.0.1"
"000123"
"0xff"
"1.256"