Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2009-11

Re: Enums RTTI/WriteStr & Mmacpas

3 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Richard Ward
Jonas wrote 13 lines
As of FPC 2.4.0, you will be able to use var s: string; { any kind of string will work begin writestr(s,enumvar); end; And afterwards 's' will contain the string representation of enumvar. In general, writestr is identical to the regular "write" procedure, except that it stores its output in a string (which you have to pass as first parameter). A similar "readstr" procedure will also be available.

Will readstr and writestr procedures be able to take multiple parameters for the variables or just one? For older mac programmers, these functions were used a lot and are nice to have. I know we have val and str in FPC but I keep forgetting the syntax and order of arguments of the FPC procedures. Not a big deal but I've always liked the readstr and writestr procedures.

Also, I have been trying to purge my code of anything to do with Mmacpas mode so it can be compatible with the new Objective C extensions being worked on in preparation for "PasCocoa/iPhone development" (or whatever it may end up being named.) The only keyword I am having trouble getting rid of is "return". There was some discussion of this previously as being able to replace "return" with "exit" but those two keywords are not quite a simple one word replacement in implementation. Again, it is not something I can't do without but it seems a nice clean way of doing things.

Although there may be a few people who need a backwards mac compatibility mode porting things from THINK Pascal, it might be considered to drop it since it seems to conflict with other compiler modes.

Reply by email

Michael Van Canneyt
to Richard Ward
Richard Ward wrote 21 lines
On Nov 5, 2009, Jonas wrote: > As of FPC 2.4.0, you will be able to use > > var > s: string; { any kind of string will work > begin > writestr(s,enumvar); > end; > > And afterwards 's' will contain the string representation of enumvar. In > general, writestr is identical to the regular "write" procedure, except > that it stores its output in a string (which you have to pass as first > parameter). A similar "readstr" procedure will also be available. Will readstr and writestr procedures be able to take multiple parameters for the variables or just one? For older mac programmers, these functions were used a lot and are nice to have. I know we have val and str in FPC but I keep forgetting the syntax and order of arguments of the FPC procedures. Not a big deal but I've always liked the readstr and writestr procedures.

It works just like regular read/write, but the output/input is going to/taken from a string.

Michael.

Reply by email

Jonas Maebe
to Richard Ward: Will readstr and writestr procedures be able to take multiple parameters for the…
Richard Ward wrote
Will readstr and writestr procedures be able to take multiple parameters for the variables or just one?

They are identical to regular read/write, so multiple parameters are possible.

Also, I have been trying to purge my code of anything to do with Mmacpas mode so it can be compatible with the new Objective C extensions being worked on in preparation for "PasCocoa/iPhone development" (or whatever it may end up being named.)

I don't think that's required. Afaik, you can perfectly have

{$mode macpas}
{$modeswitch objectivec1}

(except that will no longer be able to use the word "class" as variable/procedure name, because it's a reserved word when objectivec1 mode is active)

Show quoted text 6 lines
The only keyword I am having trouble getting rid of is "return". There was some discussion of this previously as being able to replace "return" with "exit" but those two keywords are not quite a simple one word replacement in implementation. Again, it is not something I can't do without but it seems a nice clean way of doing things.

The problem with allowing different keywords in different modes is that they can conflict with variable or procedure names (see above).

Although there may be a few people who need a backwards mac compatibility mode porting things from THINK Pascal, it might be considered to drop it since it seems to conflict with other compiler modes.

I don't see any reason at this point to drop macpas mode.

Jonas

Reply by email