any tool to at least partially convert C++ to D (htod for source

Justin Johansson no at spam.com
Wed Mar 10 11:09:05 PST 2010


Nick Sabalausky Wrote:

> "Justin Johansson" <no at spam.com> wrote in message 
> news:hn6evv$hl7$1 at digitalmars.com...
> > Walter Bright Wrote:
> >
> >> Justin Johansson wrote:
> >> > Having spent six months developing a significant app in D only to find 
> >> > impediments to
> >> > practical completion of the project and ultimate deployment,
> >>
> >> Which ones did you find to be blocking?
> >
> > (My time zone is way different to yours and gotta dash to work soon so 
> > will have to be brief).
> >
> > (Comments in relation to D1)
> >
> > The #1 show-stopper for me was lack of shared object (.so) support under 
> > Linux; virtually
> > mandated by my audience (Apache/LAMP).  (A workaround like FastCGI is 
> > simply not
> > appealing to customers.)  This topic discussed many times before on this 
> > NG.
> >
> 
> When you have a chance, I'm curious to hear why you feel something like 
> FastCGI is unappealing to customers compared to .so. I assume there's more 
> to it than it just not being "trendy" enough. (For me personally, the issue 
> is moot b/c my clients are generally on shared hosting from questionable 
> providers, so I pretty much have to stick with PHP or Haxe. Or ASP, 
> depending on the client). 

Hi Nick,

The product I'm developing is a library that will be/can be integrated into a
number of Apache modules (e.g. mod_python) for webby-type applications
(e.g. SOA) and needs to execute in-process.  It cannot be easily integrated
in-process-wise with FastCGI.  The only other option is to offer it as statically linked
library but for a variety of reasons (convenience of deployment, commercial etc),
dynamic linking via a shared library is really the only way to go.

Probably my choice of words (unappealing) may have misled you into thinking
that FastCGI might have been an option for me but it is not.

Cheers, JJ




More information about the Digitalmars-d mailing list