Mattias Gaertner wrote:
On Mon, 01 Dec 2008 15:06:45 +0000
Martin Friebe <[EMAIL PROTECTED]> wrote
That would mean that in order to avoid conversation, some functions
of the RTL would be needed in overloaded versions for each string
type. IMHO this applies only to those, which do not (or not always)
make calls to the OS. Any other function does the conversation
anyway. (It will be a case by case base)
Sorry, I can't follow here.
Please enlighten me, why an overloaded function with an internal
conversion is better than an implicit conversion?
I made a difference between rtl function which will call OS functions
(the one that would need to internally convert the format) and those
that do not make OS calls (or do not always make them)
Yes I agree, and said so before: If a rtl function is going to pass on
the data to the OS, and conversation is always needed, then no
overloading is needed. Use RTLString.
If an function does not use the OS (e.g extract file-path or name) then
no internal conversion is needed. Therefore overloaded functions would
give benefit to some programmers. (to name one group: most beginners,
who have more than enough to worry about; and will be glad if strings
are kept simple to use ( a fixed known type, not a type that looks
somehow abstract, because you do not know its implementation at the time
you write your code)
[...]
Also it would be nice (so I do not know how) not to have to duplicate
code, in order to archive this. Something like generics, maybe.
The goal of RTLString is to avoid duplicate code in the RTL.
Yes I acknowledged that this would be a problem. And also RTLString has
the benefit, of allowing unicode fpc to be available far earlier than it
would otherwise.
The question remains, could it then be extended/optimized? Maybe a
generic like template (for functions, instead of objects)? Which needs
to be written only once, and the will be specialized for each string type?
Best Regards
Martin
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
