From: James Kanze on 13 Dec 2006 11:52 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 13 Dec 2006 13:42 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 13 Dec 2006 14:24 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 13 Dec 2006 18:48 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 14 Dec 2006 07:54
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! ] |