On 13/03/2012 19:27, nemesis wrote:
> Invisible escreveu:
>> On 13/03/2012 10:11 AM, Invisible wrote:
>> I eventually gave up with NetBeans. It's just too cripplingly slow. (I
>> did not have this problem with VS.) If I type something and have to
>> wait /4 seconds/ for anything to appear on the screen, that's too
>> slow, IMHO.
>
> ah, children from the 90's...

I wish. :-P

Seriously. Visual Studio manages to be responsive enough, and not eat 
half my RAM. NetBeans can't. IMHO, that makes NetBeans inferior.

>> Seriously. Once I got to a handful of files, amounting to a grand
>> total of 6KB of Java source, performance became unacceptably poor.
>
> That's not my (ackowledged little) experience. And surely not of most
> people working on some hairy shared projects.

I can only say what I saw, not what other people see.

>> In all, I was spending /far/ too much time fighting the IDE and not
>> enough time actually coding stuff.
>
> cool, now you'll be just fighting a wholesomely stupid language.

That's the one. ;-)

>> Some of you may remember that logic simulator I built in Haskell a
>> while back. If I recall, I challenged Warp to implement it in C++, and
>> he couldn't even figure out how the heck it works.
>
> Perhaps you should have told him what the code is supposed to do rather
> than expect someone to figure out what some haskell code is doing.

Well, I did try to explain it in words, but sometimes source code is 
more exact.

> Here's a challenge for you. What do these haskell snippets are supposed
> to do?
>
> snippet 1:
>
> ((.)$(.))

ASCII art? ;-)

In fact, the "$" is necessary. Either way, this takes a 3-argument 
function, the first argument to the function, a function that transforms 
some type into the type of the second argument, and a suitable argument 
to transform. Or, in symbols,

(x -> y -> z) -> x -> (j -> y) -> y -> z

> snippet 2:
>
> f >>= a . b . c =<< g

Without knowing what the variables are bound to, this cannot be 
answered. It would be like saying "what does Foo(Bar(5)) do?"

> and for a bonus, guess what this one does:
>
> import System.Environment
>
> foo n = 0 % (0 # (1,0,1)) where
> i%ds
> | i >= n = []
> | True = (concat h ++ "\t:" ++ show j ++ "\n") ++ j%t
> where k = i+10; j = min n k
> (h,t) | k > n = (take (n`mod`10) ds ++ replicate (k-n) " ",[])
> | True = splitAt 10 ds
> j # s | n>a || r+n>=d = k # t
> | True = show q : k # (n*10,(a-(q*d))*10,d)
> where k = j+1; t@(n,a,d)=k&s; (q,r)=(n*3+a)`divMod`d
> j&(n,a,d) = (n*j,(a+n*2)*y,d*y) where y=(j*2+1)
>
> main = putStr.foo.read.head =<< getArgs

That's not even parsable. (Indentation is significant, remember?)

> no googling, huh? ;)

All I need is Hoogle. :-P

>> Yes, Java /still/ sucks. :-P
>
> Yes and that is a feature by design.

O RLY?

> What doesn't suck is the JVM and the tens of thousands of useful libs
> that run atop it. It's the only truly cross-platform performant VM out
> there. Think about it, libs you don't actually need to recompile on your
> machine.

Ha! If only... They don't say "write once, test everywhere" for nothing. ;-)

> And if you don't like java, you can just choose from many languages
> running atop it and leveraging from said libs: Scala, Jython, JRuby,
> even quite a few Scheme implementations... any haskell work on this front?

Darren claims they committed to a feature freeze too soon. I don't know 
about the low-level details of the JVM. But I gather that, say, adding 
Java generics required lots of ugly hacks so it didn't break compatibility.

I hear there are other languages that target the JVM. Presumably you 
still can't use any of the existing libraries though. (Not that any of 
them are much good.)

Oh, Haskell? Yeah, I gather a few people have tried to target the JVM 
with it. Nothing production-grade currently exists, however.

> BTW, Ant is yet another example of XML-madness: it's basically a verbose
> XML makefile for java.

Oh well. At least you don't need tab characters. :-P

Post a reply to this message

>> The most obvious way to implement this is to physically build a binary
>> tree. That requires either inheritance, or else doing something sly with
>> unions. (Or even being /really/ dirty and just having one node type, and
>> ignoring the unused fields.)
>
>    I don't see why you need different types of objects for such a binary
> tree. Each object can be identical to each other in structure. (If in
> some nodes some of the fields are unused, so what? It will still be
> significantly more efficient than dynamic binding.)

So 16 bytes of space overhead per node is worth it if you can avoid one 
indirect jump instruction? That seems like an odd trade-off from an 
efficiency point of view. (Program complexity is another matter...)

>    You don't need to mess with unions unless you really, really need to
> make the objects as small as physically possible.

Granted. That's why I wasn't going to try to do that.

>> Now for the /encoding/ part itself, I don't actually need a physical
>> tree. I have a vague recollection that last time I did this, I ended up
>> cheating and just storing a vector of codewords, and manually munging
>> that. It's a lot less elegant, but avoids dynamic allocation. (Or
>> rather, no it doesn't, but it hides it in STL containers, so you don't
>> have to do it manually.)
>
>    Using an array of objects (rather than individually allocated objects)
> doesn't completely avoid memory allocation, but it minimizes their amount,
> which is often very significant. (In other words, if your program makes
> 20 allocations instead of a million, it will have a significant impact
> on the speed of the program.)

Mmm, I hadn't even thought of using an /array/. I suppose the upper 
bound on the tree size is statically known, so why not?

>    If you really must have nodes of differing types, then it will become
> complicated from the point of view of memory management. Lack of garbage
> collection can be a b**** sometimes.

Ah well, that's why all large-scale applications are developed in C++, 
right? Because it doesn't force you to have garbage collection.

>    It's sometimes quite a bummer, but when writing efficient C++ you have
> to always think "how many memory allocations will this perform?"

Right. So what you're saying is that it's not dynamic binding /itself/ 
which is slow, but rather the dynamic allocations which necessarily go 
with it. (?)

>    Avoiding dynamic binding does not automatically mean that your program
> becomes more complicated and harder to maintain. In fact, it can sometimes
> mean the opposite. Sometimes your programs actually become *simpler* and
> much easier to understand. Full OOP (beyond simple encapsulation using
> classes) is not always the universal panacea for clarity and maintainability.
> (Of course this depends on each individual case.)

I usually find the OOP approach to be a good one. (Not always, of 
course.) Whether that's the type of code I write or what, I don't know.

Out of curiosity, if /you/ were writing a piece of code that's supposed 
to take a text string, parse it as an expression, and then execute the 
resulting expression, how would you implement that? The most obvious way 
is to make every valid kind of expression be a different class, and have 
an abstract base class with an "execute this" method, which gets 
implemented differently for each type of expression. But this 
necessarily involves dynamic binding and dynamic allocation, which you 
seem to make out is the Ultimate Evil to be avoided at all costs. So how 
would you do it?

(The obvious alternative is to design a single type that contains every 
field that any expression type will ever need, and write a giant switch 
statement to analyse each node to figure out how to execute it - which 
is exactly what OOP was designed to get rid of.)

>    But even then you have to think which design is easiest in terms of
> memory management. The less you have to manage memory manually, the
> better. Your program becomes safer and simpler.

Not manually managing memory certainly /is/ simpler than manually 
managing memory. No arguments there! ;-)

>> The problem is, I want to copy some data, but since I don't know what
>> class it belongs to, I have no idea how big it will be.
>
>    I didn't understand your problem from that description alone.

OK, well, if there is a single TreeNode class, I could write something like

   TreeNode(TreeNode t0, TreeNode t1)
   {
     child0 = new TreeNode;
     child1 = new TreeNode;
     *child0 = t0;
     *child1 = t1;
   }

If, however, the TreeNode class is abstract, obviously this won't work 
at all. I now need to know what the /actual/ type of t0 is before I can 
allocate sufficient space for it. (I'm also fuzzy on what happens when 
you try to delete a pointer - does it know what the "real" size of the 
object is, or does it use the declared type of the pointer?)

>>>     Now, writing a class that properly manages its dynamically allocated
>>> memory is a non-trivial task of its own.
>
>> Is that not just a case of allocating the memory correctly in the
>> constructor, and freeing it properly in the destructor? (I mean,
>> assuming nobody tries to copy the object or free its dynamic memory or
>> anything like that...)
>
>    The simplest design is to delete the allocated memory in the destructor
> (it doesn't really matter where inside the class the memory is allocated
> as long as the pointer is kept as 0 when there's nothing allocated) and
> then disabling the copy constructor and assignment operators. (In C++98
> this is done by declaring them private and not implementing them. In C++11
> you can explicitly express this with a keyword.)
>
>    Often this is enough. However, sometimes you would want to be able
> to copy and assign objects of that class type around. That's where the
> non-triviality kicks in.

Right. Yeah, I can see how that might get confusing - especially if 
you're trying to minimise actual data copying...

Post a reply to this message

On 13/03/2012 17:31, Warp wrote:
> Warp<war### [at] tagpovrayorg>  wrote:
>>    The first problem is: How should the object be copied? There are many
>> possibilities:
>
>    If you are wondering which solution the STL data containers use,
> it's usually just a simple deep-copy whenever the container is copied
> or assigned.

Just to be picky: I'm presuming that it's a "deep" copy as far as 
copying the container itself. Presumably what happens to the elements 
depends on what their copy constructor implements. (?)

Post a reply to this message

Orchid Win7 v1 escreveu:
> On 13/03/2012 19:27, nemesis wrote:
>> ah, children from the 90's...
> 
> I wish. :-P

ok, old fart.

> Seriously. Visual Studio manages to be responsive enough, and not eat 
> half my RAM. NetBeans can't. IMHO, that makes NetBeans inferior.

Windows comes with the .NET libraries used by VS.  It's also a native 
program, rather than one running on a VM.

>> Here's a challenge for you. What do these haskell snippets are supposed
>> to do?
>>
>> snippet 1:
>>
>> ((.)$(.))
> 
> ASCII art? ;-)

actually, I thought it was some perl idiom. :)

if it was a bit more concise, it'd give you a nice pair of boobies:
(.)(.)

> In fact, the "$" is necessary. Either way, this takes a 3-argument 
> function, the first argument to the function, a function that transforms 
> some type into the type of the second argument, and a suitable argument 
> to transform. Or, in symbols,
> 
> (x -> y -> z) -> x -> (j -> y) -> y -> z

haha, you already new that from the haskellwiki. :p

>> snippet 2:
>>
>> f >>= a . b . c =<< g
> 
> Without knowing what the variables are bound to, this cannot be 
> answered. It would be like saying "what does Foo(Bar(5)) do?"

ok, both come from here:

http://www.haskell.org/haskellwiki/Pointfree#The_owl
http://www.haskell.org/haskellwiki/Pointfree#Squish

>> and for a bonus, guess what this one does:
>>
>> import System.Environment
>>
>> foo n = 0 % (0 # (1,0,1)) where
>> i%ds
>> | i >= n = []
>> | True = (concat h ++ "\t:" ++ show j ++ "\n") ++ j%t
>> where k = i+10; j = min n k
>> (h,t) | k > n = (take (n`mod`10) ds ++ replicate (k-n) " ",[])
>> | True = splitAt 10 ds
>> j # s | n>a || r+n>=d = k # t
>> | True = show q : k # (n*10,(a-(q*d))*10,d)
>> where k = j+1; t@(n,a,d)=k&s; (q,r)=(n*3+a)`divMod`d
>> j&(n,a,d) = (n*j,(a+n*2)*y,d*y) where y=(j*2+1)
>>
>> main = putStr.foo.read.head =<< getArgs
> 
> That's not even parsable. (Indentation is significant, remember?)

ah, seems indentation is lost (too bad for haskell).  But nice style on 
giving up.

>>> Yes, Java /still/ sucks. :-P
>>
>> Yes and that is a feature by design.
> 
> O RLY?

Yes, so that your hired slaves can't cut the pulses and get free.

>> What doesn't suck is the JVM and the tens of thousands of useful libs
>> that run atop it. It's the only truly cross-platform performant VM out
>> there. Think about it, libs you don't actually need to recompile on your
>> machine.
> 
> Ha! If only... They don't say "write once, test everywhere" for nothing. 
> ;-)

seems like most of the thousands of open-source java libs are well 
tested already.

> I hear there are other languages that target the JVM. Presumably you 
> still can't use any of the existing libraries though. (Not that any of 
> them are much good.)

yes, you are likely to use java libs.

> Oh, Haskell? Yeah, I gather a few people have tried to target the JVM 
> with it. Nothing production-grade currently exists, however.
> 
>> BTW, Ant is yet another example of XML-madness: it's basically a verbose
>> XML makefile for java.
> 
> Oh well. At least you don't need tab characters. :-P

says the haskell programmer... :p

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

>>> ah, children from the 90's...
>>
>> I wish. :-P
>
> ok, old fart.

Thanks for making me feel better. :-P

>> Seriously. Visual Studio manages to be responsive enough, and not eat
>> half my RAM. NetBeans can't. IMHO, that makes NetBeans inferior.
>
> Windows comes with the .NET libraries used by VS. It's also a native
> program, rather than one running on a VM.

You know, people say "oh, Java isn't slow". And then this happens...

Also, about this "Windows comes with the .NET libraries". If that's so, 
then why did I have to wait 20 minutes for it to download .NET when I 
installed it?

>>> snippet 1:
>>>
>>> ((.)$(.))
>>
>> ASCII art? ;-)
>
> actually, I thought it was some perl idiom. :)

The question is, who the heck writes code like that anyway? (Except to 
show off.)

> if it was a bit more concise, it'd give you a nice pair of boobies:

Hey, that's what it looked like in the first place. But rich boobies. ;-)

>> In fact, the "$" is necessary. Either way, this takes a 3-argument
>> function, the first argument to the function, a function that
>> transforms some type into the type of the second argument, and a
>> suitable argument to transform. Or, in symbols,
>>
>> (x -> y -> z) -> x -> (j -> y) -> y -> z
>
> haha, you already new that from the haskellwiki. :p

Erm, no... It's a simple question of type inference. I mean, c'mon, it's 
not exactly a complicated code fragment. It's two function calls.

>> That's not even parsable. (Indentation is significant, remember?)
>
> ah, seems indentation is lost (too bad for haskell). But nice style on
> giving up.

Well, yeah, because even if I could understand it, that wouldn't prove 
anything to anyone.

>>>> Yes, Java /still/ sucks. :-P
>>>
>>> Yes and that is a feature by design.
>>
>> O RLY?
>
> Yes, so that your hired slaves can't cut the pulses and get free.

Wuh?

>> Ha! If only... They don't say "write once, test everywhere" for
>> nothing. ;-)
>
> seems like most of the thousands of open-source java libs are well
> tested already.

Wait - there are open-source Java libs now?

(Last time I looked at Java, all anyone ever used it for was pointless 
Tic-Tac-Toe applets. Nobody ever wrote actual large applications with 
it, just small toy examples.)

>>> BTW, Ant is yet another example of XML-madness: it's basically a verbose
>>> XML makefile for java.
>>
>> Oh well. At least you don't need tab characters. :-P
>
> says the haskell programmer... :p

What? Tab characters are explicitly disallowed in Haskell. :-P

Post a reply to this message

Orchid Win7 v1 escreveu:
>>>> ah, children from the 90's...
>>>
>>> I wish. :-P
>>
>> ok, old fart.
> 
> Thanks for making me feel better. :-P

I'm even older than you (not by much actually) but have a far better 
sense of humor.  Better now? :)

>>> Seriously. Visual Studio manages to be responsive enough, and not eat
>>> half my RAM. NetBeans can't. IMHO, that makes NetBeans inferior.
>>
>> Windows comes with the .NET libraries used by VS. It's also a native
>> program, rather than one running on a VM.
> 
> You know, people say "oh, Java isn't slow". And then this happens...

It's one of the fastest languages on the shootout game.

> Also, about this "Windows comes with the .NET libraries". If that's so, 
> then why did I have to wait 20 minutes for it to download .NET when I 
> installed it?

older Windows?  anyway, .NET does not count when looking at the memory 
statistcs of a program that uses it.  It's "part" of Windows.  That's 
why you look at VS and it looks fine.  That's why you look at Firefox or 
Netbeans or some other foreign app and it looks like it's sucking all 
your memory:  their particular libs are alien to Windows and thus are 
taken into account when showing statistcs.  Not so with microsoft libs, 
so VS and IE look pretty lightweight.

they play dirty.

>>> (x -> y -> z) -> x -> (j -> y) -> y -> z
>>
>> haha, you already new that from the haskellwiki. :p
> 
> Erm, no... It's a simple question of type inference.

I prefer to leave that to the compiler or interpreter.  Better yet, I 
prefer not to think of types. :)

> I mean, c'mon, it's 
> not exactly a complicated code fragment. It's two function calls.

two function calls that take other functions and return other functions 
and ... well, you get the idea.

>>> That's not even parsable. (Indentation is significant, remember?)
>>
>> ah, seems indentation is lost (too bad for haskell). But nice style on
>> giving up.
> 
> Well, yeah, because even if I could understand it, that wouldn't prove 
> anything to anyone.

BTW, I looked up my post and indentation was fine.  But anyway, it's the 
pidigits haskell program at the shootout:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=pidigits&lang=ghc

>>>>> Yes, Java /still/ sucks. :-P
>>>>
>>>> Yes and that is a feature by design.
>>>
>>> O RLY?
>>
>> Yes, so that your hired slaves can't cut the pulses and get free.
> 
> Wuh?

well, they do try to cut their pulses, but the language doesn't afford 
that.  Nor shooting on the foot.

>>> Ha! If only... They don't say "write once, test everywhere" for
>>> nothing. ;-)
>>
>> seems like most of the thousands of open-source java libs are well
>> tested already.
> 
> Wait - there are open-source Java libs now?
> 
> (Last time I looked at Java, all anyone ever used it for was pointless 
> Tic-Tac-Toe applets. Nobody ever wrote actual large applications with 
> it, just small toy examples.)

Earth to Andrew, Earth to Andrew!  An import message has been delivered: 
  this is not 1964 anymore.

Hint:  Apache once was a (patchy) http server.  Now it's one huge java shop.

After Microsoft shoved Java away from the desktop, it hid on the server 
(where it shoved Perl away).

>>>> BTW, Ant is yet another example of XML-madness: it's basically a 
>>>> verbose
>>>> XML makefile for java.
>>>
>>> Oh well. At least you don't need tab characters. :-P
>>
>> says the haskell programmer... :p
> 
> What? Tab characters are explicitly disallowed in Haskell. :-P

except where needed.

I prefer proper free-form parentheses. :)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Am 13.03.2012 11:11, schrieb Invisible:

> The real sticking point was when I started trying to use abstract
> classes. It seems that you cannot have a variable of an abstract class.
> (Because creating that variable would require creating an instance of an
> abstract class, which is illegal.) You can only have a variable that
> /points to/ such a value. (Because then what it points to can actually
> be some concrete subclass.)
>
> That's all fine and logical and everything, but there's a nasty snag:
> Now you have to care about memory management. And there's no way around it.

Forget all you know about classic C pointers; instead, try the C++11 
(aka C++0x) shared pointers - they'll take care of all the disposing 
stuff. (If C++0x is not an option, use the boost library; C++0x took 
them right from there).

Instead of e.g.

     MyVirtualClass* o1 = new MySubClass(...);
     MyVirtualClass* o2 = o1;
     o1->doThis();
     o2->doThat();
     dispose o2; o1 = null; o2 = null;

you'd write

     shared_ptr<MyVirtualClass> o1(new MySubClass(...));
     shared_ptr<MyVirtualClass> o2(o1);
     o1->doThis();
     o2->doThat();
     o1 = null;
     o2 = null;

Note that the dispose is gone for good. Shared pointers use reference 
counters to accomplish this feat.

To save you some typing, you may want to use

     typedef shared_ptr<MyVirtualClass> MyVirtualClassPtr;

(Caveat: Assignments of shared pointers are a little tricky, as the 
assignment operator "o1 = o2;" is actually implemented as a swap 
operation; you'll need to use "o1 = shared_ptr<MyVirtualClass>(o2);" 
instead to clone a pointer.)

There is also a complementary weak_ptr, which allows the referenced 
object to be destroyed. To try to access the object, get a shared_ptr 
from the weak_ptr, verify that the shared_ptr is non-null and access the 
object.

> Like VS, asking NetBeans for a basic project generates a plateful of
> useless code that you then have to waste time deleting. (Apparently
> there's an Ant script somewhere too... whatever the hell that is.) It
> also sets the tab depth far, far too deep. But unlike VS, it also seems
> to /insist/ on incorrectly putting the open bracket on the same line as
> the declaration it begins. (This incorrect practise is also common in
> C++, and yet I didn't seem to have this problem with VS.) It's easy
> enough to manually fix, I suppose.

There's nothing "incorrect" about that way of placing braces, even in 
C++. It's syntactically correct, so say what you will.

As for Java, it's actually /the/ official curly braces convention, as 
recommended by Sun and later Oracle.

> So there we are. I doubt I'd remember much about the AWT (although,
> didn't they deprecate that in favour of Swing?),

The JAVA API has a rich history of deprecating interfaces, deprecating 
interfaces designed to replace deprecated interfaces, and un-deprecating 
deprecated interfaces. I wouldn't be surprised if AWT was among the latter.

> but I can certainly
> still write algorithmic code in Java without much ado. Maybe today I'll
> try something more ambitious with it. If I can avoid throwing the IDE
> out of a window.

Try Eclipse. Somehow it seems to be the unofficial standard IDE. (Never 
tried it myself in depth though; it has that very special 
Open-Software-Project air about it that somehow makes my skin crawl ever 
since I tried OpenOffice for real.)

> (Is it just me? "Net Beans"? It's an IDE. What the /hell/ does that have
> to do with networking? The "beans" part I kinda get; everything
> Java-related has to be themed on coffee or coffee beans. But why "net"?)

Maybe because "The NetBeans project consists of an open-source IDE and 
an application platform that enable developers to rapidly create web, 
enterprise, desktop, and mobile applications using the Java platform [...]"?


Anyway, I personally stick to IDEs developed by software development 
companies (and I mean companies that develop other stuff besides 
programming languages and IDEs). So far the best IDE experience has been 
Visual Studio for C#. One might snarl at the company's marketing 
strategies, but they seem to know what helps software developers to be 
productive.

Post a reply to this message

Am 13.03.2012 20:40, schrieb Orchid Win7 v1:

>> import System.Environment
>>
>> foo n = 0 % (0 # (1,0,1)) where
>> i%ds
>> | i >= n = []
>> | True = (concat h ++ "\t:" ++ show j ++ "\n") ++ j%t
>> where k = i+10; j = min n k
>> (h,t) | k > n = (take (n`mod`10) ds ++ replicate (k-n) " ",[])
>> | True = splitAt 10 ds
>> j # s | n>a || r+n>=d = k # t
>> | True = show q : k # (n*10,(a-(q*d))*10,d)
>> where k = j+1; t@(n,a,d)=k&s; (q,r)=(n*3+a)`divMod`d
>> j&(n,a,d) = (n*j,(a+n*2)*y,d*y) where y=(j*2+1)
>>
>> main = putStr.foo.read.head =<< getArgs
>
> That's not even parsable. (Indentation is significant, remember?)

Yuck - I hate it when languages do that.

> Darren claims they committed to a feature freeze too soon. I don't know
> about the low-level details of the JVM. But I gather that, say, adding
> Java generics required lots of ugly hacks so it didn't break compatibility.

Guess how many ugly hacks C++ relies on to not break compatibility with 
classic library formats...

> I hear there are other languages that target the JVM. Presumably you
> still can't use any of the existing libraries though. (Not that any of
> them are much good.)

The fun is that you can. The bane is that you might have to.

> Oh, Haskell? Yeah, I gather a few people have tried to target the JVM
> with it. Nothing production-grade currently exists, however.

Is there any such thing as a production-grade Haskell implementation?

Post a reply to this message

Am 13.03.2012 21:37, schrieb Orchid Win7 v1:

> Wait - there are open-source Java libs now?
>
> (Last time I looked at Java, all anyone ever used it for was pointless
> Tic-Tac-Toe applets. Nobody ever wrote actual large applications with
> it, just small toy examples.)

You've never heard of Java enterprise application servers, have you?

Post a reply to this message

Am 13.03.2012 20:41, schrieb Orchid Win7 v1:

> (I'm also fuzzy on what happens when
> you try to delete a pointer - does it know what the "real" size of the
> object is, or does it use the declared type of the pointer?)

Just like free() in C, the delete operator in C++ frees whatever memory 
was originally allocated to the object, so you don't need to worry about 
/that/.

What you /should/ worry about, however, is which destructor will be 
called: Make sure to equip all of your virtual classes with a virtual 
destructor, otherwise the C++ standard guarantees for nothing.

(For non-virtual classes it is good practice to define a protected 
non-virtual destructor instead, just to be sure.)

Post a reply to this message