Clever Code

You should definately use boost::weak_ptr for your neighbours. They are suited for what you are trying to do, because can only refer to another boost::shared_ptr or boost::weak_ptr good luck

You tried : if (!((*it)->isAlive())){ delete (*it); it = m_WorkerThreadList.erase(it); } Why not it.isAlive() & delete(it) ????? Just a newbie question.... Rex

Zac Howland wrote: and even some using Linux soapbox! :-D ~Nitron. ññòòïðïðB A start

I do this too (the m, l and p things). And even though camel case is widespread now, I find it too useful to drop it.

priceless....:cool: Charlie Gilley Will program for food... Whoever said children were cheaper by the dozen... lied. My son's PDA is an M249 SAW. My other son commutes in an M1A2 Abrams

Monkeyget2 wrote: A semicolon might eventually appears between the if and the count++ but that's not a problem since the language i usually use (c#) raise an error in that case : "Possible mistaken null statement". Now that I think about it, in c/c++ it might compile without any error reported. Well, in fact all newer C++ - compilers warn, and if you program in a way so as not to get overwhelmed by thousands of warnings, you could notice. I think there is also a way to bring the compiler to make an error out of aspecific warning. (With all warnings its easy, but a bit pointless). "We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.

My first rule of debugging: "If you get a different error message you're making progress." Good one. Sometimes I like this: My first rule of debugging: "If you get an access violation you're making progress." Any sufficiently gross incompetence is nearly indistinguishable from malice.

Ami Bar wrote: Note that in .NET you have the same issue, if you create a control in one thread, for example label on a form, the label can only be update on the same thread that it was created. AFAIK, this is a different issue - the subsystem isn't threadsafe, so you could run into problems trying to (say) change window text from two different threads at once. .NET 2.0 disallows it simply because of the problems it can cause...

I learned FORTRAN on a green monochrome VMS terminal... sounds like I'm old, but only 26 :/

I regularly use this tool for C#. http://www.codeproject.com/dotnet/expresso.asp[^] But since I converted the \\ syntax tp object I suffered from the problem. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan

Depends on the type of timer. A System.Windows.Forms.Timer is implemented with the SetTimer API, and therefore callbacks always occur on the UI thread (the one that created the form). A System.Threading.Timer is implemented using waitable timers and will fire events on any available thread pool thread. It does not make any attempt to synchronise with a currently-running callback - it will fire off another event (on another thread) even if a previous callback has not yet returned. A System.Timers.Timer wraps System.Threading.Timer and can be used to get back onto the appropriate thread for an object if you set the SynchronizingObject property. It derives from System.ComponentModel.Component so it can be dropped onto designer surfaces. Stability. What an interesting concept. -- Chris Maunder

Yup I was a beta tester for Microware. I found so many bugs that they pulled me from the project. But my partner continued and it turned into a great OS. I ran a company on OS9 for about a year and it worked very well. Scott

In C# you cannot do this mistake, since any expression evaluted in an if statement must be boolean. So if you write: if (count = 1) {...} The compiler will error. The only exception is when you write: if (flag = false) {...} or if (flag = true) {...} The compiler won't error for this, but from my point of view there is no reason to compare booleans with an equal sign. Just use if(!flag) or if(flag). Ami

Useful experience. Thanks.

Please forgive my ignorance but why does the destructor have to be Virtual? --- :beer: Hakuna-Matada :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: It’s rather simple to write an unmanaged C++ application that crashes when it performs a callback. It’s impossible to write a managed application that does the same, thanks to delegates. - Jeff Prosise

ITGFanatic wrote: By testing for when an unsigned variable becomes negative, it becomes stuck in an infinite loop. I don't see any other plausible reason for such a simple change to break code. Accessing memory beyond that which was allocated for the string.

No, I meant a bare = is not a part of the syntax; == is test for equality and := is assignment. I'll gladly type the extra character (two keystrokes) to save myself from unexpected functionality.

See here[^] for an example of how Microsoft already use the technique mentioned in my previous post. Steve

No bug here. It's a sequencing problem. When a form is constructed, its controls are constucted. When the form is finished being construced (implying the controls are constructed) the Load event is fired. The idea is that all the controls should exist before one loads data into them. So when TabControl1 is constructed and its Index property is initialised, obviously the TabIndexChaged event is fired. The form is still in the construction phase, so its Load event couldn't have fired. If one really needed the functionality implied by demonstrating this as a bug, one should use the form's Open event. out by one

Yeah, that's what I thought :) Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"