[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: New public API
I should have given an intro to the list about what we are working on.
Me and author of CSP (C++ Server Pages) decided to try to get common public API. This way Servlet writers can easily migrate between the projects (both have their pros and cons)
The API has to be as close to java as possible. At the same time it should be easy to use.
In our case we are talking about two things: attributes, and parameters.
Attributes is name-value table where value is of any type.
Parameters is name->values table with values being list of strings.
Back end should be completely reimplementable.
-----Original Message-----
From: "Alexey Parshin" <alexeyp@gmail.com>
Date: Tue, 21 Feb 2006 11:51:51
To:"C++ Servlet Engine Discussion" <cppserv@total-knowledge.com>
Subject: Re: New public API
Yeah, that's a pre-requirement. But in that case, returning just const char
* is more appropriate..
2006/2/21, Ilya Volynets <ilya@total-knowledge.com>:
>
> This is one of the options I was thinking about. Only problem is that
> source of the data may not be of the appropriate type.
> Example:
> In Krzyzstov's case, where he embeds his servlet container directly into
> Apache, header values are stored as table of (char*, char*)
> If we retrieve this data and return it
> as std::string we'd have to store it
> somewhere.
>
> -----Original Message-----
> From: "Alexey Parshin" <alexeyp@gmail.com>
> Date: Tue, 21 Feb 2006 11:20:48
> To:"C++ Servlet Engine Discussion" <cppserv@total-knowledge.com>
> Subject: Re: New public API
>
> IMHO, ref counting is bad :( Every time I've used strings with ref
> counting
> it was giving me one problem or another. Of course, it depends on coding
> style..
>
> We can solve that problem partually if we return "const string&".
>
> In that case, if one wants just to use a string w/o altering its content -
> it can be done like this:
>
> const string& myString = myClass.myMethod();
> cout << myString << endl;
>
> Does it make sense to you? This approach is pretty effective.
>
> 2006/2/21, Ilya Volynets <ilya@total-knowledge.com>:
> >
> > 1. Don't know. Maybe yes maybe no
> > In any case - it's probably be bad with gcc.
> > 2. Let's see if we can get reasonable ref counting
> >
> > -----Original Message-----
> > From: Krzysztof Rzymkowski <rzymek@gmail.com>
> > Date: Tue, 21 Feb 2006 00:24:56
> > To:C++ Servlet Engine Discussion <cppserv@total-knowledge.com>
> > Subject: Re: New public API
> >
> > On Mon, 2006-02-20 at 22:37 +0000, Ilya Volynets wrote:
> > > I am aware of retval optimization, though I am not sure about
> semantics
> > in case of C++ - what if copy constructor has side effects?
> > >
> > Are you sure there's a guarantee that a copy constructor will be called
> > when an object is returned by value? I think there's no such guarantee,
> > nor there should be any.
> >
> > > As for optimizations on copy from
> > > The library, I'm not sure again - I
> > > think it's *supposed* to copy in this case, but I don't remember.
> > >
> > > Auto-ptr/ref counting is something I'd prefer, and it's semantically
> > closest to java
> >
> > Now the question is: is allocating heap memory via new is that much
> > faster then copying an object? (Though in case of a big vector is sure
> > is)
> >
> > >
> > > -----Original Message-----
> > > From: Krzysztof Rzymkowski <rzymek@gmail.com>
> > > Date: Mon, 20 Feb 2006 23:15:18
> > > To:C++ Servlet Engine Discussion <cppserv@total-knowledge.com>
> > > Subject: Re: New public API
> > >
> > > On Mon, 2006-02-20 at 11:00 -0800, Ilya A. Volynets-Evenbakh wrote:
> > > > One thing I was thinking about (and even started using in some
> cases)
> > > > is to change methods returing collections. The way it is now:
> > > > virtual std::vector<std::string> getAttributeNames()
> > > > This means that whole vector, as well as every string inside will be
> > copied
> > > > (possibly twice - inside function when creating retval, and then to
> > the
> > > > actual
> > > > return value). Now, instead we could change signiture as follows:
> > > > virtual void getAttributeNames(std::vector<std::string> &out)
> > > > This will avoid unnessesary copying.
> > > >
> > > > Java does not have to worry about it, since it returns references,
> and
> > thus
> > > > only one copy of object is created.
> > >
> > > It is possible for a STL implementation to user reference counting in
> > > vector's copy constructor, thought the SGI's STL does simple copying.
> > > It is as well possible for the compiler to use return value
> optimization
> > > [1], thought it is not always possible to write the getters in a way
> > > which allows RVO.
> > >
> > > Another option would be to use std::auto_ptr [2] or boost::shared_ptr
> > > [3].
> > >
> > > I would like to keep the API as close to the Java version as it is
> > > possible. So I'd rather stick with option 1 (ignore the problem) or 2
> > > user some sort of reference counting.
> > >
> > > [1] http://cpptips.hyperformix.com/cpptips/ret_val_opt
> > > [2] http://gcc.gnu.org/onlinedocs/libstdc
> > > ++/latest-doxygen/classstd_1_1auto__ptr.html
> > > [3] http://www.boost.org/libs/smart_ptr/shared_ptr.htm
> > --
> >
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net
>
--
Alexey Parshin,
http://www.sptk.net