I haven't tried it out, but if it works well I'd love to see it included with FPC core.+1 :)
3. You can get rid of the typeinfo parameter and introduce type safetyVery nice, thanks! I would really appreciate this change. 8)
I haven't tried it out, but if it works well I'd love to see it included with FPC core.I don't want to disencourage you, but in my eyes, it is not flexible enough for inclusion in fcl: What if I want floats in scientific notation, integers in hex, a different field separator?
I don't want to disencourage you, but in my eyes, it is not flexible enough for inclusion in fcl: What if I want floats in scientific notation, integers in hex, a different field separator?
I haven't tried it out, but if it works well I'd love to see it included with FPC core.I don't want to disencourage you, but in my eyes, it is not flexible enough for inclusion in fcl: What if I want floats in scientific notation, integers in hex, a different field separator?
One of the ways to enable customization for users is like we already have with DefaultFormatSettings record which is of TFormatSettings type. Anyone wanting customization could populate DefaultToStrSettings record with his own likings and everyone is happy. We could even allow optional parameter for settings record parameter. For scientific notation of floats, I think that ToStr should already use DefaultFormatSettings from FPC.I haven't tried it out, but if it works well I'd love to see it included with FPC core.I don't want to disencourage you, but in my eyes, it is not flexible enough for inclusion in fcl: What if I want floats in scientific notation, integers in hex, a different field separator?
@correa.elias
I have reviewed the code and it looks very nice.
I have a couple of remarks, though:
1. ManagedFldCount is deprecated (at least in 3.2.0 and trunk).
You can replace it with TotalFieldCount. (The compiler actually gives two suggestions. I chose this one)
2. I prefer {$mode Delphi}{$coperators on} over mode objfpc (see below code why!)
3. You can get rid of the typeinfo parameter and introduce type safety like so:
{$mode delphi}{$coperators on} function ToStr(var AX; ATypeInfo: PTypeInfo): AnsiString;overload; function Tostr<T>(var Value:T):AnsiString;overload; // <---- implementation function Tostr<T>(var Value:T):AnsiString;overload; begin Result :=Tostr(value,typeinfo(t)); end;
My initial tests show no regressions with these minor changes.
(objfpc mode generics look silly and won't allow this, delphi mode does allow it)
(To me objfpc mode for generics are deprecated)
I agree with the formatting thing, and its very easy to change it :I haven't tried it out, but if it works well I'd love to see it included with FPC core.I don't want to disencourage you, but in my eyes, it is not flexible enough for inclusion in fcl: What if I want floats in scientific notation, integers in hex, a different field separator?
I have reviewed the code and it looks very nice.I will include the generic version, its fantastic! (as long as it compiles for people using the unit in objfpc mode too).
I have a couple of remarks, though:
1. ManagedFldCount is deprecated (at least in 3.2.0 and trunk).
You can replace it with TotalFieldCount. (The compiler actually gives two suggestions. I chose this one)
2. I prefer {$mode Delphi}{$coperators on} over mode objfpc (see below code why!)
3. You can get rid of the typeinfo parameter and introduce type safety like so:
Code: Pascal [Select]
{$mode delphi}{$coperators on}
function ToStr(var AX; ATypeInfo: PTypeInfo): AnsiString;overload;
function Tostr<T>(var Value:T):AnsiString;overload; // <----
implementation
function Tostr<T>(var Value:T):AnsiString;overload;
begin
Result :=Tostr(value,typeinfo(t));
end;
My initial tests show no regressions with these minor changes.
I don't want to disencourage you, but in my eyes, it is not flexible enough for inclusion in fcl: What if I want floats in scientific notation, integers in hex, a different field separator?As suggested by marcov, avra, thaddy and garlar27 its easy to remedy by adding a FormatSettings parameter with a default value for the lazy :D. I will implement this: A FormatSettings record that includes float point, integer, boolean ect formatting and custom delimiters for array and record(currently '[]' and '()'), and the delimiter itself (currently a coma).
Within that context he did a pretty good job! Within that context it is also valuable, not to the FCL but to the rtl: in sysutils.Theres other functions that uses typeinfo for string conversion like SetToString and GetEnumName, both in typinfo unit (i mean, its another place where ToStr could reside if its included in core).
I would still prefer Str() function name instead of ToStr() - and yes, I am aware there is already a Str() procedure.Its a good name too, and could be used as an overload. I choose 'ToStr' because conversion functions uses it: IntToStr, FloatToStr and BoolToStr. It could be called VarToStr too...
Added new page http://wiki.freepascal.org/ToStrThanks alextp!
I'd love to see it included with FPC coreIt would be great!
I will include the generic version, its fantastic! (as long as it compiles for people using the unit in objfpc mode too).Yes, that works..... I understand your problem with FPC 3.0.4. just make a note ( or an ifdef)
About the name deprecation, i am using 3.0.4 so i cant change it for now.
I would still prefer Str() function name instead of ToStr() - and yes, I am aware there is already a Str() procedure.I would name it "xToStr" or "AnythingToStr" instead.
Some optimizations (so the file with a different name). Longer source code but shorter generated (about 30% on Win64).
1. Changed var to const.
2. Added simple validation of invalid input parameters.
3. Unnecessary code call is excluded. For example, TFormatSettings is only needed for floating types, or calling GetTypeData only for some cases.
4. Removed hints in clear places.
5. Repeated code (enumeration of array or record elements) is extracted to a separate procedure.
If there was ability to get TypeInfo for each array of const or just any parameter of called function, this feature would be much nicier to use:Well, that's not possible. That's why I wrote the generics addition. Tostr<SomeType>(SomeVariable); // strongly typed.
You could just do print([some_variable])
That's why I wrote the generics addition. Tostr<SomeType>(SomeVariable); // strongly typed.I think generic is not good here.
No in mode delphi you don't ruin your keyboard. I am still curious why people use objfpc mode for generics if even the devs don't. It is not a religion but a relict.Hellooho? I only use mode ObjFPC. Mode Delphi is only used for testing, cause aside from bugs (like the one with the overload here; did anyone report that already?) mode ObjFPC's generics are superior to the mode Delphi ones as one can use complex inline specializations that currently aren't possible in mode Delphi.
Otherwise you did a good job refactoring the code, btw.
Hellooho? I only use mode ObjFPC. Mode Delphi is only used for testing, cause aside from bugs (like the one with the overload here; did anyone report that already?) mode ObjFPC's generics are superior to the mode Delphi ones as one can use complex inline specializations that currently aren't possible in mode Delphi.If that's indeed the case it would be a reason to me to revisit them if inlining is an issue, which it is sometime. Why is that not in {$mode delphi}, just curious? (I noticed it, but assumed objfpc suffered the same)