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"
These two URLs result in different strings generated!
WHATWG is written by idiots.
Browsers are doing their own thing btw!
file://localhost/path/to/somethere
file://127.0.0.1/path/to/somewhere
WHATWG is written by idiots.
Browsers are doing their own thing btw!
😁1
WHATWG mindset:
-
-
-
file::::::: totally valid URL-
http:: hold on, that's not valid at all!😁2🔥1🤣1
This is a valid WHATWG URL with a hidden "Hello World" binary message encoded within:
-
-
-
/ is 1-
\ is 0https:/\\//\\////\\\\//\\/\\/\\\\/\\\\///\\\\/\\\\///\\\\/\\\\\\\\//\\//////\\/\\/\\\\\\/\\\\/\\\\\\\\/\\\\\\//\\//\\\\/\\\\///\\\\//\\//example.com👍1
I don't know whom is to blame, but this is a valid URL:
fILe://C|\\//\////\\\\/\/\/\\\/\