C does not prohibit dereferencing the null pointer, it merely makes it undefined behavior. If your environment is such that you’re able to dereference a pointer containing the address 0x0, then you should be able to do so. The C language standard says nothing about what will happen when you do so. (In most environments, … Read more
Static member functions were added into C++ in 1989, in Release 2.0 of the AT&T C++ Language System (pre-standardisation). Prior to that, the static keyword could not be used to declare static member functions, so code authors used workarounds, principally the one you have observed of indirecting a null pointer. In the Selected Readings accompanying … Read more
In The Development of the C Language, Dennis Ritchie explains his reasoning thusly: The second innovation that most clearly distinguishes C from its predecessors is this fuller type structure and especially its expression in the syntax of declarations… given an object of any type, it should be possible to describe a new object that gathers … Read more
the rules regarding Deref and DerefMut were designed specifically to accommodate smart pointers. Because of this, Deref should only be implemented for smart pointers to avoid confusion. — std::ops::Deref I think it’s a bad practice. since I can use my newtype as if it were the underlying type in some situations That’s the problem — … Read more
I saw a question the other day where someone inadvertently used an incomplete type by specifying something like struct a { int q; }; struct A *x; x->q = 3; The compiler knew that struct A was a struct, despite A being totally undefined, by virtue of the struct keyword. That was in C++, where … Read more
I assume you mean “is an iterator valid,” that it hasn’t been invalidated due to changes to the container (e.g., inserting/erasing to/from a vector). In that case, no, you cannot determine if an iterator is (safely) dereferencable.
10000 ints will not be copied. Dereferencing is very cheap. To make it clear you can rewrite int a = (*vecPtr)[i]; as vector<int>& vecRef = *vecPtr; // vector is not copied here int a = vecRef[i]; In addition, if you are afraid that the whole data stored in vector will be located on the stack … Read more
billProductSet is a Collection. As such, it does not have an attribute named product. Product is an attribute of the elements of this Collection. You can fix the issue by joining the collection instead of dereferencing it: SELECT count(*) FROM BillDetails bd JOIN bd.billProductSet bps WHERE bd.client.id = 1 AND bps.product.id = 1002
Referencing means taking the address of an existing variable (using &) to set a pointer variable. In order to be valid, a pointer has to be set to the address of a variable of the same type as the pointer, without the asterisk: int c1; int* p1; c1 = 5; p1 = &c1; //p1 references … Read more
Using * to dereference a reference wouldn’t be correct in C++. So I’d like to understand why this is correct in Rust. A reference in C++ is not the same as a reference in Rust. Rust’s references are much closer (in usage, not in semantics) to C++’s pointers. With respect to memory representation, Rust’s references … Read more