Help me please. I want to make my class for range statement compliant. That means I need the required overloaded operators defined and define begin and end functions.
What I don't want is for anything else except for range to be able to use the defined begin and end functions . Simply because it wouldn't be needed otherwise.
How can I make range for statement a friend of my class?
It’s not possible to restrict the use of begin/end to the range-for statement, since it is defined as equivalent to a certain compound statement that looks them up without any special access permission. The closest you can get is to make them hidden friends, but that doesn’t hide them when their argument is of the class type in question!
Related
I found this on cppreference:
Following types are derived from std::ranges::view_interface and do
not declare their own size member function, but they cannot use the
default implementation, because their iterator and sentinel types
never satisfy sized_sentinel_for:
std::ranges::basic_istream_view
std::ranges::filter_view
std::ranges::join_view
std::ranges::split_view
std::ranges::take_while_view
This makes sense since those views can not calculate size in O(1). But I do not understand why then not make more than one base class for views, for example something like view_interface but without size member?
I presume that one possible reason is that ranges are already a insanely complicated library, but maybe I am missing something else.
If you wonder why this is a problem: maybe it is not, but I think/feel it is confusing to users since those views have member function that never works.
note: I know I can use distance, this is a question about design.
A class template is not a class. std::ranges::view_interface is not the base class of anything.
std::ranges::view_interface<std::ranges::filter_view<V, Pred>> does not have a size member. Other instantiations of std::ranges::view_interface do, but it's always been possible for one instantiation of a template to have members that another doesn't have.
The documentation for std::ranges::view_interface does mention that size is only present if (among other things) its sentinel and iterator type satisfy std::sized_sentinel_for.
I much prefer having one name that calculates appropriate capabilities, than a multitude of different names for subtly different capabilities. It is more extensible, if additional members are defined in later standards, everything automatically gains the members that it supports, without having to change e.g. sized_forward_view_interface to foobar_sized_forward_view_interface.
I want to overload "->" operator globally for pointers. Is it possible?
A *var1 = new A(21);
int x = var1->someInt;
In that code it has to be triggered when reaching "var1"s "someInt" variable.
Actually I am trying to check the pointer before reaching its members. Also, I am trying to implement this system on a written code, so I don't want to change too much thing in the actual code.
I want to overload "->" operator globally. Is it possible?
No it is impossible.
Perhaps you might define a "root" class in your library or program (which would define that operator ->), and have all your classes inherit from it.
BTW, I am not sure you will be able to define your isPointerValid function in all cases (including the address of valid automatic variables of any class type), and efficiently.
There are many cases where you could not define such a function (e.g. union-s used in tagged union types; you don't easily know what member of a union is currently active. arbitrary casts; ...); .
For existing code and classes, the builtin meaning of -> (which you usually cannot redefine) has already been used to compile the code using them.
As described in C++17 standard draft in section 16.5.6 (emphasis mine):
An operator function shall either be a non-static member function or
be a non-member function that has at least one parameter whose type
is a class, a reference to a class, an enumeration, or a reference to
an enumeration.
Hence, it is not possible to overload an operator which doesn't take any arguments.
I'm a student. Let's say I want to be able to do my_string.reverse();. I don't want to see the actual code to reverse a string, I just want to see how this function would be implemented for strings.
A side question: why have I never seen this dot operator used with types such as int or char, is that simply not possible?
You can't overload the member access operator; and you can't add members to an already defined class. If the type of my_string doesn't have a reverse member, and you can't (or don't want to) add one to the class definition, then you simply can't do anything to provide that syntax.
If you want to write a function to manipulate a class without changing the class definition, it will have to be a non-member function, called as e.g. reverse(my_string).
why have I never seen this dot operator used with types such as int or char, is that simply not possible?
No it isn't. The language only defines that operator for class types, and doesn't allow it to be overloaded.
Why are those C++11 new functions of header <string> (stod, stof, stoull) not member functions of the string class ?
Isn't more C++ compliant to write mystring.stod(...) rather than stod(mystring,...)?
It is a surprise to many, but C++ is not an Object-Oriented language (unlike Java or C#).
C++ is a multi-paradigm language, and therefore tries to use the best tool for the job whenever possible. In this instance, a free-function is the right tool.
Guideline: Prefer non-member non-friend functions to member functions (from Efficient C++, Item 23)
Reason: a member function or friend function has access to the class internals whereas a non-member non-friend function does not; therefore using a non-member non-friend function increases encapsulation.
Exception: when a member function or friend function provides a significant advantage (such as performance), then it is worth considering despite the extra coupling. For example even though std::find works really well, associative containers such as std::set provide a member-function std::set::find which works in O(log N) instead of O(N).
The fundamental reason is that they don't belong there. They
don't really have anything to do with strings. Stop and think
about it. User defined types should follow the same rules as
built-in types, so every time you defined a new user type,
you'd have to add a function to std::string. This would
actually be possible in C++: if std::string had a member
function template to, without a generic implementation, you
could add a specialization for each type, and call
str.to<double>() or str.to<MyType>(). But is this really
what you want. It doesn't seem like a clean solution to me,
having everyone writing a new class having to add
a specialization to std::string. Putting these sort of things
in the string class bastardizes it, and is really the opposite
of what OO tries to achieve.
If you were to insist on pure OO, they would have to be
members of double, int, etc. (A constructor, really. This
is what Python does, for example.) C++ doesn't insist on pure
OO, and doesn't allow basic types like double and int to
have members or special constructors. So free functions are
both an acceptable solution, and the only clean solution
possible in the context of the language.
FWIW: conversions to/from textual representation is always
a delicate problem: if I do it in the target type, then I've
introduced a dependency on the various sources and sinks of text
in the target type---and these can vary in time. If I do it in
the source or sink type, I make them dependent on the the type
being converted, which is even worse. The C++ solution is to
define a protocol (in std::streambuf), where the user writes
a new free function (operator<< and operator>>) to handle
the conversions, and counts on operator overload resolution to
find the correct function. The advantage of the free function
solution is that the conversions are part of neither the data
type (which thus doesn't have to know of sources and sinks) nor
the source or sink type (which thus doesn't have to know about
user defined data types). It seems like the best solution to
me. And functions like stod are just convenience functions,
which make one particularly frequent use easier to write.
Actually they are some utility functions and they don't need to be inside the main class. Similar utility functions such as atoi, atof are defined (but for char*) inside stdlib.h and they too are standalone functions.
Can I use forward declaration for a class in order to put it's definition and Implementation later in the program after it's been used (similar to what is done about functions)?
(I need to join multiple source files of a program into a file, and i want to put the classes' definitions and Implementations at the end of the file in order to main be at the top of the file.)
Yes you can, to a certain extent.
You have to realize that the C++ compiler is quite stupid, and doesn't read ahead. This is the reason why you have to use function prototypes (among some other reasons).
Now, a function isn't hard for compiler to resolve. It just looks at the return type of the function, and the types of the parameters of the function, and just assumes that the function is there, without any knowledge about what's actually inside the function, because it ultimately doesn't matter at that point.
However, the contents of the class do matter (the compiler needs to know the size of the class for example). But remember about the not reading ahead bit? When you forward define a class, the compiler doesn't know about what's in it, and therefore is missing a lot of information about it. How much space does is need to reserve for example?
Therefore, you can forward define classes, but you can't use them as value types. The only thing you can do with it (before it has been concretely declared), is use pointers to it (and use it as a function return type and template argument, as pointer out by
#Cheersandhth.-Alf).
If the thing you need to use isn't a pointer, you should probably use headers (read this if you want to learn more about that).
Without a class definition somewhere earlier, you can't use any class members, nor can you create any instances, but you can
use T* and T& types,
use T for formal return type and parameter declarations (yes even by value),
use T as a template parameter,
and possibly more, but the above is what occurred to me immediately.
So if that's all you need, then you're set to go with the forward-declarations.
However, all that the forward declaring buys you in the sketched situation is added work, maintaining the same code in two places, so it's difficult to see the point of it…
Oh, I just remembered, there is a particularly nasty Undefined Behavior associated with forward-declared incomplete types, namely using delete p where p is a pointer to incomplete type. This requires the destructor to be trivial. If the compiler is good then it warns, but don't count on it.
In summary, I would just place main at the very end of that code, where it belongs, avoiding all the problems.