profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/ivocavalcante/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Ivo Cavalcante ivocavalcante Brasil

ivocavalcante/giara-snap 1

Giara reddit app, Snap package.

ivocavalcante/PrusaSlicer-snap 1

PrusaSlicer Snap package.

ivocavalcante/btrfsmaintenance 0

Scripts for btrfs maintenance tasks like periodic scrub, balance, trim or defrag on selected mountpoints or directories.

ivocavalcante/curv-snap 0

Curv Snap package files

ivocavalcante/qemu-snap 0

QEMU Snap package.

issue commentisocpp/CppCoreGuidelines

C.12 and dependency breaking

But a pointer can be null at runtime. I use that if the interface can be not there or be changed. But normally this is not needed because this objects are initialized together.

marbub

comment created time in 4 hours

issue commentisocpp/CppCoreGuidelines

C.12 and dependency breaking

My reading of the guideline is not that you would avoid doing that but that you would use a pointer instead. I'm not 100% confident that this is what it's saying and I'm not sure I agree if it is.

marbub

comment created time in 9 hours

issue commentisocpp/CppCoreGuidelines

Add clarification to Con.1

Which is why they should be treated differently. You answered your own question didn't you?

Sorry, I wasn't clear: I meant the guideline should be the same for both, but as I said: There should be separate flags for the two cases.

The "such a check" was meant to refer to any check that warns on non-const variables. Regardless of whether they are parameters or function locals. I.e. even if you "only" warn on function local variables you'll get an abundance of warnings.

stayprivate

comment created time in 12 hours

issue commentisocpp/CppCoreGuidelines

Add clarification to Con.1

See also https://github.com/isocpp/CppCoreGuidelines/issues/975#issuecomment-312937255 and https://github.com/isocpp/CppCoreGuidelines/issues/1081#issuecomment-345230904

stayprivate

comment created time in 14 hours

issue commentisocpp/CppCoreGuidelines

Add clarification to Con.1

Such a check will be incredibly noisy anyway

Which is why they should be treated differently. You answered your own question didn't you? Using const for function parameters is less common, and confuses some people (many people don't realise it has no meaning on a non-defining declaration, only on the definition, and having it mismatched between declaration and definition also confuses). That's why the guideline says not to enforce it for function parameters. The trade off between additional const-ness and potential confusion needs to be considered for each codebase, not enforced uniformly.

stayprivate

comment created time in 14 hours

issue commentisocpp/CppCoreGuidelines

Add clarification to Con.1

I also don't see, why function arguments should be treated any different than regular variable definitions in that respect.

Realistically however, I think a tool should have separate flags to enable/disable warnings about non-const local variables and non-const function parameters. Such a check will be incredibly noisy anyway when applied to an existing code base and it would be beneficial to clean it up one kind at a time.

stayprivate

comment created time in 17 hours

issue openedisocpp/CppCoreGuidelines

Add clarification to Con.1

Con.1: By default, make objects immutable ... Function arguments are rarely mutated, but also rarely declared const. To avoid confusion and lots of false positives, don't enforce this rule for function arguments.

void f(const char* const p); // pedantic void g(const int i); // pedantic ...

These examples are prototypes/decl, not the definition. Internaly some are interpreting the lack of example as saying const should not be used for argument passed by copie/value in definition as well. Other are saying "by default make objets immutable" as applying to argument passed by copie/value.

I've never seen code using const for argument passed by copy/value, in definition.


What is recommended. I personnaly like const in definition as it tell the reader/maintainer the variable will not be modified.

created time in a day

issue openedivocavalcante/PrusaSlicer-snap

PrusaSlicer hangs after ever g-code export

Starting after the last snap update (identified as happening on May 2, 2021), PrusaSlicer now hangs after I export g-code. The g-code is always correctly exported but the app itself freezes and I have to kill it. I've tried waiting several minutes for it to unfreeze but it is clearly in some frozen state. The system I use is not connected to the printer and I haven't changed any USB devices in the past few weeks.

Here are the system particulars...

installed version: prusa-slicer 2.3.1+snap2 26 latest/stable ivo-cavalcante

snapd version: snapd/groovy-updates,groovy-security,now 2.48.3+20.10 amd64 [installed,automatic]

Ubuntu 20.10, kernel 5.8.0-50-generic

created time in 2 days

issue commentisocpp/CppCoreGuidelines

Relax enforcement of rule F.16

I don't think passing by reference is always fine. It's not just a question of cost but complexity. When I pass something by reference I don't know how long I need to keep the referenced object alive for. Writing a function that takes an object by const reference and requires the object to outlive the method call is probably a bad idea but it can be done and when I'm calling someone else's (including my past self) code I don't know how many bad ideas they acted on. That doesn't mean you should never pass by const reference but it is a reason to prefer passing by value.

pauljansen42

comment created time in 3 days

issue commentisocpp/CppCoreGuidelines

Relax enforcement of rule F.16

Passing a huge object by value might make sense if it permits guaranteed elision, rather than forcing early temporary materialization in order to bind a reference to the temporary.

Unfortunately, the right rule is probably "it depends" and any inflexible enforcement will be wrong in some cases.

pauljansen42

comment created time in 3 days

issue commentisocpp/CppCoreGuidelines

Relax enforcement of rule F.16

I think, much more important than the size is whether the type is trivially copyable or not. For trivially copyable types, I find the rule of thumb in the rules totally fine. F.ex. you definitely want to pass a pointer or a size_t by value, which wouldn't be covered by "less than size(void*)".

As always, the important thing is that there is a way to suppress it when I have heard data that breaking this rule is important for semantic or perf reasons.

pauljansen42

comment created time in 3 days

issue openedisocpp/CppCoreGuidelines

Relax enforcement of rule F.16

We have implemented an automatic check for the current enforcement of rule F.16:

  • (Simple) ((Foundation)) Warn when a parameter being passed by value has a size greater than 2 * sizeof(void*). Suggest using a reference to const instead.
  • (Simple) ((Foundation)) Warn when a parameter passed by reference to const has a size less than 2 * sizeof(void*). Suggest passing by value instead.

We have received a lot of comments on this by users. Basically it comes down to 2 objections:

  1. The current enforcement is black or white, either something something must be pass by value or must be pass by reference unless the size is exactly 2 * sizeof(void*). The border between when to pass by value or by reference is not that strict in practice. This should also be reflected in the enforcement rules. E.g. greater than 4 * sizeof(void*) -> pass by reference and less than 1 * sizeof(void*) -> pass by value. If your type is somewhere between these two borders, you are allowed decide for yourself whether to use pass by reference or pass by value.
  2. Passing by reference is always OK. The overhead of passing by reference is negilible. So why not only demanding the first enforcement? This is because passing a huge object by value should certainly be forbidden, whereas passing a small object by reference is not wrong.

What are your thoughts on this?

Regards,

Paul

created time in 3 days

issue commentisocpp/CppCoreGuidelines

Pro.bounds.2: Only index into arrays using constant expressions - What about std::arrays?

See https://github.com/ericniebler/range-v3

carlosgalvezp

comment created time in 6 days

issue commentisocpp/CppCoreGuidelines

Pro.bounds.2: Only index into arrays using constant expressions - What about std::arrays?

Thanks, zip plus structured bindings sounds like it would be the best solution! Unfortunately not available in the STL yet, I'll look into ways of implementing them myself until then. Thanks!

carlosgalvezp

comment created time in 6 days

issue openedisocpp/CppCoreGuidelines

C.12 and dependency breaking

Using a reference to an interface for dependency breaking is so useful that I really think the advice can be harmful. It helps too against singletons, globals etc.. I think it can be very useful if you speak about value member.

class Frontend(BackendInterface &backend) : backend(beckend) { void sendMessage(string title) { auto message = backend.createMessage(); message.value = title; backend.scheduleMessage(message); } private: BackendInterface &backend; }

created time in 7 days

issue openedivocavalcante/PrusaSlicer-snap

Programm crashes on importing configuration

On current version 2.3.1+snap1 I had observed this behavoir:

Everytime I click on the entry "import a configuration bundle" the programm closes immediately. This happens for the other entries on importing configuration too. There appears no file dialog, but the programm just closes.

I experienced this on recent kubuntu 20.04 LTS.

created time in 8 days

issue commentisocpp/CppCoreGuidelines

Pro.bounds.2: Only index into arrays using constant expressions - What about std::arrays?

related question: https://stackoverflow.com/questions/8511035/sequence-zip-function-for-c11

carlosgalvezp

comment created time in 10 days

issue commentisocpp/CppCoreGuidelines

Pro.bounds.2: Only index into arrays using constant expressions - What about std::arrays?

Or with p2321:

for(auto z : std::views::zip(x, y))
  some_complex_function(std::get<0>(z), std::get<1>(z));

which can be written as:

for(auto z : std::views::zip(x, y))
  std::apply(some_complex_function, z);

or:

std::ranges::for_each(std::views::zip(x, y), [](auto z) { std::apply(some_complex_function, z); });
carlosgalvezp

comment created time in 10 days

issue commentisocpp/CppCoreGuidelines

Pro.bounds.2: Only index into arrays using constant expressions - What about std::arrays?

It's no help today, but if P2164 gets approved for C++23 then it should be possible to:

for(const auto& [i, x_i] : std::views::enumerate(x))
  some_complex_function(x_i, y[i]);
carlosgalvezp

comment created time in 10 days

issue commentisocpp/CppCoreGuidelines

Pro.bounds.2: Only index into arrays using constant expressions - What about std::arrays?

Hi again @hsutter ! First of all thanks for the comments, I definitely agree with making code safe by construction and future-proof.

However I don't see how to make the code safer, could you provide a suggestion? You mention "a range-for loop", but that's not possible here, is it? Note that I'm indexing into two arrays, not one (where a range-for loop would be the de-facto choice).

Replacing the loop with iterators is more verbose and error-prone, would you agree?

auto it_x = x.begin();
auto it_y = y.begin();

while ( (it_x != x.end()) && (it_y != y.end()) )
{
    some_complex_function(*it_x, *it_y);
   ++it_x;
   ++it_y;
}
carlosgalvezp

comment created time in 10 days

issue commentisocpp/CppCoreGuidelines

Allow protected copy operations in C.67

Yep, that's what I had in mind. Thanks for looking it up.

adah1972

comment created time in 10 days

issue commentisocpp/CppCoreGuidelines

Allow protected copy operations in C.67

This is a duplicate of issue #1151 which had some discussion ongoing when it was created, but unfortunately is now open since 3 years without any outcome.

adah1972

comment created time in 10 days

issue openedisocpp/CppCoreGuidelines

FAQ's numbered confusingly

The FAQ section numbers questions starting from 1 up to 10 then mysteriously jumps to 50. I could not find the reason behind it, and since this document is not meant to be read linearly, I found it very confusing.

created time in 11 days

issue openedisocpp/CppCoreGuidelines

suggestion: R.n (extend R.35,R.36) for shared_ptr<widget>&& parameter

Title might be like: R.n: Take a shared_ptr<widget>&& parameter to express that caller is expected to transfer "it's" reference count

I'm about to design this into an interface. The background thought is, that there is something like a "primary owner", although ownership is shared technically. shared_ptr is needed for some reason external to the function that takes the argument (in this case: weak_ptr are necessary to cross-reference objects owned by the smart pointers).

The envisioned situation at the callers side is constructing an object and handing it over to the "primary owner". To express that the caller is requested to transfer ownership instead of sharing it, a rvalue reference is used for the parameter. (Of course nothing technically prevents the caller from retaining a copy of the shared_ptr, but the interface expresses that the expectation is otherwise.)

created time in 11 days

issue commentisocpp/CppCoreGuidelines

Liftetimes: shared_ptr questions

Hi, Is there any update on how the analysis tools would detect/catch the issues in the above mentioned examples? Any updates would be helpful.

Thanks.

jrmuizel

comment created time in 14 days

issue openedisocpp/CppCoreGuidelines

Confusion over what Concrete types are

The Core Guidelines defines Concrete types as follows:

"concrete class: class for which objects can be created using usual construction syntax (e.g., on the stack) and the resulting object behaves much like an int as it comes to copying, comparison, and such (as opposed to a base class in a hierarchy)."

The standard seems not to define concrete types. Below are the only hits for "concrete":

[class.abstract]https://eel.is › c++draft › class.abstract The abstract class mechanism supports the notion of a general concept, such as a shape, of which only more concrete variants, such as circle and square, can ...

[util.smartptr.shared.create]https://eel.is › c++draft › util.smartptr.shared.create The object is initialized from args as specified by the concrete overload. The allocate_shared and allocate_shared_for_overwrite templates use a copy of a ...

[range.iter.ops]https://eel.is › c++draft › range.iter.ops ... operations adapt to the set of operators provided by each iterator category to provide the most efficient implementation possible for a concrete iterator type.

[range.iter.ops.general]http://eel.is › c++draft › range.iter.ops.general ... operations adapt to the set of operators provided by each iterator category to provide the most efficient implementation possible for a concrete iterator type.

[iterator.primitives]http://eel.is › c++draft › iterator.primitives ... operations adapt to the set of operators provided by each iterator category to provide the most efficient implementation possible for a concrete iterator type.

[util.smartptr.shared]https://eel.is › c++draft › util.smartptr.shared Effects: Allocates memory for an object of type T (or U[N] when T is U[], where N is determined from args as specified by the concrete overload). The object is ...

[utilities]https://eel.is › c++draft › utilities Effects: Allocates memory for an object of type T (or U[N] when T is U[], where N is determined from args as specified by the concrete overload). The object is ...

[smartptr]https://eel.is › c++draft › smartptr Effects: Allocates memory for an object of type T (or U[N] when T is U[], where N is determined from args as specified by the concrete overload). The object is ...

[iterators]https://eel.is › c++draft › iterators ... operations adapt to the set of operators provided by each iterator category to provide the most efficient implementation possible for a concrete iterator type.

The only definition for concrete that I found that agree with the guidelines come from BJarne's book, A Tour Of C++:

https://learning.oreilly.com/library/view/a-tour-of/9780134998053/ch04.xhtml#ch04lev1sec2

4.2 CONCRETE TYPES The basic idea of concrete classes is that they behave “just like built-in types.” For example, a complex number type and an infinite-precision integer are much like built-in int, except of course that they have their own semantics and sets of operations. Similarly, a vector and a string are much like built-in arrays, except that they are better behaved (§9.2, §10.3, §11.2).

The defining characteristic of a concrete type is that its representation is part of its definition. In many important cases, such as a vector, that representation is only one or more pointers to data stored elsewhere, but that representation is present in each object of a concrete class. That allows implementations to be optimally efficient in time and space. In particular, it allows us to

place objects of concrete types on the stack, in statically allocated memory, and in other objects (§1.5);

refer to objects directly (and not just through pointers or references);

initialize objects immediately and completely (e.g., using constructors; §2.3); and

copy and move objects (§5.2).

The representation can be private (as it is for Vector; §2.3) and accessible only through the member functions, but it is present. Therefore, if the representation changes in any significant way, a user must recompile. This is the price to pay for having concrete types behave exactly like built-in types. For types that don’t change often, and where local variables provide much-needed clarity and efficiency, this is acceptable and often ideal. To increase flexibility, a concrete type can keep major parts of its representation on the free store (dynamic memory, heap) and access them through the part stored in the class object itself. That’s the way vector and string are implemented; they can be considered resource handles with carefully crafted interfaces.

The current definition of concrete types in the guidelines leads to confusion because there is a widespread (mis?)understanding that concrete types are types that implement interfaces. Examples:

https://stackoverflow.com/questions/2149207/what-is-the-difference-between-a-concrete-class-and-an-abstract-class

Abstract class can not be used to create an object. Whereas, concrete class can be used to create an object.

Concrete means''existing in reality or in real experience; perceptible by the senses; real''. Whereas, abstract means 'not applied or pratical; theoritical'.

An abstract class can't be instantiated. Whereas, a concrete one can.

An abstract class is one that has one or more pure virtual function. Whereas a concrete class has no pure virtual functions.

https://en.wikipedia.org/wiki/Abstract_type

In programming languages, an abstract type is a type in a nominative type system that cannot be instantiated directly; a type that is not abstract – which can be instantiated – is called a concrete type. Every instance of an abstract type is an instance of some concrete subtype. Abstract types are also known as existential types.[1]

https://en.wikipedia.org/wiki/Class_(computer_programming)#Abstract_and_concrete

Abstract and concrete In a language that supports inheritance, an abstract class, or abstract base class (ABC), is a class that cannot be instantiated because it is either labeled as abstract or it simply specifies abstract methods (or virtual methods). An abstract class may provide implementations of some methods, and may also specify virtual methods via signatures that are to be implemented by direct or indirect descendants of the abstract class. Before a class derived from an abstract class can be instantiated, all abstract methods of its parent classes must be implemented by some class in the derivation chain.[26]

Most object-oriented programming languages allow the programmer to specify which classes are considered abstract and will not allow these to be instantiated. For example, in Java, C# and PHP, the keyword abstract is used.[27][28] In C++, an abstract class is a class having at least one abstract method given by the appropriate syntax in that language (a pure virtual function in C++ parlance).[26]

A class consisting of only virtual methods is called a Pure Abstract Base Class (or Pure ABC) in C++ and is also known as an interface by users of the language.[14] Other languages, notably Java and C#, support a variant of abstract classes called an interface via a keyword in the language. In these languages, multiple inheritance is not allowed, but a class can implement multiple interfaces. Such a class can only contain abstract publicly accessible methods.[20][29][30]

A concrete class is a class that can be instantiated, as opposed to abstract classes, which cannot.

I am not sure exactly how to reduce the confusion and it looks like this was already discussed in issues: #1268 #1267

One suggestion would be to rename that section to "value types".

created time in 15 days

Pull request review commentisocpp/CppCoreGuidelines

A mixed bag of minor fixes, mostly related to language use (I mean English, not C++)

 This `Addable` violates the mathematical rule that addition is supposed to be co  ##### Note -The ability to specify a meaningful semantics is a defining characteristic of a true concept, as opposed to a syntactic constraint.+The ability to specify meaningful semantics is a defining characteristic of a true concept, as opposed to a syntactic constraint.

So... Should I just revert this change?

reunanen

comment created time in 16 days

PR opened isocpp/CppCoreGuidelines

Proposing ES.48 Rule Exception for Upcasting

Proposing to add an exception to es.48 in instances where the implicit cast involves upcasting objects with multiple inheritance. Due to the various rules that define memory layout it is not always clear to the average developer which upcasts can be performed implicitly.

+55 -1

0 comment

1 changed file

pr created time in 17 days

PR opened isocpp/CppCoreGuidelines

Update change_speed example in P.1 to use user-defined literal syntax

The example code

change_speed(23m / 10s);

is not valid. 10s is fine, because that is defined in std::chrono_literals, but I'm unaware of any operator ""m in the standard library.

I'm proposing changing this example to use user-defined literal syntax.

+1 -1

0 comment

1 changed file

pr created time in 18 days

Pull request review commentisocpp/CppCoreGuidelines

A mixed bag of minor fixes, mostly related to language use (I mean English, not C++)

 This `Addable` violates the mathematical rule that addition is supposed to be co  ##### Note -The ability to specify a meaningful semantics is a defining characteristic of a true concept, as opposed to a syntactic constraint.+The ability to specify meaningful semantics is a defining characteristic of a true concept, as opposed to a syntactic constraint.

Ok, so this one is actually different from the other one.

I'm fine with reverting this change.

reunanen

comment created time in 19 days