From: James Kanze on
Mirek Fidler wrote:
> James Kanze wrote:
> > Mirek Fidler wrote:
> > > > Which is where our experience differs. For me, most classes are
either
> > > > 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
the
> > > 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:james.kanze(a)gmail.com
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! ]

From: Mirek Fidler on

James Kanze wrote:

> You seem to have missed the point. Whether they're in a
> collection or not, they have to be managed. Either deep copied,
> at extra expense, or with some sort of reference counting, at
> extra complexity.

Well, that is true for entities that are to behave as values, mostly
for programmers convenience, e.g. string - but there the cost of deep
copy is in 90% cases is as cheap as passing the pointer, at least if
SSO is used.

Anyway, most objects do not have to be copied at all. It could be true
even for string, but again, value semantics is easier to use there.
(BTW, note that when RVO is available, string copy is quite seldom
operation, except maybe assigning constants and empty strings).

Mirek


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Seungbeom Kim on
Ivan Vecerina wrote:
> I admit that if( !!p ) took me minutes to parse, on first encounter.
> Yet once you think of !! as a "cast-to-bool" operator, it just
> feels very natural.
> And then you do away with the operator bool() vs operator void*()
> vs operator ObscureMemberFunctionPointer(), by having a single
> operator !() member to enter into the bool world.
>
> Weighing in readability, risk of error (=0 vs ==0), the 0 vs NULL
> debate, I have settled for the " strage cast-to-bool !! idiom ",
> and seen a number of other programmers happily convert to it.
>
> I do wish it were taught by some C++ authors...

If it works for you, that's fine; but the whole point of operator
overloading is to make the operations on UDTs mimic those of built-in
types, and I can hardly imagine anyone having written !! for built-in
types, so it doesn't feel very natural. Especially for novices. It would
be better if the language provided a more direct method. (It does; but
alas, that implicit conversion!! :( )

By the way, this thread has grown so haphazardly; almost every aspect of
C++ is being discussed under the title of "The D Programming Language".

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andrei Alexandrescu (See Website For Email) on
Niklas Matthies wrote:
> Well, it depends what one considers "basic". It's possible in Java to
> have the statement
>
> System.out.println("Hello, world!");
>
> output "Suprise!" (or any other arbitrary string), by appropriate
> preceding code.
>
> (This is because string literals within a class are guaranteed to be
> shared, so a different occurrence of "Hello, world!" in the source
> code can be used to manipulate the contents of that shared String
> object.)

I didn't know that! How is it possible? Got code? Heck, it's not
possible in many C and C++ implementations - they put constant strings
in read-only pages.

Andrei

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Niklas Matthies on
On 2006-12-13 23:48, Andrei Alexandrescu (See Website For Email) wrote:
> Niklas Matthies wrote:
>> Well, it depends what one considers "basic". It's possible in Java to
>> have the statement
>>
>> System.out.println("Hello, world!");
>>
>> output "Suprise!" (or any other arbitrary string), by appropriate
>> preceding code.
>>
>> (This is because string literals within a class are guaranteed to be
>> shared, so a different occurrence of "Hello, world!" in the source
>> code can be used to manipulate the contents of that shared String
>> object.)
>
> I didn't know that! How is it possible?

Because string objects initialized from string literals are just
regular instances of the java.lang.String class, which is implemented
in plain Java (with the exception of its intern() method).

> Got code?

Here you go:

class Test
{
public static void main(String[] args) throws Exception
{
java.util.HashSet set = new java.util.HashSet();
set.add("Hello, World!");

doEvil();

set.add("Hello, World!");
System.out.println(set); // prints "[Surprise!, Surprise!]"
}

static void doEvil() throws Exception
{
String s = "Surprise!";
String hw = "Hello, World!";
setField(hw, "value", s.toCharArray());
setField(hw, "count", Integer.valueOf(s.length()));
setField(hw, "hash", Integer.valueOf(0));
}

static void setField(Object object, String name, Object value)
throws Exception
{
java.lang.reflect.Field
field = object.getClass().getDeclaredField(name);
field.setAccessible(true);
field.set(object, value);
}
}

:)

-- Niklas Matthies

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]