On 03/04/2011 04:23 AM, Graham St Jack wrote:
On 04/03/11 12:34, Bekenn wrote:
On 3/3/11 3:30 PM, Graham St Jack wrote:
My first instinct would be to use non-templated functions that take const
char[].
Please don't ever restrict encodings like that. As much as possible,
libraries should seek to be encoding agnostic (though I'm all for
const-qualifying parameters). This is one area where I feel the standard
library severely lacks at present.
As a Windows developer, I prefer to use wchar strings by default and use only
the W versions of the Windows API functions, because the A versions severely
limit functionality. Only the W versions have full support for Unicode; the A
versions are entirely dependent on the current (8-bit) code page. This means
no support for UNC paths or paths longer than 260 characters, and also means
that international characters commonly end up completely garbled. Good
practice in Windows is to consider the A versions deprecated and avoid them
like the plague.
Ok, I don't mind supporting wchar and dchar in addition to char, especially if
Windows insists on using them.
My main issue here is with the constness of the parameters. I think the correct
parameter to pass is const C[]. This has the advantages of:
* Accepting both mutable and immutable data.
* Declares that the function won't mutate the data.
* Declares that the function doesn't expect the data to be immutable.
It would be even better to use const scope char[], declaring that a reference
won't be kept, but it seems that scope in this context is deprecated.
Once upon a time "in" meant const scope. Does anyone know what it means now?
AFAIK not only 'in' is still const scope, but it precisely means what your
param is: plain input.
(I would love params to be 'ini' by default.)
Denis
--
_________________
vita es estrany
spir.wikidot.com
