On 4/8/23 20:19, Thiago Macieira wrote:
> On Saturday, 8 April 2023 20:51:26 -03 Phil Bouchard wrote:
>> Well I just mentioned the problems (security, efficiency, robustness,
>> ..). Here are the solutions:
>>
>> 1) Well for the security part solved by C++ Superset, here's its
>> documentation:
>> https://www.fornux.com/files/pdf/Superset_Manual.pdf
>>
>> But C++ Superset is patented and commercial so I don't expected to make
>> it part of the standards
>
> Thanks for the warning. That also means I can't even open that link.

It is license-based so I can easily activate a demo license for a few
months in Linux, MacOS or Windows. Right now it's based on Clang 12 and
I'll need to update it but for a demo it's good enough.

>> 2) For low latency FIFO containers we can integrate the following one:
>> https://github.com/philippeb8/cplusplus-overload-new
>
> You still have yet to explain *how* this solution addresses the problem. This
> is what I am saying that you're jumping from "there's a problem" to "here's a
> solution, trust me it works". The "trust me" isn't enough for this forum or
> for the standards committee. You'll have to write a rigorous paper explaining
> just how it works, how it solves the problem, what the drawbacks are, and how
> it's better than other possible solutions or at least why this solution should
> be adopted now instead of those others. This forum can help you with that, but
> *you* have to start with the evidence and lines of thought.

Ok well I can write a better presentation with benchmarks, etc. then. I
still have my day job, groundbreaking research in astrophysics and
another company I'm part of but I'll find some time.

>> It is still incomplete as it lacks a simple subtraction for deallocated
>> blocks but you get the idea.
>
> I"m reading "I haven't proven it works in real life, let alone that it solves
> the problem."

Depending on the importance of the benchmarks I'll get I can contact
with the finance sector and let them test drive it for deployment.

>> It is 3.6 times faster under Linux so I expect an even greater standard
>> deviation under Windows.
>
> Faster than what? What workloads? Under what conditions? Compared to what
> other solutions?

Faster than the standard malloc() for consecutive allocations
specialized for thread-local FIFO containers.

>> 3) I know C++ hash maps are very slow and all companies requiring fast
>> hash maps replace the standard one. So some attention should be put there.
>>
>> Even Linus Torvalds would stop complaining C++ is fixing the wrong
>> problems because he's definitely right.
>
> No, he wouldn't. I've met him and I have discussed C++ with him. He won't stop
> complaining about C++.
>
> That isn't to say he's wrong; he does have some valid points. But he says
> isn't gospel. Heck, what Bjarne says isn't gospel either.

That is why I hope to contribute to help improve C++ from my own
experience. I seriously believe we need to turn the page on memory bugs
in 2023 and scale up the framework and design of C++ so we can write
more complex code at a higher level more easily.

Python offers that but its core design is hopeless and is much slower
than C++ by far. Nonetheless the AI industry chose Python because of that.


Thank you,

-- 
Logo <https://www.fornux.com/>  
*Phil Bouchard*  facebook icon
<https://www.linkedin.com/in/phil-bouchard-5723a910/> 
CTO
T: (819) 328-4743
E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada
Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les
documents l'accompagnant, sont destinés uniquement aux personnes
identifiées et peuvent contenir des informations privilégiées,
confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce
message par erreur, veuillez le détruire.
This communication (and/or the attachments) is intended for named
recipients only and may contain privileged or confidential information
which is not to be disclosed. If you received this communication by
mistake please destroy all copies.