Matthew wrote:
>   type opExplicitCast()
> 
>  is a good idea

Yup. If it doesn't complicate it for Walter too much.

>>Then i also have another idea. Some functions must be allowed to always
>>implicitly cast their input, even if only explicit cast is defined for
>>the input. Example:
>>
>>void sillyPrint(cast(char*) string)  { /+...+/ }
>>
>>Now, given any type, for which explicit or implicit cast is defined, it
>>would be implicitly cast to char* when fed to this function.
> 
> 
> Nope. Explicit generalisation through shims
> (http://www.cuj.com/documents/s=8681/cuj0308wilson/) is a far better
> approach. It has all of the benefits, without any of the gotchas.

It may not be appropriate in all cases. A shim requieres explicit knowledge of the type to cast from - which may not be available for sillyPrint being a library function. I'm not sure i can recall in which case exactly it would really be very desirable, but i recall having had something on my mind a while ago...

I know the conversion to char* is less than appropriate, and it was the reason why i called the function sillyPrint. ;) Luckily we have our char[], which contains length and can slice into any kind of string.

> Matthew
> 
> P.S. btw, Ilya, did I tell you that the last chapter in the book is
> Properties, as inspired by your good self? :)

Yes, and it's one of the reasons i'm so eagerly awaiting the book! Btw, have you seen some Andy's experiment on the subject?

http://ikagames.com/andy/property.h

-eye

> Matthew wrote:
> >   type opExplicitCast()
> >
> >  is a good idea
>
> Yup. If it doesn't complicate it for Walter too much.

I don't see how. (But then, I'm not a compiler-writer <g>)

> >>Then i also have another idea. Some functions must be allowed to always implicitly cast their input, even if only explicit cast is defined for the input. Example:
> >>
> >>void sillyPrint(cast(char*) string)  { /+...+/ }
> >>
> >>Now, given any type, for which explicit or implicit cast is defined, it would be implicitly cast to char* when fed to this function.
> >
> >
> > Nope. Explicit generalisation through shims (http://www.cuj.com/documents/s=8681/cuj0308wilson/) is a far better approach. It has all of the benefits, without any of the gotchas.
>
> It may not be appropriate in all cases. A shim requieres explicit knowledge of the type to cast from - which may not be available for sillyPrint being a library function. I'm not sure i can recall in which case exactly it would really be very desirable, but i recall having had something on my mind a while ago...

I'm not sure if we're on the same page here. A shim is used to facilitate conversion between logically related, but physically unrelated, types.

For example, we can define a functor (C++) that uses the c_str_ptr() shim:

template <typename C>
struct path_exists
{
public:
  template <typename S>
  bool operator ()(S const &file) const
  {
    return exists_(c_str_ptr(file));
  }
private:
  static bool exist_(C const *file)
  {
    . . . // OS test for file existence
  }
};

and we can use this with *any* type for which the c_str_ptr() shim is valid.

In STLSoft, there are shims defined for all manner of things, so you can use the above functor in containers of BSTR, VARIANT, LSA_UNICODE_STRING, basic_string<>, char *, wchar_t*, stlsoft::basic_simple_string<>, HWND, etc. etc.

The important point is that there is unlimited generality, but because it is explicit - i.e. the path_exists functor contains a call to c_str_ptr() - there are no occasions where they can be called "by mistake" by the compiler. It's basically your classic win-win (apart from the odd hassle with Koenig lookup from dimwitted compilers)

> I know the conversion to char* is less than appropriate, and it was the reason why i called the function sillyPrint. ;) Luckily we have our char[], which contains length and can slice into any kind of string.
>
> > Matthew
> >
> > P.S. btw, Ilya, did I tell you that the last chapter in the book is Properties, as inspired by your good self? :)
>
> Yes, and it's one of the reasons i'm so eagerly awaiting the book! Btw, have you seen some Andy's experiment on the subject?

Good to hear! The properties templates will be released in STLSoft 1.7.1, which should be within the next 4-5 weeks, so they'll be available a few months before the book is. Also, it's likely that there'll be at least one article in CUJ on the subject around the middle of the year, probably just a few weeks before the book is launched.

> http://ikagames.com/andy/property.h

No. I'll check it out. Does the implementation provide 100% speed efficiency, and 100% space efficiency for internally represented properties? Does it provide for field and method based properties? (Hopefully he's not stolen all my thunder <G>)

Cheers

Matthew

P.S. I'm looking for volunteers for reviewing on the next book - taking some deep looks into STL - if anyone wants to volunteer. I understand if you don't, of course, as you may wish to save up your offers of service for the D book, which is the one after, if the current planning pans out. :)

Ilya Minkov wrote:
...
> or even, let the return type be the type to cast to.
> 
>     char * opCast() { return toStringz(str); }


I was going to suggest that first, but since you can't overload return values, I thought using an out parameter would be easier to implement.

> > P.S. btw, Ilya, did I tell you that the last chapter in the book is Properties, as inspired by your good self? :)
>
> Yes, and it's one of the reasons i'm so eagerly awaiting the book! Btw, have you seen some Andy's experiment on the subject?
>
> http://ikagames.com/andy/property.h

Hmm. It looks like this technique provides property-proxy objects, which one instantiates from a particular class instance, and which then provides property-like (get and/or set) access for the instance for which it acts.

The Imperfect C++ / STLSoft properties are part of the classes for which they act; they're exactly as you'd expect from any other language which provides them as a built-in feature. (And they're stinkingly efficient! :)

Vathix wrote:
>>     char * opCast() { return toStringz(str); }
> 
> I was going to suggest that first, but since you can't overload return values, I thought using an out parameter would be easier to implement.

Whoops! My fault. You are right. In my background, return values cannot be discarded and thus overloads on return value are feasible. ;) But in D this doesn't hold true.

-eye