HN user

bumblebritches5

17 karma
Posts0
Comments51
View on HN
No posts found.

Sounds like the rich kid version of me.

Parents students and teachers treated me like shit throughout elementary school, went to a new school and decided I wasn't gonna take it anymore.

Started misbehaving and getting suspended literally all the time, had over 400 disciplinary actions on my school recorded, got expelled from a few schools then expelled from the whole district, as in they just wouldn't let me go to that high school at all...

Turned myself around after choking my sister when I was 15 and damn near got arrested for it.

As in, I was sitting in the back of a cop car, not handcuffed but they patted me down, bawling my eyes out.

Thankfully my sister didn't say a word to the cop and that's when I decided I had to change.

- I wanted a form to register new types, so it could work for user-defined types;

- the C pre-processor knows nothing about lists that can be expanded multiple times;

I'm actually working on both features as Clang extensions.

#repeat, a preprocessor directive to loop, can be combined with _Pragma(push_macro/pop_macro) to create lists by redefining a macro.

and currently #increment, though I think I want to expand on this so that other macros can be redefined more easily to create lists via push/pop macro.

The reason push_macro/pop_macro pragmas can't work, is the macro has to be undefined and redefined, and the value then pushed onto a stack in the compiler.

and you can't redefine a macro in the body of another macro directly.

so I've been thinking about maybe a _Pragma(redefine_macro(MacroToRedefine, NewValueForRedefinedMacro))

but I don't want it to be limited to the _Pragma area of the compiler, I want it to be eventually standardized.

I've been talking to a friend at WG14 who suggested making it a "Preprocessor Expression, like `__has_c_attribute` and `defined()`

So that's the area I've been working on recently for the Increment/Redefine PE lately.

Except Google didn't build those things except search.

They bought Android in 2005, Youtube in 2004? and all of their other, non-search successes.

Walter, I honestly just can't trust your judgement on the future of C or C++, because all I ever see is you pushing D anytime you comment.

This seems like just another gimmick to push D tbh.

that's a K&R style function definition.

modern syntax is:

    char *Combine(char *S, char *T) {

        ...
    }
which means the Combine function returns a string (char pointer), and takes as arguments two strings, S and T.
Modern C 6 years ago

I've lately been getting segmentation faults for not casting math with diff signs, so pretty much anything can cause it.

Modern C 6 years ago

Jens Gustedt wrote this, he's very involved in ISO WG14, the group that creates the C standard.

Hey guys,

How likely would the standard be to accept a proposal to add compile time reflection to the preprocessor, or even adopt C++'s constexpr?

My use case is creating a global array in a header from static compound literals in multiple source files at compile time, and outside of some crazy clang-tblgen type solution, or very platform specific linker hacks, it's completely unsupported by C.

LLVM 9.0 7 years ago

Inline assembly is part of the C11 standard as Asm("assembly goes here")

Oh, so it's a BOM?

Kinda? It isn't limited to just the byte order tho, but I can see it.

Why integrate it into the code unit if you're only going to have one of them?

There would be multiple code units, just 1 of the mini headers/BOM.

With that comment I was trying to contrast it to UTF-8 which has those 2 leading bits of the continuation code units set to `0b10`, it wouldn't have that.

That's precisely what I meant with your UCS-2 comment.

What do you mean by variable width? the 4 bit header would be limited to the first code unit, the following ones would just be pure codepoint values.

and that's a good point, I as picturing it as the top 4 bits that describe the format, so the header's byte order would be field, but the actual codepoint value would be encoded with whatever byte and bit order the header indicated.

because it's the top 4 bits... you read that as a byte, then read X bits more to get the rest of the code unit.

yup and yup.

UTF-8 is capped at 21 bits, theoretically it can support up to 6, but it's not allowed to because of UTF-16.

This format would allow 28 bits to be encoded as 8, 16, and 32 bit code units.

There would be no surrogate pair nonsense, simply write all the non-leading-zero bits into as many code units you need as well as the 4 bit header, and you're good.

I'm not saying it'll ever happen, I know it won't, but if we could go back in time...