OSDN -- Develop and Download Open Source Software

Forums: Developers (Thread #44440)
Return to Thread list RSS

C++ Language Design (2021-07-26 17:47 by quiret #87801)

Today I have found out about P0401R6 of the C++23 draft. You can find it here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0401r6.html

My interpretation: add a library call for memory requests of at-least n bytes, putting the burden of look-ahead allocation on memory allocator implementers.

My opinion: terrible design decision. Advancing this idea to the memory allocator interface would open ways for strange performance differences based on compiler and CRTs, unpredictably so. The MSVC CRT has a long-standing approach of actually GROWING memory in-place, and if that fails going the new-allocation route. But no, don't you misunderstand it, it is not the same as the realloc function call, go research _expand from the MSVC CRT! The developer does get a boolean-feedback if the growing-inplace has succeeded or not, then he can issue a subsequent new-allocation with move-semantics to keep the C++ rules in-check! IMO this is a much better design idea but strange shit does find it's way into the C++ language sometimes anyway. Just like in every software it will take some time to temper and will fade out.

The developer should be poked to make a guess at how much he would need because HE CAN DO THE SMART MATH! Randomly guessing what the developer would need is a terrible fate. My guess is that those strange people that think allocation of 2^n blocks for encapsulation is best approach, those people are driving this addition to the language... I whole heartedly disagree.

How about actually taking ideas from MSVC for once, C++ committee???

NOTE: whenever I talk about PR in this thread, substitute it with "Paper for Review".
(Last Update: 2023-01-17 00:33 by quiret)

Re: C++ Language Design (2021-09-15 21:20 by quiret #88044)

I wonder if the C++ concepts are meant to be friendship-boundary resistant. According to the C++20 friend statement description on cppreference.com, you cannot befriend a concept. But then there are concepts like this one:

https://en.cppreference.com/w/cpp/concepts/constructible_from

According to that website, the std::constructible_from concept depends on the struct/class std::is_constructible_v but this struct is not friendship-boundary resistant. For example, you could have class A and B which are friends of each-other and B has its constructors private. If A where to query B if it can construct it using some parameters, std::is_constructible_v MUST return false because the struct or class has no access to B's constructors. But I wonder, since you cannot befriend concepts, this access denial should not happen by using std::constructible_from? The access check should be done against the location of where the concept is being used and not the point in the source where the concept was defined.

What about it?
Reply to #87801

Re: C++ Language Design (2021-12-17 05:11 by quiret #88407)

The C++ template system is very powerful for designing reusable code. Inside of my upcoming machine code compiler I want to make use of the C++ template grammar. Find out my rationale here:

https://forum.mtasa.com/topic/132061-lua-to-machine-code-compiler-interest-poll/?do=findComment&comment=1004392
Reply to #87801

Re: C++ Language Design (2022-02-11 01:17 by quiret #88713)

I did post an argument about a design flaw of the C++ sizeof unary operator where requiring it to be a multiple of the type's alignment is not architecturally necessary. With this unnecessary requirement there come burden to both the memory footprint as well as the performance of programs. You can read about my argument here:

Heading: No architecture requirement for sizeof to be multiple of alignment
https://en.cppreference.com/w/Talk:cpp/language/sizeof
Reply to #87801

Re: C++ Language Design (2022-12-16 04:52 by quiret #93007)

It is seldom that I trash about Microsoft's products, especially because I am an understanding person and such an understanding C++ developer. Across the years I learned to love the passion that Microsoft has put into their C++ language vision. The compiler did help me debug a lot of Win32 software and then also port it over to other platforms, making use of their amazing debugging solution to test my models for their correctness to only let platform implementation differences come into my way.

But today I was thoroughly DISGUSTED by the BACKWARDS QUALITY CONVERGENCE of the MSVC C++ compiler! Some months ago I was able to compile my Eir SDK just fine. Since I am using very advanced C++20 concepts statements and logical flows that not many people use, the developer genius that I am, I tend to hit the limits of C++ compilers. I had my stressful times with GCC aswell. But the company I adore deserves the biggest punishment.

> // Fuck off, MSC. You seriously annoy me!
> static inline eCompResult CompareNodes( const AVLNode *left, const AVLNode *right ) _MSVC_BUGFIX(noexcept(std::is_nothrow_invocable <decltype(compare_values <valueType, valueType>), valueType, valueType>::value))
> {
> const ValueNode *leftNode = AVL_GETITEM( ValueNode, left, sortedByValueNode );
> const ValueNode *rightNode = AVL_GETITEM( ValueNode, right, sortedByValueNode );
>
> return compare_values( leftNode->value, rightNode->value );
> }

That code above from Set.h was compiling JUST FINE MONTHS AGO! Now I am left with a compiler message that deciphers as: "I am a compiler and I don't understand how to interpret your code correctly." If I use avlKeyNodeDispatcher::compare_values then I get an ICE, internal compiler error, even! I don't have the time to play the testing monkey for that big company.
Reply to #87801

Re: C++ Language Design (2022-12-21 02:30 by quiret #93059)

Have you heard about the static_if proposal that was talked about some years ago? The gist of it was that code graph segments could be excluded from compilation without being verified correct. This would allow changes to the code based on compile time deducible attributes. You can get the best gist of it by viewing this video as part of the GoingNative series:

https://www.youtube.com/watch?v=rAeGMZNTdJY

A lot of developers may have gotten in love with the constexpr-if statement that made it's way into C++17. It allows developers to select between two code graph branches - true-branch or false-branch (which can be empty) - without evaluating their contents. With the advent of smarter C++ compilers where compile-time transformation of code graphs has become the norm, I am missing a great feature that static_if would have introduced: the injecting-into-parent {} region. Deciphered as putting objects as part of a scope but said scope would inject all contents - if evaluated - into the parent scope. Now this would be great when paired with an if statement that works at object-scope, for example:

> object_if (datamode == 0) {
> int data = 0;
> }
> else {
> float data = 0;
> }
> // the data variable is now visible in this scope, it is part of this scope and will
> // perish once this scope perishes.
>
> data++;
> return data;

Would be great if the C++ community could think about generalizing the language even further. It would help the professionality of the language a lot.
Reply to #87801

Re: C++ Language Design (2023-01-05 22:43 by quiret #93256)

Have you ever heard about constexpr-deducibility for C++ code evaluation? Compilers perform this to "optimize" code - a monkey's ass word for choosing a better machine representation from a starting code-graph. The current C++20/whatever standard does not support this concept but it has all the required tidbits in place to unrestrict it's evaluations and allow for big language-design-wise performance boost. Consider the following GCC example (GodBolt link https://godbolt.org/z/KKPP3Tasd):

> #include <stdint.h>
>
> constexpr uint32_t ROL(uint32_t a, uint8_t cnt)
> {
> if ( __builtin_is_constant_evaluated() )
> {
> return (a<<cnt) | (a>>(sizeof(a)*8u - cnt));
> }
> else
> {
> asm("ROL %b1,%k0" : "+r" (a) : "ci" (cnt));
> return a;
> }
> }
>
> int main()
> {
> uint32_t val = 123;
> uint8_t cnt = 2;
>
> val = ROL(val, cnt); // evaluated as non-constexpr in currently-latest C++,
> // but should be constexpr-deducible and thus optimized (the compiler cannot currently do this)
>
> return (int)val;
> }

Using constexpr-deduction the code above would transform to a constant integral value returned inside the main function. It would the following adjustments in the language design:

1) officially endorse promotion of if-statements with constexpr condition evaluation as constexpr-if
2) promote variables initialized by constexpr input as constexpr variables

I can imagine that debugging environment would not want this so the C++ language needs to introduce a new concept called "language design-time configurability", in this case a third adjustment is necessary:

3) design-time input parameter "constexpr-deduction-enabled"

Please consider my idea for future revisions of the C++ language.
Reply to #87801

Re: C++ Language Design (2023-01-08 18:35 by quiret #93301)

Reply To Message #93256

While researching a similar concept called "implicit-constexpr" which does not take it as far as my constexpr-deduction I stumbled upon this bold investment by GCC: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=87c2080b The introduction of the -fimplicit-constexpr attribute ammends the "constexpr" specifier to inline functions. And then it dawned upon me that restricting constexpr ammendment to already-marked-as-inline functions is a really natural and conservative idea! It would help platform C++ specializations where functions exist behind ABI boundaries, not inlinable. See constexpr-deduction as further encouragement to invest into code-generation, the effects of embedding a code-graph directly into another, realizing the compile-time transformations in effect for optimal code-gen. I hope you get the huge potential for the future of C++!
Reply to #93256

Re: C++ Language Design (2023-01-17 00:24 by quiret #93401)

While researching the future of the GCC compiler, related to the advancing C++ standard and how the compiler landscape is willing to scientifically implement it, I stumbled upon - in the vast unforeseeable jungle of PRs - the GCC 13 release notices with the following PR mention:

https://wg21.link/p2513

First off, great exploratory PR about the "real" use of C++. I am thrown-off by the mention of "industry" in relation to truly bad development practices. I wish that the PR would simply be left as a comment and the char8_t semantics be not amended for C++23 at all. Strong char8_t typing is important to prevent sloppy development model abuse (for example Linux skript kiddies passing char8_t into syscalls where char* is mandated, storage of utf-8 strings in std::string container based on char, the primitive mindset that character encodings do not matter).

I pray for the best future for the C++ language and the developer community!
Reply to #87801

Re: C++ Language Design (2023-01-24 19:49 by quiret #93519)

I had an argument with a possibly short-sighted, scared user on StackOverflow about the direction of the C++ language in the light of volatile special interests and how the compilers should expose their specific (platform) features to devs. You can find my post where I explore new GCC grammar for embedded purposes here:

https://stackoverflow.com/questions/75215239/platform-extension-specific-replacement-for-volatile-specifier-as-hardware-regis

In my opinion this shows how designing the C++ language is largely a human problem. Humans make mistakes. Humans do not want to learn new things. Humans are difficult to bring to a consensus. Thus there is little hope for radical ideas to go through well in the C++ developer community. But I promise you that my vision is greater than you may initially think! Try to unrestrict your mind, unlike the user that I argued with.
Reply to #87801

Re: C++ Language Design (2023-01-26 05:29 by quiret #93541)

I have slept over this situation and would like to provide concluding thoughts.

SOLUTIONS TO THE VOLATILE PROBLEM:
#1: __hardware specifier for variables, resulting in clear machine-code output equivalence
- every platform signs a contract with the developer about machine-code templates used when operations on volatile objects are performed, maybe in the form of a source code file exposing the platform defnitions of operations on native types (insight into compiler design, open source)
- compilers across one platform obey the contract when computing machine code
- operations on volatile objects are only limited by the mandated machine-code
templates
- PRO: side effects are 100% known
- PRO: platform performance can be negotiated by the entire industry that relies on it (multiple revisions of machine code mappings, open to public)
#2: volatile as anti-specification to constexpr/consteval
- volatile execution of code graphs forced to after-compilation/run-time, constexpr
evaluation forced to during-compilation/constant-time
- make volatile a well-designed construct of the C++ programming language (pick only which you like best)
-> volatile(expr) returns true if expression is forced to evaluate at run-time
(anti to consteval(expr) which returns false in that case)
-> volatile-specifier for function signatures to mark them as forced-runtime
-> volatile applied to C++ variables to mandate that for each C++ language operation to-be-performed on them there exists a representation in run-time machine code with at-least the (side-)effects of the language construct
- no restrictions on volatile variable language operations (compound-operations, results from assignments, etc) because their mandated language definition is known
- PRO: compiler has freedom in deciding about the best machine code version of run-time language expressions (based on code graph analysis)
- PRO: best compatibility with current industry volatile use

MOTIVES OF VOLATILE:
- volatile objects in well-defined core C++ with volatile specifier provide only a subset of non-volatile operations on them, but otherwise computationally equivalent
- volatile as limitation on compiler optimizations
- volatile keyword does also exist in the C programming language
- volatile was largely deprecated in C++20 but de-deprecated due to criticism

This problem is really difficult. I would not want to be the arbiter. My choice would be on the first due to equivalence clarity. I wish every involved party the best of luck about deciding the future of the C++ programming language.
Reply to #93519

Re: C++ Language Design (2023-03-09 22:04 by quiret #94485)

I made a video about the ownership design principle important for proper scientific software modelling. It is especially important for the C++ programming language and its extensive ownership modelling strategies directly built into the language grammar and libraries. Please give it a watch to be informed!

https://www.youtube.com/watch?v=L3AGepJA054
Reply to #87801