digitalmars.D - std.recls - FTP raises linkage issue
- Matthew (41/41) Jun 01 2004 Hi
- Regan Heath (11/71) Jun 01 2004 Sounds very natty.
- Matthew (10/73) Jun 02 2004 The "why not" is that, AFAIK, classes (and I think modules also) are lin...
- Sean Kelly (8/12) Jun 02 2004 Personally, I never link to wininet.lib because it has one major deficie...
- Hauke Duden (4/15) Jun 02 2004 The other major deficiency being, of course, that it isn't available on
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
-------------------------------------------------------------------------------
Jun 01 2004
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 multifileWalter 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/
Jun 01 2004
"Matthew" <matthew.hat stlsoft.dot.org> "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: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.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 multifileWalter 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.
Jun 02 2004
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
Jun 02 2004
Sean Kelly wrote:The other major deficiency being, of course, that it isn't available on all Windows versions. HaukeBut 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.
Jun 02 2004
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message news:c9l14k$2e7m$1 digitaldaemon.com...Sean Kelly wrote:Win32):But here's the rub. There are two choices for the implementation (onwininet.lib. MyA. Build it all, and require that users of recls/phobos link tonon-trivialinstincts rail against such things, but then pretty much any moderndeficiency --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 majorworthmany 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 ispoint out.hand-coding an FTP lib to work around it, but something I wanted toThe 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.
Jun 04 2004
"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...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.Sean Kelly wrote:Win32):But here's the rub. There are two choices for the implementation (onwininet.lib. MyA. Build it all, and require that users of recls/phobos link tonon-trivialinstincts rail against such things, but then pretty much any moderndeficiency --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 majorworthmany 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 ispoint out.hand-coding an FTP lib to work around it, but something I wanted toThe 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.
Jun 05 2004