Wus

You insult someone without offering any aid whatsoever thus showing that your motives are not in fact benevolent, which I find pathetic since it means that you probably just threw the insult in there for an ego-trip. Meh, maybe I am reading it all wrong -- I just felt that giving a little information would be more helpful than belittling someone. Consider this my EOF marker for this thread.

@Zisly You ought to check out VirtualBox as it would allow you to run the executable in a safe environment. A bit of work to set up, but I bet you would find it endlessly useful. @trancexx Calling someone pathetic in such a cavalier manner is well (I hate to be cliche) but pathetic.

Yeah, I got that too -- I mean, Kalev doesn't even seem to be trying to hide it. Kalev's bio states that he was on the C++ standards committee in the past and to me it sounds like he has a bone to pick with them. I really did appreciate Stroustrup's blunt way of dealing with it:

Good luck with your learning of C++. EDIT: I decided that I need to be less of a jackass.

To start I'd like to say that this thread is a good read -- it is exposing me to a few new things which is always good. Having said that, my problem with the current discussion is that it seems like the original poster's post has not really been properly addressed. He started with and then went on to ask about how to squeeze an extra few percentage points of efficiency out of c++ code. Perhaps I am reading this wrong, but my response is to say 'WTF!' There is absolutely no reason for him to be worried about the number of clock cycles it takes to de-reference a pointer. IMO entertaining this question in this manner is quite counterproductive for the OP. To finish... @athiwatc The fact that you asked this question shows that you are thinking which is fantastic. Unfortunately you are thinking too far ahead at the moment -- you are running before you can walk. Stop trying to optimize code and just try to learn the language. I'd suggest that you read this thread as no more than an abstract aside.

My use of the phrase 'source code bloat' references the number of lines in the source code, *not* the compiled size; I apologize if this is a non-standard use of the phrase. You are absolutely correct in that a few extra kilobytes of code isn't an issue. What *is* a problem is trying to debug, update, and manage an extra few hundred lines of code. At this juncture I will stop posting in this thread. The important points have been made and at this point I feel that I am beating a dead horse. We clearly and irrevocably disagree. End of story. Cheers.

First, the more interesting statistic (in my opinion) is the reciprocal of the time, which is directly proportional with the speed. This can then be used to find a good metric of your % increase in speed. Test1: _FileListToArray: Sec = 7.70 , 1832 items, 0.130 1/s _FileListToArrayXT: Sec = 4.62 , 1832 items, 0.216 1/s * XT version is 66.2% faster Test2: _FileListToArray: Sec = 12.80 , 3114 items, 0.0781 1/s _FileListToArrayXT: Sec = 7.31 , 3114 items, 0.137 1/s * XT version is 75.1% faster Thus you have made the function 60-80% faster. My question to you is, under what circumstances is a 80% increase in speed acceptable when a ~300% increase has been made to the source code? There are definitely situations where this would be warranted, but what is it about this situation that makes it worthwhile. I will admit that a significant amount of that bloat is probably from the added features, but still even an increase in source code commensurate with the increase in speed seems like a very poor choice in most cases. I would say that the increase in function speed should be orders of magnitude larger than the source code bloat in order to make it worthwhile in most cases.

You are absolutely correct on all points. I was not deriding the usefulness of the function, just trying to correct the misinformation given. Heh, I'd prefer to not be 20k in the hole right now, but that doesn't change the fact that I am. Without explicitly specifying that you wish the result to be real, the imaginary roots are just as valid. Incorrect assumptions on your part are just that, incorrect. It seems like you have remedied this however, via changing the functions name. Awesome. It's great to see you are willing to learn. Not-so-awesome. Imaginary numbers shouldn't be viewed as a pain, they were created because they were necessary for the development of mathematics, which in turn was necessary for the development of civilization. You may not know it, but almost all of electronics (read computers) is based on mathematics involving complex numbers and complex valued functions. Thus you probably wouldn't have a computer in front of you right now without the imaginary number i. _Root($fNum, $nBase = 3) I suggest you change the $nBase parameter to something else... say $nOrder. To me $nBase implies the base for a numbering system, which is decidedly not what you mean. EDIT: Typo.

Actually, you are wrong, not MS Powertoy calc. If your range is allowed to be the complex numbers then 1.5+2.5980762113533159402911695122588i is a solution. In general there will be n (not necessarily distinct) roots to an nth order equation. In this case the polynomial equation you are trying to solve is x^3 -27 = 0, which is cubic (or order 3) and thus has 3 roots. The three cubic roots of 27 are: -3 -1.5 + 2.598076211353i -1.5 - 2.598076211353i What you probably wanted was the real solution, but that isn't always what you get, especially when you use a calculator that doesn't have a strong symbolic solver. What the MS Powertoy calc almost certainly does to find roots is to use Newtons Method, which as far as I know has no preference between real or imaginary roots, though I am not completely certain of that.

If that algorithm is new to you then I highly suggest that you read up on graph-searching and tree-traversal algorithms as they come in handy all the time. If you view the directories as nodes and the files as leaves then the following are all very applicable (and should be in every programmers toolbox anyway): http://en.wikipedia.org/wiki/Depth-first_search http://en.wikipedia.org/wiki/Breadth-first_search http://en.wikipedia.org/wiki/Tree_traversal

I'm not entirely sure what the means, but I can assure you I just wrote that function 100% from scratch without ever having seen your code or amel27's code in my life. If they look very similar (which I agree they do) it is because they both use the same extremely well-known algorithm, and we both used common sense. I'm sorry if I sound a bit touchy on the subject, but I am going to grad school for what I hope to be a life long career of research and my intellectual integrity is not something I take lightly. If you want further proof, then I can send you a few dozen java projects I have which use the same basic code template in a variety of circumstances, thus showing that the code is by no means unique in its nature.

Just to elaborate on what I was saying earlier about not needing to do actual recursion, I wrote the following code. #include <Array.au3> Dim $results = _FLTA_NonRecursiveRecursion("C:\Program Files\AutoIt3\", True) _ArrayDisplay($results) Func _FLTA_NonRecursiveRecursion($sPath, $bRecursive) ; Make a stack Local $iStackCapacity = 64 Local $iStackSize = 0 Local $aFolderStack[$iStackCapacity] ; Ready the return variable Local $sRet = "" ; Seed the stack with the start directory $aFolderStack[0] = $sPath $iStackSize += 1 ; Loop while there is a directory left to be explored While $iStackSize > 0 ; Change to the new directory you want to explore FileChangeDir($aFolderStack[$iStackSize-1]) $iStackSize -= 1 ; Initiate directory listing Local $search = FileFindFirstFile("*") Local $file = "" ; Loops until current directory is completely explored While 1 ; Grab the next item in the directory $file = FileFindNextFile($search) ; Kick out if listing is exhausted If @error Then ExitLoop ; Decide if item is File or Folder If StringInStr(FileGetAttrib($file), "D") Then ; It is a folder. Add to queue if listing is recursive. If $bRecursive Then ; Redim stack if needed. If $iStackCapacity <= $iStackSize Then $iStackCapacity *= 2 ReDim $aFolderStack[$iStackCapacity] EndIf ; Add folder to stack $aFolderStack[$iStackSize] = @WorkingDir & "\" & $file $iStackSize += 1 EndIf Else ; It is a file. Add to listing. $sRet &= "|" & @WorkingDir & "\" & $file EndIf WEnd WEnd ; Return an array version of the total listing Return StringSplit($sRet, "|") EndFunc ;==>_FLTA_NonRecursiveRecursion It lists every file in a directory recursively (or not depending on the boolean flag) without any actual recursion. It is only supposed to be a proof of concept, and is not intended to be anything more. I obviously didn't try to do any error checking or include all those fancy schmancy speedups or add all the functionality. I used a stack, so it is just a depth-first search. It ought to work with or without the beta. EDIT: Typo.

By the way, I really don't like the fact that you have an argument that is not supposed to be changed. $sWorkPath = *** internal use only (do not use) *** Could you not implement this method without the recursion? Say with a stack or a queue? I am guessing a DFS, i.e. queue, would work pretty well.

It might be the case that I spoke a bit hastily in regards to this function, and I shall educate myself a bit more before posting anything more on it. Having said that, my comments on what I called 'a need for speed' I resolutely stand behind.

I can only speak for myself and from my personal experience of managing a moderately sized project for ~6 months (I only mention this so you won't dismiss my opinion as uninformed), but if if one of the guys I'd worked with had said that, well, I would have slapped them with a large trout. There is always one more tweak that can make your code faster -- almost always at the expense of clarity and brevity -- and the question is 'Where do I draw the line?', which is only gained through experience. Start doing some real debugging and I believe you will quickly appreciate my sentiments.