TFPExpressionParser ...and jargon about strToFloat etc.

[lucamar]

When the functionality is known to be dependent of localization one always can write a de-localizer or de-localized conversion function (although I do see it a bit stupid that I must undo something that RTL is doing as library of very basic lego-blocks) and use it, instead of using the basic blocks to construct something more complex if not already included to libraries/books/units however one like to call them.

But you have got already the "lego" blocks! And they don't depend on default localization, either, unless you wish it.

Only, instead of using the most basic function overloads you've to use more "sophisticated" ones, so instead of  for example:

Code: Pascal  [Select][+][-]

1. Caption := FloatToStr(ANum)

you'd use:

Code: Pascal  [Select][+][-]

1. MySettings {a TFormatSettings} := DefaultFormatSettings;
2. MySettings.ThousandSeparator := '!';
3. MySettings.DecimalSeparator := ';';
4. Caption := FloatToStr(ANum, MySettings);

which for ANum=1234.56 would display as caption:

Code: [Select]

1!234;56An if you need even more control, there you've FloatToStrF() to which you can tell everything with the level of detail you want: format, notation, digits before/after the comma, ...

And similarly for, say, StrToFloat().

So the blocks are there; one just have to know they are there, which can be done by simply reading the documentation.

ETA: Corrected stupid mistake

[ArtLogi]

When the functionality is known to be dependent of localization one always can write a de-localizer or de-localized conversion function (although I do see it a bit stupid that I must undo something that RTL is doing as library of very basic lego-blocks) and use it, instead of using the basic blocks to construct something more complex if not already included to libraries/books/units however one like to call them.

But you have got already the "lego" blocks! And they don't depend on default localization, either, unless you wish it.

Only, instead of using the most basic function overloads you've to use more "sophisticated" ones, so instead of  for example:

Code: Pascal  [Select][+][-]

1. Caption := FloatToStr(ANum)

you'd use:

Code: Pascal  [Select][+][-]

1. MySettings {a TFormatSettings} := DefaultFormatSettings;
2. MySettings.ThousandSeparator := '!';
3. MySettings.DecimalSeparator := ';';
4. Caption := FloatToStr(ANum);

which for ANum=1234.56 would display as caption:

Code: [Select]

1!234;56An if you need even more control, there you've FloatToStrF() to which you can tell everything with the level of detail you want: format, notation, digits before/after the comma, ...

And similarly for, say, StrToFloat().

So the blocks are there; one just have to know they are there, which can be done by simply reading the documentation.

You do realise how non-self explanary these T-starting objects as some secondary kind of call parameter (whic eventyally is not even called call parameter, but used as such) are for a person who uses freepascal or anyother general language for like once in a four years to write something like ten thousand lines of code.

Indeed I will read the documentation of this FloatToStr, but it is really is more straight forward to use tools (without Txxxxx) found from systutils (because of their atomic nature) and a few other base units and a few IFs and FOR-loops to go pass things, than read these documents (if there is much more than comment from source, like with this RTL document), where you are referring to.

You see I'm on document reading phase with TFPExpressionParser (<- notice starts with T), I think I'm on that phase still many days more, but it does that much more than StrToFloat that it hopefully eventually pays back.

Of course I'm cratefull for persons who contribute to project like this, but come on.

[marcov]

Code: Pascal  [Select][+][-]

1. Caption := FloatToStr(ANum)

Caption := FloatToStr(ANum);[/code]

Personally I would make that

Code: Pascal  [Select][+][-]

1. Caption := FloatToStr(ANum,MySettings);

[lucamar]

Code: Pascal  [Select][+][-]

1. Caption := FloatToStr(ANum)

Caption := FloatToStr(ANum);[/code]

Personally I would make that

Code: Pascal  [Select][+][-]

1. Caption := FloatToStr(ANum,MySettings);

Oops! Yeah, that's what I meant; corrected now

You do realise how non-self explanary these T-starting objects as some secondary kind of call parameter (whic eventyally is not even called call parameter, but used as such) are for a person who uses freepascal or anyother general language for like once in a four years to write something like ten thousand lines of code.

Indeed I will read the documentation of this FloatToStr, but it is really is more straight forward to use tools (without Txxxxx) found from systutils (because of their atomic nature) and a few other base units and a few IFs and FOR-loops to go pass things, than read these documents (if there is much more than comment from source, like with this RTL document), where you are referring to.

If you're realy writing ten thousand lines of code, you should be familiar with the facilities offered by the language and the compiler libraries. Those T-starting objects you complain about are record (and whatnot) types someone took the time and effort to add and use to easy the use of the RTL/FCL/LCL and be able to add all those overloads with (yes!) parameters that allow you to do almost anything you'd wish without having to reinvent the wheel (i.e a few IFs and FOR-loops). And don't forget that most of those conversion functions (with overloads) are in SysUtils, if not in System, so it's not that much effort to find and use them, much less if you take the trouble of dedicating a day or two to read the RTL/FCL/LCL/LazUtils docs to refresh your knowledege when you (re-)start again after those four years.

But, of course, that's just my opinion; you can do whatever you see fit for you and your project(s). I just pointed a way to make something using the facilities already there.

[ArtLogi]

Code: Pascal  [Select][+][-]

1. Caption := FloatToStr(ANum)

Caption := FloatToStr(ANum);[/code]

Personally I would make that

Code: Pascal  [Select][+][-]

1. Caption := FloatToStr(ANum,MySettings);

Oops! Yeah, that's what I meant; corrected now

You do realise how non-self explanary these T-starting objects as some secondary kind of call parameter (whic eventyally is not even called call parameter, but used as such) are for a person who uses freepascal or anyother general language for like once in a four years to write something like ten thousand lines of code.

Indeed I will read the documentation of this FloatToStr, but it is really is more straight forward to use tools (without Txxxxx) found from systutils (because of their atomic nature) and a few other base units and a few IFs and FOR-loops to go pass things, than read these documents (if there is much more than comment from source, like with this RTL document), where you are referring to.

If you're realy writing ten thousand lines of code, you should be familiar with the facilities offered by the language and the compiler libraries. Those T-starting objects you complain about are record (and whatnot) types someone took the time and effort to add and use to easy the use of the RTL/FCL/LCL and be able to add all those overloads with (yes!) parameters that allow you to do almost anything you'd wish without having to reinvent the wheel (i.e a few IFs and FOR-loops). And don't forget that most of those conversion functions (with overloads) are in SysUtils, if not in System, so it's not that much effort to find and use them, much less if you take the trouble of dedicating a day or two to read the RTL/FCL/LCL/LazUtils docs to refresh your knowledege when you (re-)start again after those four years.

But, of course, that's just my opinion; you can do whatever you see fit for you and your project(s). I just pointed a way to make something using the facilities already there.

I will do. I also must thank you, about the code snippet, after all I most probably end up using it at some point of time.

About those T-starting objects Records are still rather straight forward (if the record is not too deep) vs object, but for perspective of someone like me those usually are hard to identify which is which as they are a bit like onions with layers after layers which end up really complex really soon. Not maybe yet in RTL so much, but on FCL and LCL. Another natural feature of them is that they are not necessary the same as similar object in another environment (ie. Edit-field) (at this case a programming language + libraries), compared to . Third natural feature is that they are often not as comprehensively documented (at one place), as more do-one-thing type of functions, due to their complexity and volunteer nature of development.

You are correct that someone who is re-learning (or learning and re-learning) should read manual (rtfm). What comes to 10k lines of code as absolut max including whitespace and comment and ide-generated parts etc., I'm pretty sure that someone which is fluent with most of the language and library features, shortcuts and so on could do the same with fraction of code. However if I must chose to do things vs. reading of doing things in these hobby projects, I prefer to do things, even if the code is by all professional standards ugly as hell, consisting all form of copypaste(ism) from past projects and so forth..

[Bart]

About those T-starting objects

You are aware that there is some common naming convention here that the name of (custom) types start with a T (with the exception of basic types like integer, char, string etc.)?

Bart

[ArtLogi]

About those T-starting objects

You are aware that there is some common naming convention here that the name of (custom) types start with a T (with the exception of basic types like integer, char, string etc.)?

Bart

So then TObject is custom type, while it is the parent of all (correct me if I'm wrong) objects found from FPC implementation of OPascal? So how it can be custom if it as much set on the stone as string (array of chars). PS. I almost forgot that there is one clever exception to this rule.

T-comes from Teacher it does have knowledge and methods and if it does have lucky students will heritage those both. Sometimes the students evolve to be so annoying that they return knowledge back to teacher. Seriously T I do assume comes from Type or Turbotype. While Record is a drawer and method is a clerk, when both are combined to same space it forms an concept of great suffering aka office.

tldr.. I really do not know where and how the name convention of this prefix uppercase T really comes and how it should work.

[lucamar]

tldr.. I really do not know where and how the name convention of this prefix uppercase T really comes and how it should work.

It's quite easy: the "Txxx" convention to name a type (as well as "Pxxx" to mean a pointer) comes from as far back as Turbo Pascal (it was Borland's convention) and Borland/CodeGear/Embarcadero have kept it alive through the years.

In the begining, it came about because objects used to be accessed mainly through pointers, so you'd have an object Something of type TSomething, accessed thorugh a pointer PSomething. So it's an historical artifact become a "convention", just as much as Microsoft's "hungarian notation"--and in fact can be seen as a simplification of that.

There's a document at Embarcadero (though I don't have the URI, sorry) explaining this and other conventions in their code which has become through the years the "standard" for almost all Pascal programmers.

Note that it's mostly used for non-intrisic, non-simple types (and yes, while it's forced as the "ancestor" of all classes TObject is neither of that and is declared, IIRC, in the unit Classes).

Ancient types (integer, char, etc.), of course, are part of the base (mostly Wirth's) language and follow no such convention, hence aliases and related types don't follow it either, much less "C" derived types.