The D Programming Language
in [C++]
|
From: Mirek Fidler on 12 Dec 2006 12:00 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. 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. Mirek -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mirek Fidler on 12 Dec 2006 12:01 James Kanze wrote: > PeteK wrote: > > James Kanze wrote: > > > PeteK wrote: > > > > My experience is that almost no classes have a logical owner. > > > Most classes which have a deterministic lifetime manage that > > > lifetime themselves. When I'm using garbage collection in C++, > > > I'd guess that about 90% of the deletes are "delete this". > > > Which is where our experience differs. For me, most classes are either > > on the stack, in a collection or embedded in another class. > > In terms of number of classes, you're probably right. In terms > of number of objects, however, it's less sure. Things like the > characters in a string, for example, can't be on the stack, > since they have variable size. Ah, but that is misunderstaning. Nobody speaks about implementation details here. If we are speaking about placing objects to stack, it does not mean that object itself cannot use the heap to implement its behaviour. Mirek -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Niklas Matthies on 12 Dec 2006 17:23 On 2006-12-08 00:53, Al wrote: > Niklas Matthies wrote: : >> It's not as private as one might assume; with default security >> settings you can access it via reflection. For example it's possible >> to corrupt a String object by replacing its char[] value. > > Sure, you can use reflection to do interesting things. But that's a > whole other can of worms. It isn't just restricted to private data. If > Java's reflection is anything like C# then it can be use to bypass a > whole lot of things that the "static" compiler wouldn't have allowed. > This is fine. No /basic/ language invariants have been violated. 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.) > In addition, I believe most of these things _are_ covered under the > security principals, so you could simply restrict code access if you > want to avoid them. > > One other thing, when you say it's possible to "corrupt" a String > object, what does that mean, exactly? It means that for example you can set the "offset" or "count" (=length) members of the String to values not covered by the backing char array, so that accesses to the String result in ArrayIndexOutOfBoundExceptions. Or you can set the "hash" member so that the same String can end up multiple times in the same HashSet. > Do you mean that it is somehow possible to corrupt the virtual > machine's memory integrity? No, but program and data integrity; which is what "truly" private data is about. I'm not saying that Java is bad for it. But I'd have some hesitation to claim that Java has "truly private data". -- Niklas Matthies -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 12 Dec 2006 17:48 Gerhard Menzl <clcppm-poster(a)this.is.invalid> writes: > David Abrahams wrote: > >> Gerhard Menzl <clcppm-poster(a)this.is.invalid> writes: >>> Your choice of terms was at least >>> misleading: someone unfamiliar with the C++ exception mechanism could >>> easily interpret it as describing a compile-time check, which is >>> precisely what C++ does not offer. To avoid this confusion, >>> especially when comparing C++ with Java, which does have static >>> checks, I think it is important to distinguish between "cannot throw" >>> and "will abort if it throws". >> >> What's the difference between a function that "will abort if it >> throws" and one that "might abort (for whatever reason)?" > > There is a difference between a compile-time guarantee and an abort at > runtime. That C++ does not offer the former may be obvious to you, which > is probably why you didn't find the statement misleading, but it could > easily lead less experienced readers of this group to believe there is > such a thing as compile-time exception specification checking. I don't > quite understand why you are so opposed to my attempt of clarification. I wouldn't say you attempted to clarify anything, and if you had put it as a clarification I probably wouldn't have objected. I was opposed to what seemed to be a flurry of attacks on Peter's original statement, which, taken in its context, was IMO understandable, correct, and insightful: [someone else] > Look instead at C++'s throw(). Seems completely bogus to me. Why? > Because in truth, it guarantees absolutely nothing, unlike Java. [Peter] Wrong again. C++ throw() guarantees that the function will not throw anything -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: PeteK on 12 Dec 2006 18:45
James Kanze wrote: > PeteK wrote: > > James Kanze wrote: > > > PeteK wrote: > > > > My experience is that almost no classes have a logical owner. > > > Most classes which have a deterministic lifetime manage that > > > lifetime themselves. When I'm using garbage collection in C++, > > > I'd guess that about 90% of the deletes are "delete this". > > > Which is where our experience differs. For me, most classes are either > > on the stack, in a collection or embedded in another class. > > In terms of number of classes, you're probably right. In terms > of number of objects, however, it's less sure. Things like the > characters in a string, for example, can't be on the stack, > since they have variable size. > No, but they *are* in a collection. A string is just an ordered collection of some character type. (and with small string optimisation they often *can* be on the stack). > > Only a small number of classes require the use of smart > > pointers and in the end even these are bound to the lifetime > > of a single class created to run the application. The word > > "delete" usually only turns up in comments. > > Or in a few special classes, such as smart pointers? > Nope. I use intrusive reference counting, so the only delete is in the root base class. I did a quick check of the number of deletes in a fairly large project that I've been working on. There were four deletes. Two were where someone appears to have pasted in some old code. One was in the ref counted base class. The other was in a buffer class that is used as the basis of our string class. Since the ref counting class and the buffer class both date from the early days of OS2 I think the it's not unreasonable to claim that I didn't write a single delete in the entire project (having found the other two I'll soon be removing them). [snip] > > In C++ something is logically dead when it's destructor is > > called. The fact that you've got live pointers to it doesn't > > mean it's alive, it means you've probably got an error in your > > program. > > By definition, at the language level. C++ requires us to create > a deterministic lifetime for all objects, even if the design > doesn't require it. That's what I'm arguing against. > But the logical lifetime of an object is not necessarily dependent on the language you use. For example, you talked about using dispose in Java. When you call dispose the object is logically dead, regardless of whether of not you have other references to the object. If you simply forgot to call dispose the object would still be logically dead at the point, you just wouldn't have formally killed it off. > > [...] > > > True, but in practice, you don't have to worry about objects > > > which aren't logically dead, but which are inaccessible, because > > > the program doesn't need them any more. > > > Unless these objects contain precious resources. > > Which in practice they don't (except memory). How can a value > contain a resource? > How can a value be an object? An object can have a value, but I don't see how a value can have an object. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |