Hi Scott, On 20 May 2010 18:56, Scott McMurray <me22.ca+boost@gmail.com> wrote:
On 20 May 2010 10:58, Artyom <artyomtnk@yahoo.com> wrote:
If so give me one reason why should my application be compiled for each type of these?
Good luck :-)
Give me one reason why I should have to link all of those into my binary when I only deploy using one of them.
And Thorsten's request is just to make the virtual optional, not to remove it altogether. You can still make it runtime-configurable if you insist.
I've been tinkering with a dynamic layer above the low-level templated code that would be runtime-configurable when finished. This has been the first suggestion I've had from a few people and not an unreasonable request by any means. Two things that have come up so far are: 1. The dynamic interface unsuprisingly lends itself to having a compiled library for the library functions. At this early stage I'm tempted to make "compiled" the default choice - ie. using the dynamic portion of the library would simply mean including some declaration-only headers and having everything else hidden in a single library. This would mean very fast compiles and small application binaries. I don't see at the moment why the .cpp files couldn't actually be .ipp files that could optionally be included in the headers to prevent the need to link against a CGI library. 2. The dynamic interface seems to lend itself to a really simple Python binding. I'm not convinced there is any point in going very far down this route as Python is awash with CGI libraries and WSGI seems to be the de-facto standard anyway. Still, Python's FastCGI support is based on the standard FastCGI library so there might be some room for gains. Thoughts? Cheers, Darren