I feel that you avoid answering what it is that your
*CMW* *does* *better* than competition for example
Protocol Buffers. Where is the edge from what you are
above?
Boost has rather small amount of executables (Build,
Wave and few others) indeed and code generation is
done mostly by meta-programming (that I don't like).
Would someone be willing to supply me with the
Protocol Buffers pieces to serialize and deserialize
a ::std::vector<::std::deque<double> > ?
If so, I'll work on writing a test with CMW code
that compares these. Tia.
You sell non-standard language-specific alternative to
wide set of well-established open and language-neutral
solutions. You sell it to engineers. Yet you openly tell
that you need help in finding out if it is outstanding in
anything at all?
It's free.
I have tests that compare with the serialization
library in Boost.
I haven't updated my site yet, but I'm updating
those tests using Boost 1.55. For the
vector<deque<double> > test, the Boost version is
over 2 times slower than the CMW version. The
Boost-based executable is over 3 times larger than
the CMW-based executable.
I'm not sure Protocol Buffers is worth comparing
against. If someone is interested in seeing that,
they can do a little bit to make it happen. I'm
happy to turn over my side of the test so they
can do the comparison at their location also.
Its usage is very narrow (being language- and version-specific).
Basically clipboard operations (undo/redo/cut/paste) within single
application and dumping objects into text or xml file or log for
debugging/problem reporting/code generation purposes.
For those things it is adequate; it does not matter if undo takes
25 or 50 milliseconds. CMW feels even more narrow in sense that
it does not look like suitable for most of named use-cases.
It is more likely that someone wanting to actually serialise
something between applications/services using boost uses
Boost.PropertyTree instead.
Yes, but what use case it is that you compare?
You push that 'std::vector<std::deque<double> >' reflection?
Typically it is implementation detail that may change between
versions. It is likely that profiling shows in version 2.1 that
'std::valarray' trumps 'std::deque' but it can't be done since
that would make CMW of 2.2 not compatible with 2.1.
Telling
that it is indexed collection of indexed collections of floating
point values gives it more longevity and is neutral to
programming language.
If C++ reflection is major property for you then there is cereal.
http://uscilab.github.io/cereal/index.html (has JSON/XML and
various binary representations).
There are even attempts of
making reflection libraries:
https://bitbucket.org/dwilliamson/clreflect
I'm also not sure. Those seem to be on same market
between small enough for using text-based protocols
and big enough for using real binary formats (audio,
graphics, database etc.). Protobuf lacks reflection
and CMW lacks language neutrality.
(e-mail address removed) wrote:
Maybe you don't but others certainly do!
Ian Collins oratorically vehemently insists
Wow, -j 32 !! Say no more. Where did you find that 32 since at most I only
can find 16, as 2 threads per core. Actually thread core, not real core.
An i7 is still a 4 core, not sure how that threaded core is embedded into
the hardware.
I don't know. The way it's implemented often creates more
problems than it's worth.
Reference counted pointers seem irrelevant for a lot of
applications: some won't use any dynamic memory, except within
the standard containers, and many others will only use it for
entity objects, which have deterministic lifetimes for which
shared_ptr is totally irrelevant. And even in the few cases
where intensive use of reference counted pointers is relevant,
you probably want some sort of invasive counting, to avoid
errors. We experimented with `std::shared_ptr` when we moved to
C++11, but found that it didn't work for us, and went back to
our home written one.
James said:I don't know. The way it's implemented often creates more
problems than it's worth.
Reference counted pointers seem irrelevant for a lot of
applications: some won't use any dynamic memory, except within
the standard containers, and many others will only use it for
entity objects, which have deterministic lifetimes for which
shared_ptr is totally irrelevant. And even in the few cases
where intensive use of reference counted pointers is relevant,
you probably want some sort of invasive counting, to avoid
errors.
We experimented with `std::shared_ptr` when we moved to
C++11, but found that it didn't work for us, and went back to
our home written one.
Intrusive smartpointers have a convenient property that they can be created
from plain pointers (like 'this') or references.
Let's say you are changing
some function which currently has only a pointer or reference to the
object, and want to call some other function which expects a smartpointer,
or want to store a smartpointer for later use. With intrusive smartpointers
this is a no-braner, otherwise it becomes a PITA to pass smartpointers
through all those functions which actually do not need them.
Of course, this style works best if *all* objects of the given class can
be accessed via smartpointers (all objects are allocated only dynamically,
for example). This requirement may appear as a drawback in some cases.
The drawback is that sometimes you want a temporary object which could be
an automatic object on the stack, but you cannot have that (as the
constructor is protected, for good reasons). I understand this is only a
performance issue, but in the spirit it is against the zero overhead
principle of C++.
I don't know. The way it's implemented often creates more
problems than it's worth.
Reference counted pointers seem irrelevant for a lot of
applications: some won't use any dynamic memory, except within
the standard containers, and many others will only use it for
entity objects, which have deterministic lifetimes for which
shared_ptr is totally irrelevant.
Paavo Helde said:Intrusive smartpointers have a convenient property that they can be created
from plain pointers (like 'this') or references. Let's say you are changing
some function which currently has only a pointer or reference to the
object, and want to call some other function which expects a smartpointer,
or want to store a smartpointer for later use. With intrusive smartpointers
this is a no-braner, otherwise it becomes a PITA to pass smartpointers
through all those functions which actually do not need them.
I always wondered if it useful to have a "smart object" template like:
template <typename T>
class RC : public T
{
public:
/* add perfect forwarding constructors here */
void addRef();
void release();
private:
int count;
};
theoretically it combines the the advantages of internal and external
reference counts:
- you can use T on the stack and RC<T> as smart object, as with external
counts.
- performance of internal counts.
- safety/"ownership contract" of external count: you can only create smart
pointers from RC<T>* not from T*.
- You can pass by raw pointer/reference and create smart pointers on
demand, but still have the "ownership contract"
Any disadvantages?
Öö Tiib said:The 'boost::intrusive_ref_counter' is bit better since one can regulate
thread safety of access to that 'count'. Also CRTP makes it simpler,
no need for variadic template constructor for template (that makes
most readers head spin).
But boost::intrusive_ref_counter is basically just a helper class for
implementing a plain normal intrusive count.
It has none of the advantages of the above solution.
My RC template works with any existing class, and with appropriate
specialization also with primitive types. Just by using RC<SomeClass> or
RC<int>. No need to declare a wrapper. No need to decide at design time
whether a class should be "smart".
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.