Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always default to const or constexpr? #18

Open
maxxoccupancy opened this issue Feb 29, 2024 · 2 comments
Open

Always default to const or constexpr? #18

maxxoccupancy opened this issue Feb 29, 2024 · 2 comments

Comments

@maxxoccupancy
Copy link

Instead of writing const, constexpr, inline, etc, could we have every method and variable automatically default to the smallest, fastest, or most constant version? And have every variable and member automatically default to the fastest type? For a few examples:

(using whiteboard)

//variable pie becomes a constant float and a constant double
pie = 3.1415926536   
// compiler selects float or double, attempts to **_constexpr_** this equation, area gets the same type as myRadius
area = myRadius * pie

struct dog:                //defaults to a 4-byte union unless multiple members are read later in the program
    name = 'Max'     //const string
    numLegs = 4, numTails = 1, numIQ   // const uint_fast8_t, numIQ defaults to 0
    bark():                   //methods are actually global functions, but can only be called within the program by an object of type 'dog'
        print "ruff"        //bark() defaults to an **_inline, pure_** function; print is not pure
        numIQ--           //if 0, numIQ bottoms out at 0, operation attempts to **_constexpr_**

dog* Max             // unique pointer of 16, 24, or 32 bits is created; Maxx will automagically be deleted
(dogGetsHit) ? Max.numLegs--
Max.bark()

In C/C++, we almost always have to sprinkle our code with keywords that let the compiler perform additional optimizations. Shouldn't the default always be to the fast way so that unprofiled code runs a bit faster, pollutes the Branch History Table and cache less, and the code and data would be a bit more compact?

@nektro
Copy link
Owner

nektro commented Feb 29, 2024

Shouldn't the default always be to the fast way

this is achieved by defining variables with const by default and only using var when needing mutation. note that in newer versions of zig this is compiler enforced. zig is a much younger language so was able to unify the keywords needed. in c++ constexpr is somewhat analogous to zig's comptime but done in a way that maintains c++ backwards compatibility.

@maxxoccupancy
Copy link
Author

But I mean in general. So instead of some statement like (psuedocode):

const uint_fast16_t MAXIMUS = static_cast<int>(letter * 8);
constexpr Entity* demo = std::unique_ptr<double> uptr2 (register pd);
...

And so on, we let coders bypass all of that learning overhead by just writing the usual:

uint16 MAXIMUS = letter * 8;
Entity demo = fun(u2* pd);
...

...and have each of those terms default to the fastest code. Functions default to inline, variables default to constant or uint_fast_16, expressions default to constexpr, methods default to static, and so on. Not for one specific feature or the other, but if the default throughout the whole ecosystem is to go straight to the faster result, then pages (6 pages in the ISO C standard) always default to the faster result, then the programmer at least has something deterministic. So when devs through the Ziggaverse wonder how something is likely to behave, then we can generally figure out the answer on our own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants