Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 07/27/24 in all areas

  1. dummzeuch

    Avoid parameter evaluation

    Yes, some special characters plus if plus ifend are a lot more convenient than an if then statement. I'm sold.
  2. Remy Lebeau

    Avoid parameter evaluation

    Not quite. You have implemented DoProcess() incorrectly, causing undefined behavior. The code compiles, but it will not behave correctly at runtime for certain types. For instance, try passing a single Char into it and your code will crash. That approach is wrong. You cannot treat all of those types the same way, as they are stored in different ways in the array. vtChar and ctWideChar are stored as individual values in the array itself (like integers are), whereas vtString is a pointer to a ShortString variable, whereas vtAnsiString and vtUnicodeString are copies of the data block pointer from inside of an AnsiString/UnicodeString instance, etc. You need to handle the various types individually and correctly, eg: procedure DoProcess(const Args: array of const); var i: Integer; begin for i := Low(Args) to High(Args) do begin case Args[i].VType of vtString: Writeln(Args[i].VString^); vtChar: Writeln(Args[i].VChar); vtPChar: Writeln(Args[i].VPChar); vtWideChar: Writeln(Args[i].VWideChar); vtPWideChar: Writeln(Args[i].VPWideChar); vtAnsiString: Writeln(AnsiString(Args[i].VAnsiString)); vtWideString: Writeln(WideString(Args[i].VWideString)); vtUnicodeString: Writeln(UnicodeString(Args[i].VUnicodeString)); vtInteger: Writeln(Args[i].VInteger); vtInt64: Writeln(Int64(Args[i].VInt64)); else Writeln('Type handling not implemented yet ' + IntToStr(Args[i].VType)); end; end; end; Also, see the MakeStr() example in this earlier post:
  3. Lajos Juhász

    Devin AI - Is it already happening?

    Microsoft might or might not using Github for train AI. How can you be sure that when you send with a prompt a piece of code it is not going to be used for training the AI system. If that code contain some top secret detail. The owner of the source code could sue the developer. (I daily work on code bases that is owned by a client of the company I am working for)
  4. Remy Lebeau

    Avoid parameter evaluation

    Since performance is in question, I would suggest taking this approach a step further and use 'array of const' instead of 'array of string'. That way, you can pass in integers and other fundamental types as-is and not invoke the overhead of converting them to strings unless you are sure you actually need to, eg: procedure Log(LogLevel: TLogLevel; const Args: array of const); overload; begin if CanLog(LogLevel) then begin // convert Args to a log message and write it out as needed... end; end; Log(llTrace, ['Test', GetLastError(), ...]);
  5. David Schwartz

    Avoid parameter evaluation

    Delphi is a few decades behind contemporary language features today. The last several language additions have been around since the 90's. I'm not sure how far into the 2000's they are yet. I think I'll be long dead before they catch up with the more popular language features that most languages already support today in 2024. I mean ... hey ... the only thing added in D12 was multi-line string literals. WOOT! WOOT! I'm not moving off of D10.4.2 until they start focusing on real language improvements. Given how many emails I'm getting lately trying to urge people to get back onto maintenance plans, I'm guessing the user base is shrinking ... maybe because nobody wants to use a language that's still stuck in the 90's when most contemporary languages are still evolving quite steadily. I think Delphi introduced anonymous methods and closures before Java did. But since then, Java has updated them with nearly every release, and they look nothing like they did initially. I can't think of anything that has changed with Delphi's syntax.
×