Re: The D Programming Language
Mirek Fidler wrote:
James Kanze wrote:
Mirek Fidler wrote:
Which is where our experience differs. For me, most classes are
on the stack, in a collection or embedded in another class. Only a
small number of classes require the use of smart pointers and in the
IME, no objects require the use of smart pointers (nor GC). Both GC
and/or smart_ptrs are bad idea. You can always find the scope where
object instance logically belongs.
Don't be silly. When the saleman creates an order, there's no
program scope at which it could possibly be placed.
Salesman? Well I am now not sure it above is meant as joke which I do
not understand or as real life example.
It's a real life example, and I don't see what there is not to
understand. The salesman contacts the customer, the customer
says he wants to purchase a certain number of shares, and the
salesman creates the order.
If second option is valid, writing C++ bussines logic apps is my main
job. In real world orders are placed in SQL, however the closest thing
in C++ to SQL database is global container.
In the real world, it's a bit more complicated, because creation
of the order must be notified to other people (traders who will
execute it, the middle office who will bill the client, etc.).
And of course, all this is spread out over many different
machines, in different cities. But you're right that for most
of its lifetime, the object is maintained in a global container.
It's lifetime doesn't correspond to that of the container (which
isn't its scope either); it's lifetime is determined by external
events; in our case, when the order has been filled and booked.
So... the order is created within a transaction, which manages
it until the commit, at which time it is inserted into the table
(and in case of rollback, is deleted... but logically, it could
be just forgotten---conceptually, the order is only a potential
object, or a value, until the commit). And it will be
explicitly deleted in the commit of another transaction.
There is absolutly no scope which corresponds to this lifetime.
And this corresponds to the case for almost all entity objects
in all of the applications I've worked on. The objects are
created in response to an external stimulus, and cease to exist
in response to another external stimulus, often handled in
another thread, and so certainly in a different scope. After
the commit of the transaction in which the object is created,
the object belongs to the container, and is explicitly managed.
Before that, it's just a potential object, more or less like a
value, and garbage collection could very well take care of it,
rather than using a complex mixture of smare pointers and the
transaction object. (The smart pointers are used to ensure
deletion between the moment the object has been created, and the
moment it is inserted into the transaction; the transaction is
responsible for it until the commit or rollback.)
And of course, if you're using optimistic locking, you also have
to manage the copies of the objects you're working on. Whose
lifetimes don't obey C++ scope either (but at least don't span
several different threads).
James Kanze (GABI Software) email:firstname.lastname@example.org
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]