main logo
Subject: Re: [C++] Support of all: char* path, POSIX path, FSRef, FSSpec
Author: Andreas Grosam
Posted: 2002/11/28 06:11:51
 
View Entire Thread
New Search


On Mittwoch, 27. November 2002, Ruslan Zasukhin <sunshine /at/ public DOT kherson.=
ua> wrote:
>[C++] Support of all: char* path, POSIX path, FSRef, FSSpecHi
>Guys,
>
> While we work here on VPHP we have meet problem that we need
>support POSIX paths for VSDK and VCSDK.
>
> After investigation of question it looks that only way is
>next:
>
> For example for VDK_Database class
> I have made the next 3 functions for Create():
>
>
> FBL_EXP virtual =A0=A0=A0void =A0=A0=A0=A0=A0=A0=A0CreateDataBase(
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0const char* =A0=A0=A0=A0=A0inFullPath, =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0ulong =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0inSizeOfCluster =3D (32 * 1024L), =
=A0=A0=A0
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0FBL_DbMode =A0=A0=A0=A0=A0=A0inMode =3D kFBL_Dsc_=
Dat_Blb_Ind, =A0=A0=A0
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0uchar =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0inNativeOS =3D =
0
>); =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
>
>
> #if FBL_MAC
> FBL_EXP virtual =A0=A0=A0void =A0=A0=A0=A0=A0=A0=A0CreateDataBase(
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0const FSSpec* =A0=A0=A0inFileSpec, =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0ulong =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0inSizeOfCluster=
=3D (32 * 1024L), =A0=A0=A0
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0FBL_DbMode =A0=A0=A0=A0=A0=A0inMode =3D kFBL_Dsc_Dat_=
Blb_Ind, =A0=A0=A0
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0uchar =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0inNativeOS =3D =
0 ); =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
> #endif // FBL_MAC
>
> #if TARGET_API_MAC_CARBON
> FBL_EXP virtual =A0=A0=A0void =A0=A0=A0=A0=A0=A0=A0CreateDataBase(
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0const FSRef* =A0=A0=A0=A0inParentFolder, =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0const UniChar* =A0=A0inFileName, =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0ulong =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0inSizeOfCluster =3D (32 * 1024L), =
=A0=A0=A0
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0FBL_DbMode =A0=A0=A0=A0=A0=A0inMode =3D kFBL_Dsc_=
Dat_Blb_Ind, =A0=A0=A0
>=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0uchar =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0inNativeOS =3D =
0 ); =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
> #endif // TARGET_API_MAC_CARBON
>
>
> Also the same 3 functions for OpenDatabse()
>
> Also we have
>=A0=A0=A0=A0Dump() LoadDump()
>
> And in Cursor
>=A0=A0=A0=A0Import/Export
>
> All these 6 functions must have 3 forms to support all ways.
> In fact 2 forms are from MacOS... =A0
>
> Not pleasant but I do not see other way...
>
> Any comments ?

I tend to simplicity:
Support only the POSIX path (narrow char filenames) in the interfaces.

For Mac and other "exotic" OS add an addionally library, where users (we) =
can convert from FSSpec to a path. MoreFiles is OK, so you need just to =
refere to it.


On original UNIX, the file system does not support unicode (or UCS, ISO =
10646, etc) for filenames (although UNIX may support several character =
codes in narrow characters and different locales). And if it is supported =
on a certain system (mostly UTF-8 only), using unicode might lead to =
severe problems, at least portability issues and "moving" databases from =
one system to another, or UNIX tools not taking care of it.
unicode is an OS specific extension.

Disadvantage: there might be ambiguities on the Mac (and restrictions) - =
but since the advent of MacOS X we should avoid ambiguities in volumn =
names and filenames because of the UNIX under the hat.

IMO, not having UNI code and several encodings for filenames, shouldn't be =
an issue for us -- but we want it for database strings! ;)

And, for you Ruslan, it might be an issue if you need to refere to =
filenames which are stored in meta data section of the database. Then you =
need to fiddling around with unicode and encodings and generally take care =
of it - probably in common portable source code.=20
Supporting unicode might be unneccessary and exaggerated for that purpose.=20



Andreas

see also, http://www.cl.cam.ac.uk/~mgk25/unicode.html
IMO, the best site for unicode and related stuff.

>
>
> --
> Best regards,
> Ruslan Zasukhin =A0=A0=A0=A0=A0[ I feel the need...the need for speed ]
> -------------------------------------------------------------
> e-mail: ruslan@paradigmasoft.com
> web: http://www.paradigmasoft.com
>
> To subscribe to the Valentina mail list
> send a letter to valentina-on /at/ lists DOT macserve.net
> -------------------------------------------------------------
>
 
©2002 Andreas Grosam
<-- Prior Message New Search Next Message -->