void DoSomething(
_In_reads_bytes_(numBytes) const void * p,
_In_ size_t numBytes );
The beauty and simplicity of the good old C-style void* in C++
161–170 of 182 posts
Re: The beauty and simplicity of the good old C-style void* in C++
#162Makes you wonder why OP is using cpp to begin with if theyre suggesting void*
How in Nora does that get downvoted? It's the mainstream view on it
Re: The beauty and simplicity of the good old C-style void* in C++
#163Earlier quoted context omitted.
Are your seriously comparing the C++ standard committee to the Trump administration? I know you have an axe to grind, but this is getting ridiculous. Where exactly have you seen this "parade of sycophants" in the C++ standards committee? As far as I know, Bjarne is just a regular committee members with just as many votes as everyone else and no veto powers. The committee frequently accepts or rejects proposals agains…
Yes, I am seriously making that comparison. It's not as bad of course but it's certainly enough to make me cringe. > Where exactly have you seen this "parade of sycophants" in the C++ standards committee? AIUI The committee itself operates under the "Chatham House Rule" in which participants agree not to tell anybody who said anything and so we can only see group outcomes for the committee itself. For example 100% af…
If Bjarne was so powerful, how come they voted contracts into C++26 despite his strong concerns? How come he publicly vents his frustration with the direction the language is taking?
Re: The beauty and simplicity of the good old C-style void* in C++
#164[deleted]
Re: The beauty and simplicity of the good old C-style void* in C++
#165Don’t people remember the real history anymore? The original C did not include the void type, and therefore void* did not exist either. Original C used char* to represent pointers of any type and directly cast char* to double*. You can read the first edition of The C Programming Language from 1978 to learn about this. void and void* were essentially invented based on practices from early C++ and were eventually incorporated into ANSI C.
Re: The beauty and simplicity of the good old C-style void* in C++
#166Earlier quoted context omitted.
Well if compilation time is an issue, you chose the worst possible language to use. But if you must use C++, you should use the mechanisms that best communicate intent.
It’s this kind of attitude that perpetuates bad compilation time. Templates have to get parsed and instantiated over and over again. Then you need link time optimization to deduplicate all the redundant copies of the same code.
No they don't, modules exist, as do external template libraries.
Re: The beauty and simplicity of the good old C-style void* in C++
#167Earlier quoted context omitted.
Are you asserting that WG14 never had the necessary skills among all the members to help improve this proposal, or dare to bring another one during the last 40 years?
This has not much to do with skill. Standardization does not work like this, and I told you this before.
Yeah, I keep missing the existing practice in secure C compilers that is supposed to land on a WG14 paper.
You can tell me the times you wish for, I will keep playing my trumpet until I see something in C that resembles to Modula-2 was offering in safety, nowadays brought back by Zig.
Re: The beauty and simplicity of the good old C-style void* in C++
#168Earlier quoted context omitted.
Are you asserting that WG14 never had the necessary skills among all the members to help improve this proposal, or dare to bring another one during the last 40 years?
> Are you asserting that (...) No, I called out your opinionated ignorance on the topic. > WG14 never had the necessary skills among all the members to help improve this proposal (...) Frankly I don't think you even understand what you're arguing. I mean, to start off, if an idea is feasible then do you think it needs a full blown committee joining forces to magically fix all the problems? > (...) or dare to bring an…
Who is more ignorant here, you repeating calling me that, or WG14 not doing anything to improve security since the Morris worm in 1988?
Re: The beauty and simplicity of the good old C-style void* in C++
#169Earlier quoted context omitted.
There's no need: there's std::copy already. Or maybe the idea was to create a typesafe template wrapper around the generic function which is also very common and really nice. No need to create one wrapper per type, a single template should work.
And how was std:copy implemented? Your answer is valid only for a programming language which assumes that the standard library is implemented in another language. C/C++ are supposed to be languages in which any program can be written, unlike languages like Java or Python.
You cannot implement modern C++ in pure C++ nowadays, as the standard library requires compiler intrisics, just like a language like Java.
Re: The beauty and simplicity of the good old C-style void* in C++
#170> Why should people complexify and uglify their C++ code with the uint8_t pointer (or std::byte), when void* works just fine?? Fair point (although to be honest: 'complexify' feels a bit of an exaggeration here to me), but the answer to this why is simple: document and express intent clearly. The compiler gave you an error first such that you're forced to consider what you're doing. Any seasoned C++ developer seeing…
> Fair point (although to be honest: 'complexify' feels a bit of an exaggeration here to me) Both uint8_t and std::byte require a header ( or ) which may expose you to platform x config specific build failures if you do any conditional #including, and the latter is a whole damn enum class with a strange adversion to arithmetic, where `byte |= 1` becomes `byte |= std::byte(1)`, `byte += 1` becomes `byte = std::byte(st…
> and the latter is a whole damn enum class with a strange adversion to arithmetic, where `byte |= 1` becomes `byte |= std::byte(1)`, `byte += 1` becomes `byte = std::byte(std::to_integer(byte) + 1);`, and both become something you can accidentally step into in your full debug builds because it's an actual function call (at least on MSVC - still extra instructions on clang/gcc, but I can see the dang call instruction on MSVC!) instead of a compiler built in.
That's the point, std::byte is for opaque bytes. You're not expected to do arithmetic directly just like you can't do arithmetic on void.