Hi

I want to canvas opinion regarding the forthcoming updates to recls, which will be reflected in D very soon.

Simply put, recls has had two externally visible enhancements:

1. One can now specify multi-part filters, e.g. "*.cpp;*.d;makefile*, which is far more convenient (and efficient) than conducting N separate searches. I'm assuming this will be welcomed by all, but I'm open to being surprised. <G>

2. recls can now enumerate FTP hierarches (currently Win32 only), as well as the local file-system. Naturally, this is a very nice thing, and I'm hoping people will think it's as cool as I do. I intend to write a very succinct sample program for Phobos that does a recursive attribute/size/date diff between a local directory and an FTP site. As well as a nice example of the succinctness of D's power, this tool'll simplify my life enormously. ;)

But here's the rub. There are two choices for the implementation (on Win32):

A. Build it all, and require that users of recls/phobos link to wininet.lib. My instincts rail against such things, but then pretty much any modern non-trivial Win32 app links in WinInet, so maybe it's a non-issue after all.

B. Provide a separate D component for FTP enumeration. Since D requires that modules cannot be multifile, this could not be in the std.recls namespace, and, IMO, would be too much hard work for the implementors and users alike.

So, it seems to me that we have to link Phobos to WinInet. Either that, or the D community states that they don't want FTP enumeration (and we build Phobos with RECLS_NO_FTP_API defined).

Actually, there's a third choice. We can provide a static WinInet stub library, which only loads and invokes the real WinInet.DLL functions when required. When not, it'll occupy only a few byes of one's exe. Of course, if Walter would implement delay loading linking for DMC++ this would be non-issue. (Walter: if that's already in, please require me to eat my shorts, but don't forget to publicise this facility more thoroughly.)

I'd be interested to here any/all thoughts.


Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

-------------------------------------------------------------------------------

"So far, C++ is the best language I've discovered to say what I want to say" -- Alex Stepanov

-------------------------------------------------------------------------------

On Wed, 2 Jun 2004 13:43:24 +1000, Matthew <matthew.hat@stlsoft.dot.org> wrote:
> I want to canvas opinion regarding the forthcoming updates to recls, which will be reflected in D very soon.
>
> Simply put, recls has had two externally visible enhancements:
>
> 1. One can now specify multi-part filters, e.g. "*.cpp;*.d;makefile*, which is
> far more convenient (and efficient) than conducting N separate searches. I'm
> assuming this will be welcomed by all, but I'm open to being surprised. <G>

Sounds very natty.

> 2. recls can now enumerate FTP hierarches (currently Win32 only), as well as the
> local file-system. Naturally, this is a very nice thing, and I'm hoping people
> will think it's as cool as I do. I intend to write a very succinct sample program
> for Phobos that does a recursive attribute/size/date diff between a local
> directory and an FTP site. As well as a nice example of the succinctness of D's
> power, this tool'll simplify my life enormously. ;)
>
> But here's the rub. There are two choices for the implementation (on Win32):
>
> A. Build it all, and require that users of recls/phobos link to wininet.lib. My
> instincts rail against such things, but then pretty much any modern non-trivial
> Win32 app links in WinInet, so maybe it's a non-issue after all.

The key word being "non-trivial". Would this force a trivial program to link against it unnecessarily?

> B. Provide a separate D component for FTP enumeration. Since D requires that
> modules cannot be multifile

Walter may be thinking about changing this... Walter?

> , this could not be in the std.recls namespace, and,
> IMO, would be too much hard work for the implementors and users alike.
>
> So, it seems to me that we have to link Phobos to WinInet. Either that, or the D
> community states that they don't want FTP enumeration (and we build Phobos with
> RECLS_NO_FTP_API defined).

I think we want to be able to choose to have FTP enumeration, and if we choose not to, we should not have to link against WinInet. We should be able to achieve that, if not, why not.

> Actually, there's a third choice. We can provide a static WinInet stub library,
> which only loads and invokes the real WinInet.DLL functions when required. When
> not, it'll occupy only a few byes of one's exe. Of course, if Walter would
> implement delay loading linking for DMC++ this would be non-issue. (Walter: if
> that's already in, please require me to eat my shorts, but don't forget to
> publicise this facility more thoroughly.)
>
> I'd be interested to here any/all thoughts.
>
>
> Matthew Wilson
>
> Author: "Imperfect C++", Addison-Wesley, 2004
>     (http://www.imperfectcplusplus.com)
> Contributing editor, C/C++ Users Journal
>     (http://www.synesis.com.au/articles.html#columns)
> STLSoft moderator
>     (http://www.stlsoft.org)
>
> -------------------------------------------------------------------------------
>
> "So far, C++ is the best language I've discovered to say what I want to say" --
> Alex Stepanov
>
> -------------------------------------------------------------------------------
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opr8x9s1wf5a2sq9@digitalmars.com...
> On Wed, 2 Jun 2004 13:43:24 +1000, Matthew <matthew.hat@stlsoft.dot.org> wrote:
> > I want to canvas opinion regarding the forthcoming updates to recls, which will be reflected in D very soon.
> >
> > Simply put, recls has had two externally visible enhancements:
> >
> > 1. One can now specify multi-part filters, e.g. "*.cpp;*.d;makefile*,
> > which is
> > far more convenient (and efficient) than conducting N separate searches.
> > I'm
> > assuming this will be welcomed by all, but I'm open to being surprised.
> > <G>
>
> Sounds very natty.
>
> > 2. recls can now enumerate FTP hierarches (currently Win32 only), as
> > well as the
> > local file-system. Naturally, this is a very nice thing, and I'm hoping
> > people
> > will think it's as cool as I do. I intend to write a very succinct
> > sample program
> > for Phobos that does a recursive attribute/size/date diff between a local
> > directory and an FTP site. As well as a nice example of the succinctness
> > of D's
> > power, this tool'll simplify my life enormously. ;)
> >
> > But here's the rub. There are two choices for the implementation (on
> > Win32):
> >
> > A. Build it all, and require that users of recls/phobos link to
> > wininet.lib. My
> > instincts rail against such things, but then pretty much any modern
> > non-trivial
> > Win32 app links in WinInet, so maybe it's a non-issue after all.
>
> The key word being "non-trivial". Would this force a trivial program to link against it unnecessarily?
>
> > B. Provide a separate D component for FTP enumeration. Since D requires
> > that
> > modules cannot be multifile
>
> Walter may be thinking about changing this... Walter?
>
> > , this could not be in the std.recls namespace, and,
> > IMO, would be too much hard work for the implementors and users alike.
> >
> > So, it seems to me that we have to link Phobos to WinInet. Either that,
> > or the D
> > community states that they don't want FTP enumeration (and we build
> > Phobos with
> > RECLS_NO_FTP_API defined).
>
> I think we want to be able to choose to have FTP enumeration, and if we choose not to, we should not have to link against WinInet. We should be able to achieve that, if not, why not.
>
> > Actually, there's a third choice. We can provide a static WinInet stub
> > library,
> > which only loads and invokes the real WinInet.DLL functions when
> > required. When
> > not, it'll occupy only a few byes of one's exe. Of course, if Walter
> > would
> > implement delay loading linking for DMC++ this would be non-issue.
> > (Walter: if
> > that's already in, please require me to eat my shorts, but don't forget
> > to
> > publicise this facility more thoroughly.)
> >
> > I'd be interested to here any/all thoughts.

The "why not" is that, AFAIK, classes (and I think modules also) are linked atomically. In other words, if I use part of a class, I still have to resolve all the symbols that are used by the rest of that class.

Unless we do either the delay-loading (whether the compiler-provided version, or a manual one), then we have no real choice but to require linking to wininet.lib. The alternative is just hideously messy.

Maybe it's not an issue though, since it's a system DLL, and we're already binding to most of them in non-trivial programs.

In article <c9jid0$930$1@digitaldaemon.com>, Matthew says...
>
>But here's the rub. There are two choices for the implementation (on Win32):
>
>A. Build it all, and require that users of recls/phobos link to wininet.lib. My instincts rail against such things, but then pretty much any modern non-trivial Win32 app links in WinInet, so maybe it's a non-issue after all.

Personally, I never link to wininet.lib because it has one major deficiency -- many of the features only work in user mode (ie. they don't work if the application is running as an NT service).  I'm not sure that this is worth hand-coding an FTP lib to work around it, but something I wanted to point out.

Beyond that, I don't have a problem linking to wininet.lib for my Windows-based D applications.


Sean

Sean Kelly wrote:
>>But here's the rub. There are two choices for the implementation (on Win32):
>>
>>A. Build it all, and require that users of recls/phobos link to wininet.lib. My
>>instincts rail against such things, but then pretty much any modern non-trivial
>>Win32 app links in WinInet, so maybe it's a non-issue after all.
> 
> 
> Personally, I never link to wininet.lib because it has one major deficiency --
> many of the features only work in user mode (ie. they don't work if the
> application is running as an NT service).  I'm not sure that this is worth
> hand-coding an FTP lib to work around it, but something I wanted to point out.

The other major deficiency being, of course, that it isn't available on all Windows versions.

Hauke

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c9l14k$2e7m$1@digitaldaemon.com...
> Sean Kelly wrote:
> >>But here's the rub. There are two choices for the implementation (on
Win32):
> >>
> >>A. Build it all, and require that users of recls/phobos link to
wininet.lib. My
> >>instincts rail against such things, but then pretty much any modern
non-trivial
> >>Win32 app links in WinInet, so maybe it's a non-issue after all.
> >
> >
> > Personally, I never link to wininet.lib because it has one major
deficiency --
> > many of the features only work in user mode (ie. they don't work if the application is running as an NT service).  I'm not sure that this is
worth
> > hand-coding an FTP lib to work around it, but something I wanted to
point out.
>
> The other major deficiency being, of course, that it isn't available on all Windows versions.

In that case, it should do a runtime check & load rather than a static link.

"Walter" <newshound@digitalmars.com> wrote in message news:c9p94o$2kb6$2@digitaldaemon.com...
>
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c9l14k$2e7m$1@digitaldaemon.com...
> > Sean Kelly wrote:
> > >>But here's the rub. There are two choices for the implementation (on
> Win32):
> > >>
> > >>A. Build it all, and require that users of recls/phobos link to
> wininet.lib. My
> > >>instincts rail against such things, but then pretty much any modern
> non-trivial
> > >>Win32 app links in WinInet, so maybe it's a non-issue after all.
> > >
> > >
> > > Personally, I never link to wininet.lib because it has one major
> deficiency --
> > > many of the features only work in user mode (ie. they don't work if the application is running as an NT service).  I'm not sure that this is
> worth
> > > hand-coding an FTP lib to work around it, but something I wanted to
> point out.
> >
> > The other major deficiency being, of course, that it isn't available on all Windows versions.
>
> In that case, it should do a runtime check & load rather than a static link.

Ok, I'll work on that. It'll require some hokey #define / #include magic, but that's one of the things C/C++ are good at. He he ...

However, there is one problem. What do we do about when people want to link to WinInet within their own work? Can anyone envisage problems with WinInet doing initialisation differently when implicitly vs explicitly loaded.