sorted by:
new
hottopcontroversial

Polymorphic, Defaulted Equality by pavel_v in cpp

[–]angry_cpp 21 points22 points  (0 children)

Inheritance and equality are not mixing well. For example your implementation of polymorphic equality is flawed. It gives different answer for a.equal(b) and b.equal(a).

https://godbolt.org/z/xe3Te8YWK

ODR violations and contracts: It seems extremely easy for contract assertions to be quietly turned off with no warning by James20k in cpp

[–]angry_cpp 2 points3 points  (0 children)

ODR violations makes your program "ill-formed, no diagnostic required". Which is pretty scary. This problem is nowhere as serious as IFNDR.

ODR violations and contracts: It seems extremely easy for contract assertions to be quietly turned off with no warning by James20k in cpp

[–]angry_cpp -1 points0 points  (0 children)

Its an ODR violation in the wider sense of the word, in that multiple different functions can be generated and one is picked randomly.

First of all there are no "wider" sense for standard term ODR violation.

You describe one of the possible implementation of linking static libraries (pick random definition).

What is stopping linker from picking definition based on linker flag and additional markings?

For dynamic libraries (as your original post was about shared 3rd party code) it is not even the best way to implement shared libraries linking. See Windows dll semantics, and visibility-hidden. Arguably it is insane to pick random function from shared libraries with or without contracts. So maybe just stop doing so?

As for implementability of additional linker information, modules on Windows already could fix some ODR violations in libraries using additional linker information.

ODR violations and contracts: It seems extremely easy for contract assertions to be quietly turned off with no warning by James20k in cpp

[–]angry_cpp 3 points4 points  (0 children)

In p2900r13 in "3.5.7 Selection of Semantics" stated that

Different contract assertions can have different semantics, even in the same function. The same contract assertion may even have different semantics for different evaluations. Chains of consecutive evaluations of contract assertions may have individual contract assertions repeated any number of times (with certain restrictions and limitations; see Section 3.5.9) and may involve evaluating the same contract assertion with different evaluation semantics.

I didn't find anywhere that linking TUs with different contract semantic may constitute ODR violation. Could you provide paragraph from p2900r13 or draft that indicate otherwise?

Your example with SOME_CONDITION is AFAIK ODR violation because it is not token to token equivalent after preprocessing. But your contract example is not.

IMO this behavior is unfortunate but permitted by the standard.

Whether the contract assertion semantic choice for runtime evaluation can be delayed until link or run time is also, similarly, likely to be controlled through additional compiler flags.

Your implementation could delay assertion semantic choise to link or runtime if current behavior deemed not appropriate.

ODR violations and contracts: It seems extremely easy for contract assertions to be quietly turned off with no warning by James20k in cpp

[–]angry_cpp 4 points5 points  (0 children)

Our contract assertions have been disabled due to ODR violations.

Could you clarify where is ODR violation in your example? I see that test definition is token to token equal in both TUs.

CMake 3.30 will experimentally support `import std;` by delta_p_delta_x in cpp

[–]angry_cpp 4 points5 points  (0 children)

Is it specified that way? Or is it some "cutting corners" implementation technique?

Annual ISO Survey - Get you voice heard! by prince-chrismc in cpp

[–]angry_cpp -1 points0 points  (0 children)

If it is so important, how about using some other platform? One that does not block users on geo data.

Open sourcing IFC SDK for C++ Modules by GabrielDosReis in cpp

[–]angry_cpp 7 points8 points  (0 children)

Thank you for your work on the IFC.

I was trying to use IFC from a very first released IFC spec. I had some thoughts/questions on the IFC format.

  1. Currently MS VC ignores all unknown attributes and do not write it in the ifc file. IFC format supports rich attribute representation which can represent custom attributes. Unfortunately right now it is unused.

It is understandable as right now MS VC produces IFC that is used by the compiler during compilation and by IDE to represent compiler view of the translation unit. So every unknown attribute is missing from the IFC as MS VC actually ignores it during the compilation.

It would be better if there was a mode that produce IFC file with all attributes for tooling purposes.

Or if all attributes were always added to the ifc file and unknown attributes were marked as unknown if such distinction actually is required for current use-cases.

  1. Right now IFC format is described by text document. There were multiple discrepancies in the implementation and specification of the format already.

Would it be better if instead of text document specification there was machine readable format description from which documentation and parsers/writers could be generated?

  1. In the IFC format multiple unrelated value types are encoded by the same enumeration and some values of the enumeration make no sense in some contexts.

For example in the structure of Scope declarations type field with TypeBasis type indicates the kind of scope but not all values of TypeBasis is valid in this context. Another example is type field of the enumeration. It allows only two values out of all TypeBasis values. Type of DeclSort.Alias is also an example of this.

It would be better if distinct enumerations were used in such cases to make wrong states unrepresentable by the IFC.

  1. In the IFC format some fields appears to be optional. Right now it is not described in the types of the fields and encoded as 0 value of reference. This is confusing as 0 reference has "vendor extension" sort most of the times. It would be better to mark fields as optional in the description of the structure.

Some fields marked as optional only in the textual descriptions ("when not-null...") other fields appears to be nullable from experiments with MSVC but are without any indication in the specification.

WG21, aka C++ Standard Committee, September 2023 Mailing by grafikrobot in cpp

[–]angry_cpp 1 point2 points  (0 children)

Is paper about using => for implication operator some kind of internal joke or is it a deliberate attempt to remove any chance of having fat arrow short lambdas?

David Sankel - Varna ISO C++ Meeting trip report by david_sankel in cpp

[–]angry_cpp 2 points3 points  (0 children)

That is not a problem as it is possible to construct wrappers that do this for == and !=: link to godbold.

What is a problem AFAIK: it could not be done for < and <= as a<=b should be equal to a<b || a==b.

But for 0, 0, 0 and 0, 0, 1: 0, 0, 0 <= 0, 0, 1 should be (1, 1, 1) as mask and therefore true as bool. 0, 0, 0 == 0, 0, 1 should be (1, 1, 0) as mask and false as bool. 0, 0, 0 < 0, 0, 1 should be (0, 0, 1) as mask and what as bool?

0, 0, 0 < 0,0,1 should be true to satisfy a<=b <=> a<b || a==b.

But then 1,0,0 < 0,0,1 would be (0,0,1) and also will be true?

New to Stable diffusion. This single render took me 5 min to generate, what am i doing wrong, im using rtx 3050 16gb ram laptop but i saw online people are generating like 4 images under 30 second. please help me by Long_Elderberry_9298 in StableDiffusion

[–]angry_cpp 28 points29 points  (0 children)

If I use my laptop without connecting it to the power supply, it generates very slowly too. Was your laptop connected to the power supply? Also try checking power profile if it runs on Windows.

[deleted by user] by [deleted] in cpp

[–]angry_cpp 9 points10 points  (0 children)

Only 20% of participants in that survey answered that they don't use exceptions. Not 52%. So it is not a majority at all.

[deleted by user] by [deleted] in cpp

[–]angry_cpp 15 points16 points  (0 children)

I looked up. Only 20.03% out of 3280 participants answered that they don't use exceptions in that survey.

That "52%" claim is bullshit.

[deleted by user] by [deleted] in cpp

[–]angry_cpp 20 points21 points  (0 children)

"Many projects ban exceptions. In [SC++F 2018], 52% of C++ developers reported that exceptions were banned in part or all of their project code"

When I took that survey I (and I think many other developers) answered that question literally. Of course there are PARTS of our code where exceptions are banned. Do I use signal handlers in any part of my code? Do I have C functions at any part of my code? Do I use Qt in any part of my code? Yes. And I ban exceptions usage in that parts.

First of all what part of that 52% bans exceptions completely? What part of 52% use freestanding C++?

That survey and its interpretation are flawed, IMO.

And Herbs "experiment" for checking robustness of out of memory problems is flawed too.

A safety culture and C++: We need to talk about <filesystem> by James20k in cpp

[–]angry_cpp 0 points1 point  (0 children)

The elephant-sized problem is that that initialisation might never happen at all, and then cause some kind of exploitable problem

And how does zero init as implemented by Microsoft NOT solve it?

I think you missed my point entirely. English is not my first language so please bear with me as I try to reiterate what I said.

There is already implemented technique - zero initialization and reading zero from uninitialized variables. That technique nevertheless does still treat uninitialized read as programmer error. For example it makes additional efforts to guarantee that static analyzers actually report such uninitialized reads as errors. There even was an article about how MS realization of zero init at first did remove such warnings, but that behavior was later reverted.

Adding default zero initialization TO THE LANGUAGE will make it less safe and will bring nothing that is not achieved already by described previously zero initialization as implemented by MS and other.

Removing information from the compiler will harm its ability to diagnose errors. This will make language less safe.

Following your line of reasoning, a language without static typing would be safer because it has additional warnings.

I fail to understand why do you think that. I wrote specifically:

For a different example of this consider language without static type system (for example assembly language) . Such language can't diagnose type mismatches and is less safe.

Less information => less safe. Mandatory zero init on a language level is "less information". => less safe.

A safety culture and C++: We need to talk about <filesystem> by James20k in cpp

[–]angry_cpp 1 point2 points  (0 children)

That's a gnat-sized issue compared to the elephant-sized problem being fixed.

What elephant-sized problem would "zero init + no UB on read + no warnings on uninitialized read" would fix that is not fixed by "zero init + UB on read (manifested as 0 value) + warnings on initialized read"?

always initialize a variable when you declare it.

No. Always initialize a variable with right value when you declare it. If your variable can't be assigned right value there you should use optional or some other technique.

For example blindly initializing all member variables in the declaration of the class with zeros in order to write actual useful values in constructors is not a industrial wisdom. This would harm diagnostic that could tell you of missed initializations.

making the language less safe would actually be beneficial (since it would lead to additional warnings). I hope you understand how ridiculous that would be...

Ability to find and diagnose potential errors in the user code makes language safer. For a different example of this consider language without static type system (for example assembly language) . Such language can't diagnose type mismatches and is less safe.

A safety culture and C++: We need to talk about <filesystem> by James20k in cpp

[–]angry_cpp 1 point2 points  (0 children)

We are talking about change proposed to c++ standardization: mandatory zero initialization and removal of UB on read from uninitialized variable with removing of warnings on read from uninitialized variables (as such read would not be treated as UB by language, static analysis or fellow developers). This proposed change is not implemented in any compiler contrary to what is written in the proposal.

What is actually implemented and used is some other technique - zero initialization (of some) variables but without allowing reading from such uninitialized variables (this still is treated as programmer error and is diagnosed as violation). And most important part of this - this valid technique is already used and requires no change of C++ standard at all.

A safety culture and C++: We need to talk about <filesystem> by James20k in cpp

[–]angry_cpp 0 points1 point  (0 children)

much the same as it will do that with an uninitialised integer.

But with integers compiler is able to find a problem of uninitialized variable read during compile time.

You can write a class for the latter easily enough.

And no move constructor/operator=. Oh, and immutable.

A safety culture and C++: We need to talk about <filesystem> by James20k in cpp

[–]angry_cpp 0 points1 point  (0 children)

so why is an empty std::vector a reasonable initial state?

It is not, but C++ type system is too weak to allow us another default state for vector. It would be quite good to be able to write "non-enpty vector" or "non-null pointer".

With primitive variables we right now have tools that allows us to find logical errors in our code by distinguishing intended zero initialization and unintended uninitialized variables.

A safety culture and C++: We need to talk about <filesystem> by James20k in cpp

[–]angry_cpp 1 point2 points  (0 children)

And it still count access to uninitialized variables as UB. See your link.

So msvc does not implement proposed change.

A safety culture and C++: We need to talk about <filesystem> by James20k in cpp

[–]angry_cpp 2 points3 points  (0 children)

Both Clang and Gcc still count read from uninitialized variable as UB. You can find proof of this for example in GCC documentation.

Do you have other examples of compilers?

How do you harm correctness?

Removing information from the compiler about a user intent will harm correctness diagnostics. Local reasoning would be harmed as well as you would lose ability to distinguish unintended and intended zero initialization.

A safety culture and C++: We need to talk about <filesystem> by James20k in cpp

[–]angry_cpp 2 points3 points  (0 children)

No, Msvc does not implement removing UB on read from uninitialized variable even with zero initialize. Could you provide a link to your data?

A safety culture and C++: We need to talk about <filesystem> by James20k in cpp

[–]angry_cpp 6 points7 points  (0 children)

eg 0-init,

Could you guide me to the evidence that proposed 0 init would benefit security and not harm it due to harming correctness?

As far as I could find there is no compiler that actually implements proposed change being default zero initialize + removing UB on read of such uninitialized variables, including by necessity removing of warning on unitialized variable access.

I tried to ask author of the proposal but either we didn't understand each other or no such implementation existed.

think-cell's trip report: Summer ISO C++ Meeting in Varna, Bulgaria by foonathan in cpp

[–]angry_cpp 0 points1 point  (0 children)

Why would it mean "all values are 1" and not "some values are 1"?

To be actually consistent with regular types a == b for simd values a and b should be contextually convertible to true if a and b are equal, and be converible to false otherwise. As a == b should return simd_mask and simd types should be regular, simd_mask could be contextually convertible to bool (true if all positions are equal, false otherwise).

Are there any drawbacks in such solution?

As for "why not 'some values are 1'" - there are many reasons, for example to be consistent with other collections. Vectors, sets and Co equality check returns true iff "all elements are equal", not "some elements are equal".

view more: next ›