please don't do it

[terrill]

becktho,

state machine or sequential code has nothing to do with object orientated programming. how can you tell what I am wiring together. It is about defing objects and creating methods with private and public functions and data memders, data encapulations. The benefits of oop are well documentated. This is off topic anyway.

Message Edited by terrill on 06-22-2006 10:26 AM

[shoneill]

"if we could there would be no war in IRAQ."

I think I'll openly and consciously side-step any additional comment on that as it is very easily construed in many different ways.......

Lets please not bring politics into the LV arena.  Please be aware we're a global community and local opinions may differ.

Shane.

[shoneill]

"we all have our own style of programming. we all program the way we feel comfortable doing so. I may link error clusters and you may use a SM. The point is it gets the job done and we feel good about the job that we did."

and

"If your comfortable always using SM's then hey go for it, if not then don't use."

This I openly and consciously agree with 😉

Well said.

Shane.

[terrill]

There are many ways to code anything but some are better then others. If there are no constraints like most coderes then any method is usable. if memory usage, cpu use and time is important then you will need to look at issues like this. I will say it depends on the gaols of the project.

Message Edited by terrill on 06-22-2006 10:34 AM

[becktho]

Firstly I fully agree with Jhoskins - everyone should do what he thinks is most useful.

Secondly - terrill, I can't tell what you are wiring together. You did not say you code really object oriented. You just wrote "I would separate the code into functional blocks and try to be as object oriented as possible", what made me assume you just wrote it and didn't know what it really is about. There are often enough newbies who think using LV you can code sequentially, in dataflow or object oriented.

I know well enough what OO is about.

[Joe_H]

Thanks shane, sorry for the statement about the war I do not want to offend anyone as it is my opinion. But the fact is we start wars and heated discussions just because we want to convince everyone that the way we do things is the only way to do it and that any other way will never be as good as the way that I do it. This is a global community and we are all going to have many different opinions about the way things should be done.

come on lets give it a rest.

[Ray.R]

Thanks shoneill for the examples.

This thread is indeed interesting, and yes, it answered a curiosity question.  It is obviously being used for Software Re-use and maintainability.  I need to read up more on the topic and who knows... probably join the new camp. 

My guess is that once you've adopted an approach, you use it (practically) everywhere, which may explain why it seems to be over-abused. 

As Titou mentionned, this is definitely an interesting thread..

JLV

[shoneill]

"if memory usage, cpu use and time is important then you will need to look at issues like this"

While this may be true for some extremely time-critical routines, the truth of the matter is that the algorithm used, or the implementation of the algorithm often makes far more difference than whether it's coded along scheme A or scheme B.  Avoiding data copying for example can make huge differences in execution speed and memory usage.  I'd rather spend my time optimising these aspects.

That's one point you also left out of your list (memory usage, cpu use and time) is the amount of bugs in the software.  I personally find SMs easier to debug.

It is however correct that maintainability and optimization are sometimes mutually exclusive, but I can't help but feel you're shifting the goalposts here.

This thread is getting off-topic a bit.  We're degrading to a "I'm more right than you" discussion.

Shane.

Edit: PS: Jhoskins,  No personal offence taken.  I've come to terms with the situation in Iraq long ago, but I just wanted to remind that it's still a very sore point for many.  I was also not clear in which direction the point was directed as it was very open to interpretation.  For me Interpretation + politics = time to go home for a beer. 😉

PPS: This is my last post in this thread.  I believe the questions have been answered.

Message Edited by shoneill on 06-22-2006 03:48 PM

Message Edited by shoneill on 06-22-2006 03:51 PM

[terrill]

I do not see the topic shift. I have the same point. Different styles should be used for different tasks. There is no one fix for everything code. The state machine is not some magic coding structure. That being said, if 2 sets of code accomplish the same task then they are not equal. There are ways to benchmark code. that beimg said everyone has different objectives for code.

[Ben]

I know I am coming in late here....

I agree with the original topic that being "do not use QSM's for everything."

I will use all of the above methods depending on the application.

These are some of the factors I take into concideration when deciding which method.

1) Complexity of function - If I can not quickly envision the code's structure (due to too many "If-Then-Else" conditions) I will use the State Diagram Editor (SDE) to get my thought straight. If when I am done I can see that the code can be structured using data flow and a few nested cases, then I MAY re-code if performance is an issue. Other-wise I will leave it as a SD because it alot easier to maintain code that is a SD because the SD gives me a"bird's eye view" of the code. See image.

2) "While" - I have come to believe that an application who's operational description use the word "while", a QSM MAY be an effective design pattern. Examples of "while" requirements could be "While the data is being collected and displayed, we also want to log."

THat is all I have time for at the moment.

Ben

PS: Did I mention that I love the SDE?

See "Ode to a State Diagram" found in the LabVIEW Champion's BLOG at this URL

http://forums.lavag.org/blog/champions/index.php?

Message Edited by Ben on 06-22-2006 09:04 AM