Frank Heckenbach:
Apologies for duplication, but you replied to subsequent messages and a copied part of this one, so I'm guessing you didn't see the questions below. I'm responding to your complex (to me) message about ncurses types and automatic configuration for multiple hosts. Any verification or correction of my approach would be appreciated.
Earlier Message from willett@udel.edu:
Frank, thanks very much for all your advice. I'm trying to get up to speed here.
Ok, based on your message, I'm now using: MedCard for chtype in ncurses.h (assuming typedef unsigned long chtype) CBoolean for "bool" in ncurses.h (assuming typedef unsigned int bool) CBoolean for an "int" which contains only TRUE or FALSE CInteger for an "int" used as an integer (on older gpc I use "integer") tacs now uses index of char128 = #0 .. #127
The c translation types are very useful! Thanks.
Did I understand you to say I should use CBoolean in both the above cases?
To create the ncurses.h file, I have to run ./configure within the ncurses source directory. I could run this several times for different hosts, to find what the range of types are. Right? Could you suggest a couple of different hosts to try out? Say, the most common? or perhaps, the most different? or better, how do I read the configuration file directly? I see that "configure" is a readable text file, but I can't find a list of alternative "bool" (for example) definitions in that configuration file.
In fact, I can't figure out what my own host (Mac OSX) is called, when I try
./configure host=powerpc-apple-darwin
I get an "unknown host" message. Any suggestions?
When you said:
BTW (unrelated), I'd suggest to rename the package to `gpc-ncurses-...' or `ncurses-gpc-...', to avoid confusion with an ncurses library package.
Did you mean I should name the interface file, e.g. ncurses.pas -> gpc-ncurses.pas
or the unit, e.g. unit ncurses; -> unit gpc-ncurses;
(If the latter, wouldn't gpc_ncurses be a more standard Pascal name than gpc-ncurses?)
To do more things like reading the ncurses.h headers and then automatically configuring ncurses.pas types to be consistent, that's a bit beyond me. Beyond, both in that I wouldn't know how to and that I don't have time to learn how to and test all these. I wouldn't want to write c wrappers, a lot of work and then we're stuck with double calls. What I'm thinking now is to use all your MedCard, CBoolean, etc types, and put in documentation warning about what types of hosts would need edits before use. and/or how to check ncurses.h and hand-modify ncurses.pas.
Does this approach and the above modifications seem reasonable?
Willett Kempton
willett wrote:
Frank Heckenbach:
Apologies for duplication, but you replied to subsequent messages and a copied part of this one, so I'm guessing you didn't see the questions below. I'm responding to your complex (to me) message about ncurses types and automatic configuration for multiple hosts. Any verification or correction of my approach would be appreciated.
Earlier Message from willett@udel.edu:
Frank, thanks very much for all your advice. I'm trying to get up to speed here.
Ok, based on your message, I'm now using: MedCard for chtype in ncurses.h (assuming typedef unsigned long chtype) CBoolean for "bool" in ncurses.h (assuming typedef unsigned int bool) CBoolean for an "int" which contains only TRUE or FALSE CInteger for an "int" used as an integer (on older gpc I use "integer") tacs now uses index of char128 = #0 .. #127
The c translation types are very useful! Thanks.
I hope not to bore you with my yakitty yak.
First, is MacOSX a POSIX compliant operating system ?? On linux, you type the command " printenv | more " and you will learn a lot about your system.
Second, I believe the CString type is important. Your interface (like FPC) uses the PChar type. PChar works but is ambiguous, CString is not ambiguous. NCurses will use a lot of CStrings.
The rest, I don't know. Just plain ncurses.pas works for me. The only programming snag is GPC demands that a function is treated as a function. FPC lets a function pass as a procedure.
Good work. Important, too.
Thanks, Rick.
On 3 May 2005 at 20:27, Rick Engebretson wrote:
[...]
Second, I believe the CString type is important. Your interface (like FPC) uses the PChar type. PChar works but is ambiguous, CString is not ambiguous. NCurses will use a lot of CStrings.
A CString is the same thing as a PChar.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com/
Rick Engebretson wrote:
The rest, I don't know. Just plain ncurses.pas works for me. The only programming snag is GPC demands that a function is treated as a function. FPC lets a function pass as a procedure.
GPC doesn't do it unconditionally as it's too dangerous.
`--ignore-function-results' will do it globally (NOT recommended!)
`attribute (ignorable)' for a specific function (only recommended if the result is meaningless and can always be safely ignored, don't use if the result is an error status)
`Discard (MyFunc (...))' for an individual call
Frank
Hi Folks,
willett wrote:
MedCard for chtype in ncurses.h (assuming typedef unsigned long chtype) CBoolean for "bool" in ncurses.h (assuming typedef unsigned int bool) CBoolean for an "int" which contains only TRUE or FALSE CInteger for an "int" used as an integer (on older gpc I use "integer") tacs now uses index of char128 = #0 .. #127
Question: Are there types to use the other way around? I.e. do we have a C header with a `_p_int` type we can be sure to remain an 1:1 mapping of the gpc integer type, regardless of future compiler changes?
Yours,
Markus
Markus Gerwinski wrote:
Question: Are there types to use the other way around? I.e. do we have a C header with a `_p_int` type we can be sure to remain an 1:1 mapping of the gpc integer type, regardless of future compiler changes?
No!
Frank
Frank Heckenbach wrote:
Markus Gerwinski wrote:
Question: Are there types to use the other way around? I.e. do we have a C header with a `_p_int` type we can be sure to remain an 1:1 mapping of the gpc integer type, regardless of future compiler changes?
No!
Thanks.
Next question: Where can I find a complete list of Pascal types that are 1:1 mappings of C types, and what they map?
I also made up a C header containing this declaration:
typedef enum { gpc_false, gpc_true } gpc_bool;
for compatibility. Is this one a valid mapping, or would you rather recommend me another one?
Regards,
Markus
Markus Gerwinski wrote:
Next question: Where can I find a complete list of Pascal types that are 1:1 mappings of C types, and what they map?
Programming: Data Types: Integer Types: Main Branch Integer Types
Programming: Data Types: Real Types
CString -> [const] char *
Char -> unsigned char
Boolean -> unsigned char
Enums, records and arrays if structurally identical, not packed in Pascal, and same alignment options used.
I also made up a C header containing this declaration:
typedef enum { gpc_false, gpc_true } gpc_bool;
for compatibility. Is this one a valid mapping, or would you rather recommend me another one?
typedef unsigned char Boolean;
(as several of the C files of the units do).
And if you like:
enum { gpc_false = 0; gpc_true = 1; };
(or macros if you prefer, whatever).
Frank
Frank Heckenbach wrote:
Programming: Data Types: Integer Types: Main Branch Integer Types
Programming: Data Types: Real Types
Thank you. One more question here: Can I be sure that the GPC `real' will remain equivalent to the GCC `double'?
I also made up a C header containing this declaration:
typedef enum { gpc_false, gpc_true } gpc_bool;
for compatibility. Is this one a valid mapping, or would you rather recommend me another one?
typedef unsigned char Boolean;
Thanks again.
Best,
Markus
Markus Gerwinski wrote:
Frank Heckenbach wrote:
... snip ...
I also made up a C header containing this declaration:
typedef enum { gpc_false, gpc_true } gpc_bool;
for compatibility. Is this one a valid mapping, or would you rather recommend me another one?
typedef unsigned char Boolean;
In Pascal a Boolean has the enumerated values false, true. The standards specify that the ord(false) is 0, which forces ord(true) to be one. A boolean is not compatible with an integer, but the ord of a boolean is an integral type. There is no guarantee as to how much storage is used by a boolean, that is up to the implementor. The common choices are byte and integer. A PACKED ARRAY OF boolean _may_ only use one bit per item.
Markus Gerwinski wrote:
Frank Heckenbach wrote:
Programming: Data Types: Integer Types: Main Branch Integer Types
Programming: Data Types: Real Types
Thank you. One more question here: Can I be sure that the GPC `real' will remain equivalent to the GCC `double'?
I suppose so, but I thought so with `Integer' and `int' a few years ago, so if you want to be really sure, you might want to use `Double' in Pascal.
Frank
-
CBFalconer -
Frank Heckenbach -
Markus Gerwinski -
Prof. A Olowofoyeku (The African Chief) -
Rick Engebretson -
willett