Mike Torrettinni

@Clément This is my quick setup: type IIF = class class function _<T>( aCond : boolean; aTrue : T; aFalse : T ) : T; end; class function IIF._<T>( aCond : boolean; aTrue : T; aFalse : T ) : T; begin if aCond then Result := aTrue else Result := aFalse; end; procedure TForm2.FormCreate(Sender: TObject); var i: integer; s: string; c: TVirtualStringTree; begin i := IIF._<integer>(i=1, 1, 2); s := IIF._<string>(i=1, '1', '2'); c := IIF._<TVirtualStringTree>(i=1, vst1, vst2); end; Do you have a recommendation on better naming?

Interesting, I like that idea! 🙂 I guess I'm chasing something like this - then we can avoid overloaded and the whole 'reimplementing' rtl functions:

Actually a setting or compiler directive 'prioritize last defined overloaded', this issue would be solved! It works with non overloaded methods, why can't it work with overloaded and directive?

I assume you are right - I'm the last one to judge the core of Delphi functionality... was just explaining what he was asking about with example. That is how I remember IfThen issues, but my experience is limited to simple type examples.

It works very good on simple types, I use it a lot. For example: IntegerValue := IfThen(condition, IntVal1, IntVal2); StringValue := IfThen(Condition, String1, String2); For expressions, you need to be aware they will be evaluated, so it can cause problems if not used correctly, like: vStr1 := '1'; vStr2 := ''; vInt := IfThen(condition, vStr1.ToInteger, vStr2.ToInteger); // will fail at runtime The runtime error will occur here: EConvertError with message ''' is not a valid integer value for Integer type' It's like with everything else in Delphi: if you don't use it is expected, you get unexpected behavior. Use it as is it designed, you get correct behavior.

You are right, it doesn't seem like there is a perfect solution. A trade off in all cases. Will see how it goes with this, perhaps I will realize it was not a good decision, or it will be really neat solution to my problem.

Just trying to clean up the uses clause. And these are simple functions, nothing I need to worry about Delphi changing in the future.

I have many units where I need access to integer, string and one of custom IfThen implementations. So, I want to just use my Utils.pas, without StrUtils and Math in these units.

Oh, I didn't think about this... I'm not used to using unit identifiers, except in some cases. Before I started using namespaces for unit names, it would be easier, but now it's getting annoying to have to name the full unit name. Like: ProjectName.Utilities.IfThen() instead of just IfThen() If there is no other way, then I can start using unit prefix. But it will take time to adjust. No, Utils.pas name is just for this example purpose.

Integer and String, copied from Math and StrUtils.

Good suggestions! At this moment this was a test of micro benchmarking, and if similar concept is applied to multiple methods, it might bring some more than micro improvements. Of course this is not a 'let me test this quickly in 1h and know the results'... it will take time and results might not be what I was hoping for, or I might be surprised and it turns out to be big overall improvement. 🙂

Thank you. Interesting suggestion, but I don't use unit initialization sections (I think only in 1). I have 'prepare on start' unit/methods that handle/control project behavior, executed before first form is shown.

Very good, thanks! This is years old function working as expected. Maybe it's time for an improvement, but only if there is benefit at the end. I'm not trying a change for the sake of a change.

It this change is an actual improvement and if it becomes a template for similar functions, it could have noticeable effect on overall project. Of course, if at the end the result is not worth it, then change will not be implemented.

Not sure if this is of any value in your case, but I remember analyzing Process Monitor log and discovering my exe unnecessary accessing/or repeated opening, closing Registry (instead of open once and access and close when not used anymore). I also discovered it was trying accessing some non-existent files on the disk, causing slow load/start time. This was not very clear at analyzing source. https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

I wasn't actually referring to these one-liners... 🙂 I would say I often try to optimize things that are 'fun', something I know I can do. If it's something very new to me, I hesitate but eventually go at it. So, 90% of the time is fun, I guess.

Nice try! 🙂

No need for sorry, at all, really. When I was compared to a boy from 'Boy who cried wolf' story, it took me a while to realize how different personalities we have on this forum and to not take it personally, sometimes is just the language or wording 🙂 The usual trio of one-liners is not complete, in this topic, yet 🙂 Back to topic: I didn't implement this change, yet, but will have it on the list to evaluate in the future. The Hex2Bin topic, from the other day, gave me a boost to try and see if little tricks make big improvements, but I rarely touch functions below 1% of total runtime, this one is more exception than the rule.

Thank you, but I think we have different definition of maintainable code. Until a few years ago I didn't use classes, I had 1000s of global variables, long methods, so nothing refactored... And now you guys describing splitting this function into 2 functions for performance (or whatever reason) as ugly, non-maintainable code... we are so far apart on this, we are not even in the same zip code (or same country, for European friends) 🙂 I do appreciate all suggestions and comments! It would be nice to know if someone had similar experience, did similar thing, and how such micro optimization came back causing issues later.

My memory is already bad, just ask my wife 🙂

OK, thanks. Good suggestion on class encapsulation, if possible. I'm not worried about ugly code, if I add comments and meaningful names, I'm OK with it, if it performs good. Of course such functions are rarely changed, so maintenance is also not really a deciding factor.

Aha, interesting. Now I understand what @Attila Kovacs meant in his comment: I was still focused on local unused variables vs no-local variables. Wasn't focused on string variable.

OK, thanks, interesting suggestion. In this case this could work, because flag doesn't change while the project is running, set at the beginning for the whole runtime of project.

Are you guys suggesting that I set the function type at the time when I set the flag (SetFlag), something like: flag := SetFlag; // flag is initialize on Project start if flag then ProcessString := ProcessStringWhenFlagIsTrue else ProcessString := ProcessStringWhenFlagIsFalse; // function type type TProcessStringType = function(const aStr: string): string; ProcessString = TProcessStringType; // usage of ProcessString function vStr := ProcessString('x'); ?

No need to go beyond Delphi's capabilities. This whole topic was great to follow, all this knowledge! 🙂