Thread: Help understanding how "operator char*()" works.

Originally Posted by phantomotap

However, I think your point was probably: how do I prevent the silent conversion to 'const char *' from causing problems when used with the subtraction operator. The answer is the same for every operator associated with the intended conversion: provide the operator and either prevent successful compilation or crash with a well-formed error during execution.

That was kindof the point, wasn't it?
So, you have an example?
I'd love to see you thwart the happy little compiler.

Originally Posted by phantomotap

The best part of this is: you are both wrong. First, it isn't a counter. Second, even with the implicit conversion it would not compile for a conforming compiler. Subtracting two pointers yields an integer type and 'std::string' has no such constructor.

I do not see what "it isn't a counter" has to do with anything. Concerning the error: I ignored that part due to the disclaimer that only C++ Coding Standards incorporates corrections, but thinking about it further, it cuts both ways: suppose the constructor that creates a string with n characters was changed such that the null character was default. In that case, implicit conversion would allow Sutter's otherwise problematic original example to compile when the conversion function is provided.

Originally Posted by phantomotap

However, I think your point was probably: how do I prevent the silent conversion to 'const char *' from causing problems when used with the subtraction operator.

Precisely, though more generally, "to block otherwise logically illegal, or just silly, operations", as you yourself have pointed out much earlier.

Originally Posted by phantomotap

The answer is the same for every operator associated with the intended conversion: provide the operator and either prevent successful compilation or crash with a well-formed error during execution.

That is easier said than done. Providing a named conversion function, on the other hand, is as easily done as said, and avoids those problems associated with implicit conversions.

I'd love to see you thwart the happy little compiler.

O_o

Thwart the compiler?! Are you insane?! I'm suggesting you use the compiler. That's why it exists. What don't you get? You can literally use any method of static assertion or compiler firewall you desire.

As I've implied: I use a meta-function to do this for any or all of the operators applied to any number of types--actually limited to 64. The massive overhead would be pointless, but I'll offer a trivial and sloppy way to block an operator for a type you don't own without otherwise affecting the compiler output, messages or errors, from "correct" source. Enjoy.

That is easier said than done.

No. It isn't. I have a series of meta-functions that you simply invoke. (That is, it is as easy done as typed.)

Soma

Code:

class blocker{public: blocker(){} private:blocker(const blocker &){} friend blocker operator - (const my_string &, const my_string &);};

blocker operator -
(
  const my_string & lhs,
  const my_string & rhs
)
{
  blocker return_value;
  return(return_value);
}

Originally Posted by phantomotap

Thwart the compiler?! Are you insane?! I'm suggesting you use the compiler. That's why it exists. What don't you get? You can literally use any method of static assertion or compiler firewall you desire.

In my view, you are opening up evil conversion with the implicit type operator, but then you are blocking them... so you open them up to the compiler and then you block them for the compiler.
That, essentially means thwart the compiler in my book

Originally Posted by phantomotap

No. It isn't. I have a series of meta-functions that you simply invoke.

You still have to determine what to invoke, and have to update your code if there are additions to the target type interface (for class types not under your control, at least), even if these would not normally affect your code.

In my view, you are opening up evil conversion with the implicit type operator, but then you are blocking them...

O_o

Yea... that would be silly, but I'm not blocking the conversion. I'm telling the compiler that certain constructs are invalid... I'm basically marking conversions in certain contexts as private.

You still have to determine what to invoke, and have to update your code if there are additions to the target type interface (for class types not control your control, at least), even if these would not normally affect your code.

If your code would not be affected by such additions then, by definition, no source change would be needed regardless of the source written to prevent such constructs from compiling. (Edit: Actually, I may be giving to much credit here; it is possible to write source that depends upon the firewall for correct compilation, but it is very unlikely to happen by accident.) That said, if you desire that your source makes use of these additional facilities, you would have to change something, but that's always the case.

Soma

Originally Posted by phantomotap

I'm telling the compiler that certain constructs are invalid... I'm basically marking conversions in certain contexts as private.

Yes, it is like declaring copy constructors and copy assignment operators private in order to disable copying.

Originally Posted by phantomotap

If your code would not be affected by such additions then, by definition, no source change would be needed regardless of the source written to prevent such constructs from compiling.

Ah, but what if the type you are designing is intended for use (or just might be used) by another programmer (or team, as the case may be), as would be the case for a library? Such a source code change would be needed in order to maintain the interface provided.

Originally Posted by phantomotap

That said, if you desire that your source makes use of these additional facilities, you would have to change something, but that's always the case.

When you put it as "additional facilities", I tend to agree with the notion that this would be a viable alternative to a named conversion function, though I am not convinced that it is worth the effort when a named conversion function can be clearer and just shifts the burden on using sensible operations from other types to the user of the type you provide.

When you put it as "additional facilities", I tend to agree with the notion that this would be a viable alternative to a named conversion function, though I am not convinced that it is worth the effort when a named conversion function can be clearer and just shifts the burden on using sensible operations from other types to the user of the type you provide.

O_o

I think I've spotted a flaw in your understanding. In a perfect world the responsibility, or burden if you like, of disabling conversions for specific constructs belongs to the provider of a type. (You wouldn't, or shouldn't, in using my library, or any other, go into the headers to mark some method private even if it should have been marked private.) Even in our world of shambles, the responsibility belongs to a single type. (Granted, in this case I've offered that it can "fix" an existing provision that didn't account for unwanted implicit conversion by displacing this burden, but that's not really the point.) The relevant source, even without templates, need only be written to disallow problematic conversions for each implicitly converted type for any given class type with such implicit conversions. The 'blocking' type is a "no-op"; it is no more associated with the relevant type nor any more responsible than 'std::string' would be if someone provides 'std::string operator + (const std::vector<?> &, unsigned long)'.

Soma

PS. And not that it matters, but I'm a big fan of consistency. I teach people to use 'static_cast<?>' even with classes offering implicit conversion. (With an exception of 'operator void *' and 'operator bool' because stream using source seems "right" without it.)

It is interesting that you start by saying

No. They should not be avoided. If you do the work to block otherwise logically illegal, or just silly, operations they can make code much cleaner. (Of course, misused they can make code uglier, but that doesn't say much as it applies to most features of C++.)

and you finish with this

PS. And not that it matters, but I'm a big fan of consistency. I teach people to use 'static_cast<?>' even with classes offering implicit conversion. (With an exception of 'operator void *' and 'operator bool' because stream using source seems "right" without it.)

So you would prefer:

Code:

ofsteam fout(static_cast<const char*>(filename));
//over
ofstream fout(filename.c_str());

Does this apply only to string-like things? Many classes can return objects of various types from different methods, would you also make the classes castable into these types?

Code:

Character c;
//Rect r = c.bounding_rect();
Rect r = static_cast<Rect>(c);

Originally Posted by phantomotap

The relevant source, even without templates, need only be written to disallow problematic conversions for each implicitly converted type for any given class type with such implicit conversions.

I do not understand what you are trying to say in the sentence quoted above, so kindly explain and elaborate.

What I meant is that since a named conversion function forces the user of the type to explicitly request the conversion, any abuse of this conversion is the user's fault. With an implicit conversion function, any abuse of this conversion is both the user's fault and the type designer's (or implementor's) fault. The former is at fault for a mistake in using the type, and the latter is at fault for failing to disable the constructs that are not sensible.

The idea is that you create a function such as:
const char* get();
In your class instead of the implicit conversion operator:
operator const char* ();
This will eliminate the chance for these headaches.

Also, non-const char* is bad for encapsulation. Basically, by returning a non-const char*, you implicitly give clients of your class leave to do with your internal string data whatever they want - not a good idea when the char* really belongs to the string object.