Lazarus

Miscellaneous => Suggestions => Topic started by: 440bx on June 23, 2019, 12:05:17 pm

Title: A suggestion for a new FPC feature
Post by: 440bx on June 23, 2019, 12:05:17 pm
Hello,

Pascal/Delphi/FPC limit the declaration of "variant"(s) in records to be the last field in the record.

It would very nice if that limitation was removed thus allowing variants to appear anywhere and, in multiple places, in a record type.

It would simplify porting C data type definitions to FPC/Pascal and increase the expressive power of the language.

Just a wish upon a binary star....


Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on June 23, 2019, 01:02:20 pm
AFAIK, in both Pascal and C/C++ records (structs) are fixed length. If you want to add something that isn't (like a string), you have to store that outside the record and add a pointer.
Title: Re: A suggestion for a new FPC feature
Post by: Thaddy on June 23, 2019, 01:33:46 pm
That's not correct. Variant parts of records always have the size of its largest possible member.
I actually agree with such a feature, although you can work around it without reordering by pre-declaring sub records and use those as members of the final record  or nested variant parts.

Because the size of a variant record part is always known, it can't be too difficult to implement such a feature, although this is more like syntax sugar than absolute necessity.
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on June 23, 2019, 01:33:57 pm
AFAIK, in both Pascal and C/C++ records (structs) are fixed length. If you want to add something that isn't (like a string), you have to store that outside the record and add a pointer.
They are fixed length only if their definition makes them that way.   They can vary in length if the programmer chooses to define them as variable.  Here is an example (from MSDN):
Code: Pascal  [Select]
  1. typedef struct {
  2.   GUID  PowerSetting;
  3.   DWORD DataLength;
  4.   UCHAR Data[1];
  5. } POWERBROADCAST_SETTING, *PPOWERBROADCAST_SETTING;
the size of the record varies depending on the size of the "Data" array which is specified in the field "DataLength".  Another example that comes to mind is the size of the IMAGE_LOAD_CONFIG_DIRECTORY32/64 in a PE file.  It varies depending on how many fields the compiler decided to use and its size is determined by the first field "Size".  Dumpbin seems to be the only PE dump utility that handles that structure correctly.

But, that really isn't a new feature, Pascal can do either of those already the same way it's done in C.

OTH, translating/converting a definition like:
Code: Pascal  [Select]
  1. typedef struct JOBOBJECT_NOTIFICATION_LIMIT_INFORMATION_2 {
  2.     DWORD64 IoReadBytesLimit;
  3.     DWORD64 IoWriteBytesLimit;
  4.     LARGE_INTEGER PerJobUserTimeLimit;
  5.     union {
  6.         DWORD64 JobHighMemoryLimit;
  7.         DWORD64 JobMemoryLimit;
  8.     } DUMMYUNIONNAME;
  9.  
  10.     union {
  11.         JOBOBJECT_RATE_CONTROL_TOLERANCE RateControlTolerance;
  12.         JOBOBJECT_RATE_CONTROL_TOLERANCE CpuRateControlTolerance;
  13.     } DUMMYUNIONNAME2;
  14.  
  15.     union {
  16.         JOBOBJECT_RATE_CONTROL_TOLERANCE_INTERVAL RateControlToleranceInterval;
  17.         JOBOBJECT_RATE_CONTROL_TOLERANCE_INTERVAL
  18.             CpuRateControlToleranceInterval;
  19.     } DUMMYUNIONNAME3;
  20.  
  21.     DWORD LimitFlags;
  22.     JOBOBJECT_RATE_CONTROL_TOLERANCE IoRateControlTolerance;
  23.     DWORD64 JobLowMemoryLimit;
  24.     JOBOBJECT_RATE_CONTROL_TOLERANCE_INTERVAL IoRateControlToleranceInterval;
  25.     JOBOBJECT_RATE_CONTROL_TOLERANCE NetRateControlTolerance;
  26.     JOBOBJECT_RATE_CONTROL_TOLERANCE_INTERVAL NetRateControlToleranceInterval;
  27. } JOBOBJECT_NOTIFICATION_LIMIT_INFORMATION_2;
  28.  
  29.  
to Pascal is tedious and cumbersome because Pascal only allows one variant part and it _must_ be last in the record definition.

Removing the limitation that variant parts can only occur once and last in a record definition would definitely simplify some data type definitions.






Title: Re: A suggestion for a new FPC feature
Post by: Thaddy on June 23, 2019, 01:38:21 pm
read my previous reply, the crossed.
A variant record is fixed length based on largest member, just like a union.
But  can be type checked on all members, that's something different.

For that reason, your suggestion is sound.
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on June 23, 2019, 02:11:01 pm
read my previous reply, the crossed.
A variant record is fixed length based on largest member, just like a union.
But  can be type checked on all members, that's something different.

For that reason, your suggestion is sound.
I noticed our posts crossed. I didn't reply at the time because I concur with what you said.

It's more than just syntactic sugar though.  Having that feature would make it much easier to write a general ".h to .pas" header translator because the translator wouldn't be faced with the necessity of having to generate an additional definition and a name for the union to use in the record declaration.

There are quite a few debugging structures that use multiple unions to cover type definitions, not to mention structures like:
Code: Pascal  [Select]
  1. typedef struct _D3DKMT_VIDMM_ESCAPE                        {
  2.     D3DKMT_VIDMMESCAPETYPE Type;
  3.     union
  4.     {
  5.         struct
  6.         {
  7.             union
  8.             {
  9.                 struct
  10.                 {
  11.                     ULONG ProbeAndLock : 1;
  12.                     ULONG SplitPoint : 1;
  13.                     ULONG NoDemotion : 1;
  14.                     ULONG SwizzlingAperture : 1;
  15.                     ULONG PagingPathLockSubRange : 1;
  16.                     ULONG PagingPathLockMinRange : 1;
  17.                     ULONG ComplexLock : 1;
  18.                     ULONG FailVARotation : 1;
  19.                     ULONG NoWriteCombined : 1;
  20.                     ULONG NoPrePatching : 1;
  21.                     ULONG AlwaysRepatch : 1;
  22.                     ULONG ExpectPreparationFailure : 1;
  23.                     ULONG FailUserModeVAMapping : 1;
  24. #if (DXGKDDI_INTERFACE_VERSION >= DXGKDDI_INTERFACE_VERSION_WIN8)
  25.                     ULONG NeverDiscardOfferedAllocation : 1;
  26.                     ULONG AlwaysDiscardOfferedAllocation : 1;
  27.                     ULONG Reserved : 17;
  28. #else
  29.                     ULONG Reserved : 19;
  30. #endif
  31.                 };
  32.                 ULONG Value;
  33.             } DUMMYUNIONNAME;
  34.         } SetFault;
  35.         struct
  36.         {
  37.             D3DKMT_HANDLE ResourceHandle;
  38.             D3DKMT_HANDLE AllocationHandle;
  39.             HANDLE hProcess;        // 0 to evict memory for the current process, otherwise it is a process handle from OpenProcess(PROCESS_ALL_ACCESS, FALSE, ProcessId).
  40.         } Evict;
  41.         struct
  42.         {
  43.             UINT64 NtHandle;           // Used by D3DKMT_VIDMMESCAPETYPE_EVICT_BY_NT_HANDLE
  44.         } EvictByNtHandle;
  45.         struct
  46.         {
  47.             union
  48.             {
  49.                 struct
  50.                 {
  51.                     UINT NumVads;
  52.                 } GetNumVads;
  53.                 D3DKMT_VAD_DESC GetVad;
  54.                 D3DKMT_VA_RANGE_DESC GetVadRange;
  55.                 D3DKMT_GET_GPUMMU_CAPS GetGpuMmuCaps;
  56.                 D3DKMT_GET_PTE  GetPte;
  57.                 D3DKMT_GET_SEGMENT_CAPS GetSegmentCaps;
  58.             } DUMMYUNIONNAME;
  59.             D3DKMT_VAD_ESCAPE_COMMAND Command;      // in
  60.             NTSTATUS    Status;                     // out
  61.         } GetVads;
  62.         struct
  63.         {
  64.             ULONGLONG   LocalMemoryBudget;
  65.             ULONGLONG   SystemMemoryBudget;
  66.         } SetBudget;
  67.         struct
  68.         {
  69.             HANDLE hProcess;
  70.             BOOL bAllowWakeOnSubmission;
  71.         } SuspendProcess;
  72.         struct
  73.         {
  74.             HANDLE hProcess;
  75.         } ResumeProcess;
  76.         struct
  77.         {
  78.             UINT64 NumBytesToTrim;
  79.         } GetBudget;
  80.         struct
  81.         {
  82.             ULONG MinTrimInterval; // In 100ns units
  83.             ULONG MaxTrimInterval; // In 100ns units
  84.             ULONG IdleTrimInterval; // In 100ns units
  85.         } SetTrimIntervals;
  86.         D3DKMT_EVICTION_CRITERIA EvictByCriteria;
  87.         struct
  88.         {
  89.             BOOL bFlush;
  90.         } Wake;
  91.         struct
  92.         {
  93.             D3DKMT_DEFRAG_ESCAPE_OPERATION  Operation;
  94.  
  95.             UINT                            SegmentId;
  96.  
  97.             ULONGLONG                       TotalCommitted;
  98.             ULONGLONG                       TotalFree;
  99.             ULONGLONG                       LargestGapBefore;
  100.             ULONGLONG                       LargestGapAfter;
  101.         } Defrag;
  102.     } DUMMYUNIONNAME;
  103. } D3DKMT_VIDMM_ESCAPE;
  104.  
and that still isn't as bad as it can get, add some bitfields in there and there is plenty of fun to be had translating that to Pascal, particularly to versions of Pascal that, unlike FPC, don't support bitfields.
Title: Re: A suggestion for a new FPC feature
Post by: lucamar on June 23, 2019, 05:04:22 pm
I would like this feature too, if it had a clean syntax. I have missed it almost from my Pascal beginnings: implementing some of DOS structures (DPB, LoL, etc.) was a good eye-opener for this.


OT ... This will sound stupid and nitpicking but, please, use the correct "[code=whatever]" tags. Using "Pascal" highlighting for C code, for exampe, makes most code look like a comment, which (at least here) means decreased visibility.
Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on June 23, 2019, 05:26:04 pm
Ok, I should have added that arrays and unions reserve the space of the largest item. But they're still all the same size.

Code: Pascal  [Select]
  1. typedef struct {
  2.   GUID  PowerSetting;
  3.   DWORD DataLength;
  4.   UCHAR Data[1];
  5. } POWERBROADCAST_SETTING, *PPOWERBROADCAST_SETTING;

It stores a pointer to Data.

Yes, you can make variable-length "structures", but you have to store them in a different way. As a dynamic array, for example.
Title: Re: A suggestion for a new FPC feature
Post by: Almir.Bispo on June 23, 2019, 05:41:02 pm
The variable length in structure in Pascal shall be not a feature,but a BUG.
Please forget it.

(Please don't let C programmers work in FPC !!)
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on June 23, 2019, 06:12:09 pm
OT ... This will sound stupid and nitpicking but, please, use the correct "[code=whatever]" tags. Using "Pascal" highlighting for C code, for exampe, makes most code look like a comment, which (at least here) means decreased visibility.
I agree with you but, I don't see a "C" option in the list...  because of that, I picked Pascal.


Code: Pascal  [Select]
  1. typedef struct {
  2.   GUID  PowerSetting;
  3.   DWORD DataLength;
  4.   UCHAR Data[1];
  5. } POWERBROADCAST_SETTING, *PPOWERBROADCAST_SETTING;

It stores a pointer to Data.
No.  It doesn't store a pointer.  It stores the array of UCHAR directly in the structure.  The compiler doesn't know that there is (likely) more than 1 character stored in the last field which is the reason for the "DataLength" field.  That's the field that allows the programmer to use the correct array size at runtime.

The structure size varies but, the compiler sees it as a fixed size structure because it is being "lied" to by specifying [1] as the number of array elements.


The variable length in structure in Pascal shall be not a feature,but a BUG.
Please forget it.
Two things for you to realize: 1. that's not the feature I suggested.  2. variable length structures have long been available in Pascal (by lying to the compiler.)
Don't forget it.

(Please don't let C programmers work in FPC !!)
Don't worry, the majority of C programmers don't use FPC.  You're welcome.





Title: Re: A suggestion for a new FPC feature
Post by: Thaddy on June 23, 2019, 06:40:31 pm
Don't worry, the majority of C programmers don't use FPC.  You're welcome.
A large majority of Pascal programmers are also proficient in C........ Certainly the old hands
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on June 23, 2019, 06:53:27 pm
A large majority of Pascal programmers are also proficient in C........ Certainly the old hands
Yes, that is true. 

The thing about C programmers is that they are usually die-hards who won't use anything else unless it is strongly C "flavored".

Other programmers, such as Pascal programmers, usually get at least acquainted with the C language because it is very influential and because of that, it pays to be somewhat proficient in the language.

Title: Re: A suggestion for a new FPC feature
Post by: Kays on June 24, 2019, 04:14:40 pm
[…] allowing variants to appear anywhere and, in multiple places, in a record type. […]
Veto!

Putting the variant part at the end is the only sane conclusion. The year dot computers didn’t have a buttload of memory and worked considerably slower. The status quo is a good compromise between having bloated data structures (bad [if you allow it, you will have it]) and not having to mov data because the memory model has changed (good), as soon as the selected variant changes.
Title: Re: A suggestion for a new FPC feature
Post by: Thaddy on June 24, 2019, 04:22:11 pm
Putting the variant part at the end is the only sane conclusion.y model has changed (good), as soon as the selected variant changes.
No. not at all. size is known, There is no reason at all to not implement it. This is a very valid and serious request.
Would help to take some compiler classes..... O:-)
Title: Re: A suggestion for a new FPC feature
Post by: ASerge on June 24, 2019, 04:43:31 pm
It would very nice if that limitation was removed thus allowing variants to appear anywhere and, in multiple places, in a record type.
If I understand you correctly, then comparing the code on C:
Code: C  [Select]
  1. typedef struct TRec {
  2.   union
  3.   {
  4.     byte FieldA;
  5.     byte OrFieldB;
  6.   }
  7.   union
  8.   {
  9.     byte FieldC;
  10.     byte OrFieldD;
  11.   }
  12. }
  13. //...
  14. TRec rec;
  15. //...
  16. rec.FieldA = 1;
  17. rec.FieldC = 2;
with the similar code on Pascal:
Code: Pascal  [Select]
  1. type
  2.   TRec = record
  3.     DummyName1: record
  4.       case Byte of
  5.         0: (FieldA: Byte);
  6.         1: (OrFieldB: Byte);
  7.       end;
  8.     DummyName2: record
  9.       case Byte of
  10.         0: (FieldC: Byte);
  11.         1: (OrFieldD: Byte);
  12.       end;
  13.   end;
  14. //...
  15. var
  16.   Rec: TRec;
  17. //...
  18.   Rec.DummyName1.FieldA := 1;
  19.   Rec.DummyName2.FieldC := 2;
you want to syntactically exclude the names DummyNameX?
Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on June 24, 2019, 05:09:13 pm
Code: Pascal  [Select]
  1. typedef struct {
  2.   GUID  PowerSetting;
  3.   DWORD DataLength;
  4.   UCHAR Data[1];
  5. } POWERBROADCAST_SETTING, *PPOWERBROADCAST_SETTING;

It stores a pointer to Data.
No.  It doesn't store a pointer.  It stores the array of UCHAR directly in the structure.  The compiler doesn't know that there is (likely) more than 1 character stored in the last field which is the reason for the "DataLength" field.  That's the field that allows the programmer to use the correct array size at runtime.

The structure size varies but, the compiler sees it as a fixed size structure because it is being "lied" to by specifying [1] as the number of array elements.

Interesting. That does sound very Microsoft. I would strongly prefer not to have something like that in fpc.
Title: Re: A suggestion for a new FPC feature
Post by: lucamar on June 24, 2019, 07:25:30 pm
Interesting. That does sound very Microsoft. I would strongly prefer not to have something like that in fpc.

But you do have something like that in Pascal:
Code: Pascal  [Select]
  1. TVariableRecord = record
  2.   Size: Integer;
  3.   Data: array [0..0] of byte;
  4. end;
:o
Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on June 24, 2019, 07:41:00 pm
And how do I put data in Data? SetLength doesn't work.

I don't really believe it.
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on June 24, 2019, 07:50:21 pm
Interesting. That does sound very Microsoft. I would strongly prefer not to have something like that in fpc.
Microsoft isn't the only one who has used that "feature".  It's not what could be characterized as common but, it isn't really rare either.   

It's a lot of "fun" when not only the field size varies but the semantics of the field - including its data type - vary depending on the value of some other variable in the structure/record.   Basically a record whose variant is "squeezed" to fit each type.

It's more something of a C programmer's thing than a Microsoft thing.

Programmers always find ways to abuse a feature. <chuckle>  I suspect that's what's made the C language popular.

Going back to the topic of the thread, removing the restriction that a variant must be the last field in a record and allowing multiple variants in a record would really ease porting C data structures to Pascal.  We live in a C world whether we like it or not.

ETA:

And how do I put data in Data? SetLength doesn't work.

I don't really believe it.
you load data in that field the same way you load data into an array (the field is an array), you're simply not respecting the array bounds (whatever they may be) and, since you are ignoring the declared array bounds, you need to either manually, set the count of elements or the size in bytes, into some variable dedicated to hold it for the structure to be usable.

Believe or not... and it's not Ripley's, it's Pascal (and C, C++ and quite a few other languages that implement that "trick".)
Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on June 24, 2019, 07:58:10 pm
So, you malloc() a buffer, memcpy() the record into it, and then manage everything yourself? Like increasing the pointer to the right location?

You don't need the record for that. It has no purpose.

Edit: and make sure to turn off any range or bounds checking. Yes, C. Not Pascal.
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on June 24, 2019, 08:09:02 pm
So, you malloc() a buffer, memcpy() the record into it, and then manage everything yourself? Like increasing the pointer to the right location?

You don't need the record for that. It has no purpose.
You're getting the idea... it is almost always used with dynamically allocated memory.  It definitely has a purpose, when the size of the array can vary a significant amount and the program needs to keep track of many such records, it is very useful.

For instance, if you write a text editor with an "undo" feature (good feature to have in a text editor), you can have the fixed part of the record describe the memory block it applies to, its sequence and whatever should be put back when the "undo" function is carried out (that part obviously varies in size.) Having every potential undo action neatly packaged in its own variable length record is a much better solution than keeping a pointer to the undo data in the record (the reason is because, using a pointer to another block means there could be a very significant amount of fragmentation.)

Anytime you want to lessen memory fragmentation, records of that kind are good candidates.
Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on June 24, 2019, 08:28:36 pm
If you want to program like that, I would suggest using assembler or C.
Title: Re: A suggestion for a new FPC feature
Post by: lucamar on June 24, 2019, 08:55:48 pm
If you want to program like that, I would suggest using assembler or C.

It is not usually a question of "want" but of "need". As a Pascal programmer I love having everytihng as neat and tidy and elegant as possible. But sometimes the real world  insists on intruding with these frankly outrageous demands and, isn't it nice that if you need it you have this kind of features available? :)
Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on June 25, 2019, 01:43:29 am
No. I don't agree. There are always many good ways to do something.

Every project I do is custom and completely different from all my previous ones. I'll adjust and use what the others that cannot have to use.

It's not that I didn't try other things than Object Pascal, most of the time I use something else. I like Object Pascal because it is the most dependable. It won't try to get me to shoot in my own foot. It still works 10 years later.

If you're young, you try to outsmart the others by coming up with border cases that are hard to understand, but work. If you become older, you want things to be understandable.

And not in the first place for me. I'm smart enough to figure it out. But for everyone else.
Title: Re: A suggestion for a new FPC feature
Post by: lucamar on June 25, 2019, 05:01:57 am
If you're young, you try to outsmart the others by coming up with border cases that are hard to understand, but work. If you become older, you want things to be understandable.

I'm not so young as I used to be and I don't fell the need to outsmart anybody. Just to write the best code I can, with all it means in terms of speed, accuracy and maintainability.

But sometimes those border cases come to you, whether you like them or not, and the best solution one can find is not exactly "by the book". In those, admitedly few, cases it's good that the language, and the compiler, you're using can cope with your solution.

Yes, there are always many ways to do something. The problem really is deciding which is the "good" one. And sometimes the "good" one is not the "easy, easily undertood" one.

In the cases I were referring to? You either "cheat" by ignoring array limits or start handling pointers like mad. Frankly, I prefer to "cheat" with the array and let pointers and pointer math for when they are really needed. And, of course, comment in the source what I'm doing and why.

But we'll have to agree to disagree, I fear.
Title: Re: A suggestion for a new FPC feature
Post by: trev on June 25, 2019, 06:42:54 am
FWIW, as an old and retired C programmer I agree with lucamar. Nice to have, maybe not essential.
Title: Re: A suggestion for a new FPC feature
Post by: PascalDragon on June 25, 2019, 09:20:48 am
If you want to program like that, I would suggest using assembler or C.
This has nothing to do with wanting to program like that, but needing to program like that, because such constructs are required to interact with the Windows API.

So, you malloc() a buffer, memcpy() the record into it, and then manage everything yourself? Like increasing the pointer to the right location?

You don't need the record for that. It has no purpose.
That's not how it usually works.

Let's take the example of POWERBROADCAST_SETTING given above. Assume there exists the following function (don't know right now how the real one is defined, but it's enough for the example):
Code: Pascal  [Select]
  1. function GetPowerBroadcastSetting(aSetting: PPOWERBROADCAST_SETTING; out aLen: DWORD): BOOL;
You then typically use it like this:
Code: Pascal  [Select]
  1. var
  2.   setting: PPOWERBROADCAST_SETTING;
  3.   i, len: DWORD;
  4. begin
  5.   if not GetPowerBroadcastSetting(Nil, len) then
  6.     Exit;
  7.   setting := PPOWERBROADCAST_SETTING(GetMem(len));
  8.   if not GetPowerBroadcastSetting(setting, len) then begin
  9.     FreeMem(setting);
  10.     Exit;
  11.   end;
  12.   for i := 0 to setting^.DataLength - 1 do
  13.     Write(IntToHex(setting^.Data[i], 2), ' ');
  14. end.
This is just an example, but that's essentially how such constructs are used.

Don't forget that a Pascal program isn't isolated by itself, but interacts with the surrounding operating system and thus it needs to interact with the APIs of that (and it's much easier to simply point someone to MSDN than to explain and let them use the C examples then having to explain how that structure needs to be used compared to that other one).
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on June 25, 2019, 09:49:43 am
First, I apologize for the late reply.  Somehow I missed -- some of -- the replies in this thread...

@Serge,

with the similar code on Pascal:

Code: Pascal  [Select]
  1. type
  2.   TRec = record
  3.     DummyName1: record
  4.       case Byte of
  5.         0: (FieldA: Byte);
  6.         1: (OrFieldB: Byte);
  7.       end;
  8.     DummyName2: record
  9.       case Byte of
  10.         0: (FieldC: Byte);
  11.         1: (OrFieldD: Byte);
  12.       end;
  13.   end;
  14. //...
  15. var
  16.   Rec: TRec;
  17. //...
  18.   Rec.DummyName1.FieldA := 1;
  19.   Rec.DummyName2.FieldC := 2;
you want to syntactically exclude the names DummyNameX?
Personally, I believe the union/variant names should always be required.  I am not fond of unnamed/anonymous unions.  What you suggested looks good to me, of course, I would rather see more descriptive names being used for the variants but, as we all know, no compiler can enforce that. ;)


ETA:

Don't forget that a Pascal program isn't isolated by itself, but interacts with the surrounding operating system and thus it needs to interact with the APIs
That's what it really is all about. 
Title: Re: A suggestion for a new FPC feature
Post by: Thaddy on June 25, 2019, 10:47:03 am
First, I apologize for the late reply.  Somehow I missed -- some of -- the replies in this thread...

@Serge,

with the similar code on Pascal:

Code: Pascal  [Select]
  1. type
  2.   TRec = record
  3.     DummyName1: record
  4.       case Byte of
  5.         0: (FieldA: Byte);
  6.         1: (OrFieldB: Byte);
  7.       end;
  8.     DummyName2: record
  9.       case Byte of
  10.         0: (FieldC: Byte);
  11.         1: (OrFieldD: Byte);
  12.       end;
  13.   end;
  14. //...
  15. var
  16.   Rec: TRec;
  17. //...
  18.   Rec.DummyName1.FieldA := 1;
  19.   Rec.DummyName2.FieldC := 2;
you want to syntactically exclude the names DummyNameX?
Personally, I believe the union/variant names should always be required.  I am not fond of unnamed/anonymous unions.  What you suggested looks good to me, of course, I would rather see more descriptive names being used for the variants but, as we all know, no compiler can enforce that. ;)


ETA:

Don't forget that a Pascal program isn't isolated by itself, but interacts with the surrounding operating system and thus it needs to interact with the APIs
That's what it really is all about.

That's more or less what I meant.
You can expand this with a liitle macro, so the "union" becomes quite understandable:
Code: Pascal  [Select]
  1. {$mode objfpc}{$macro on}{$Define union :=}
  2. type
  3.   TRec = record
  4.     DummyName1: record
  5.       union case Byte of
  6.         0: (FieldA: Byte);
  7.         1: (OrFieldB: longword);
  8.       end;
  9.     DummyName2: record
  10.       union case Byte of
  11.         0: (FieldC: longint);
  12.         1: (OrFieldD: Byte);
  13.       end;
  14.   end;
  15. begin
  16. end.

Title: Re: A suggestion for a new FPC feature
Post by: 440bx on June 25, 2019, 12:07:27 pm
Code: Pascal  [Select]
  1. {$mode objfpc}{$macro on}{$Define union :=}
  2. type
  3.   TRec = record
  4.     DummyName1: record
  5.       union case Byte of
  6.         0: (FieldA: Byte);
  7.         1: (OrFieldB: longword);
  8.       end;
  9.     DummyName2: record
  10.       union case Byte of
  11.         0: (FieldC: longint);
  12.         1: (OrFieldD: Byte);
  13.       end;
  14.   end;
  15. begin
  16. end.

That looks good... another possibility that comes to mind would be to directly replace "record" with "union".  Using your example, the result would look like this:
Code: Pascal  [Select]
  1. type
  2.   TRec = record
  3.     DummyName1: union
  4.       case Byte of
  5.         0: (FieldA: Byte);
  6.         1: (OrFieldB: longword);
  7.       end;
  8.     DummyName2: union
  9.       case Byte of
  10.         0: (FieldC: longint);
  11.         1: (OrFieldD: Byte);
  12.       end;
  13.   end;
  14. begin
  15. end.
Of course, that presumes a new "union" keyword would be added to the language.
Title: Re: A suggestion for a new FPC feature
Post by: Thaddy on June 25, 2019, 01:07:25 pm
 :D Looks even better... 8-)
Doesn't need to be added: to the language perse:
Code: Pascal  [Select]
  1. {$macro on}{$define union:=record}

But anyway: I think my syntax is more clear, because it identifies union members of records as union, with the possibility to add non-union members.
After all, unions are part of a record. Unless - what I wrote - they are declared first and are strict variant records to be used as members in subsequent records.

That's basically how I always do it, with the exception of that little eye candy macro.... :P

You really can construct a 1-1 memory lay-out compared to C syntax, although more verbose, which is good. That has always been the case.
Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on June 25, 2019, 01:19:09 pm
PChar and dynamic arrays are stored in memory with a 32-bit integer at [-1] that denotes the actual length. For PChar that is invisible, as their length should be decided by the first #0 char. But that means that the compiler can treat a PChar as a regular one.

So, a struct like this:

Code: C  [Select]
  1. typedef struct {
  2.   GUID  PowerSetting;
  3.   DWORD DataLength;
  4.   UCHAR Data[1];
  5. }

is actually how you would convert a dynamic Pascal array to C...  :o


For comparison, the last large project I worked on (bug fixing) was written in C++, and fully static. No dynamic memory at all. There was this huge struct filled with other nested structs, that was written as-is from memory to disk and vice versa. Just save 1 record of size sizeof() to disk, or take the global pointer and load that amount of bytes into it. Oh, yes, did I mention that everything was defined globally?

And with each new version , new stuff was added. To the end of the file, of course. And if you changed any of the record packing settings, everything stopped working. You couldn't actually reference any of the structs inside, as their location and size was defined by the version of the program. It was a lot of fun making bugfixes for that...

And all of you say: "Well, of course that should be possible to do in FPC as well, because some programs work like that and we should be able to communicate with that." Instead of the sane approach: writing in/export functions.
Title: Re: A suggestion for a new FPC feature
Post by: Thaddy on June 25, 2019, 01:45:14 pm
That is simply not correct SymbolicFrank,

A C union size is determined - as I already explained - by its largest member.
That's what we are talking about: the union does not even contain a length size.....

See https://en.wikipedia.org/wiki/Union_type
Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on June 25, 2019, 02:08:19 pm
That is simply not correct SymbolicFrank,

A C union size is determined - as I already explained - by its largest member.
That's what we are talking about: the union does not even contain a length size.....

See https://en.wikipedia.org/wiki/Union_type

What I wrote is correct, and it wasn't in response to something you said. It wasn't about unions, either.
Title: Re: A suggestion for a new FPC feature
Post by: PascalDragon on July 02, 2019, 09:45:43 am
PChar and dynamic arrays are stored in memory with a 32-bit integer at [-1] that denotes the actual length. For PChar that is invisible, as their length should be decided by the first #0 char. But that means that the compiler can treat a PChar as a regular one.

So, a struct like this:

Code: C  [Select]
  1. typedef struct {
  2.   GUID  PowerSetting;
  3.   DWORD DataLength;
  4.   UCHAR Data[1];
  5. }

is actually how you would convert a dynamic Pascal array to C...  :o

You're wrong. PChar does not have any length at the front, it's simply a pointer to a memory with characters with the first #0 denoting the end.
Just take a look at this:
Code: Pascal  [Select]
  1. var
  2.   Test: PChar = 'Blubb';
  3. begin
  4. end.
The corresponding assembly code looks like this:
Code: [Select]
.section .rodata.n_.Ld1,"d"
.balign 8
.Ld1:
# [24] Test: PChar = 'Blubb';
.ascii "Blubb\000"

Also dynamic arrays contain not the length, but the high index as well as a reference count. And if you put a dynamic array into a record the record will only contain a reference to that dynamic array, not the dynamic array itself, so the structure you quoted is not a 1:1 equivalent to
Code: Pascal  [Select]
  1. TMyRecord = record
  2.   PowerSetting: TGUID;
  3.   Data: array of UCHAR;
  4. end;
Title: Re: A suggestion for a new FPC feature
Post by: marcov on July 02, 2019, 11:00:43 am
I'd be careful to expand on anonymous functions. It is very limited.

It is one of the few pascal features that regularly bite me.

A typical template that goes wrong is:

Code: Pascal  [Select]
  1. procedure  tsomethread.queueit(const msgtypes : array of integer);
  2. var msg : Tsomemessage;
  3.      i :integer;
  4. begin
  5.   for i:=0 to high(msgtypes) do
  6.      begin
  7.         msg:=translate(msgtypes[i]);
  8.         queue(procedure
  9.                     begin
  10.                      callwithmessasage (msg);
  11.                    end
  12.                  );
  13.      end;
  14. end;
  15.  
  16.  

Can you spot the problem?
Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on July 02, 2019, 12:53:16 pm
Ok, I'll bite. I got the other stuff wrong, so I probably don't get this one either.

Msg is in scope. On the one hand, the variable msg changes every loop, but on the other hand the parameter msg should be copied. As the anonymous function isn't executed immediately, it stores msg as a field, according to the explanation of PascalDragon, and the procedure is stored in queue for later use. So they should all have their own copy.

I don't see it.
Title: Re: A suggestion for a new FPC feature
Post by: marcov on July 02, 2019, 01:20:36 pm
Ok, I'll bite. I got the other stuff wrong, so I probably don't get this one either.

Msg is in scope. On the one hand, the variable msg changes every loop, but on the other hand the parameter msg should be copied. As the anonymous function isn't executed immediately, it stores msg as a field, according to the explanation of PascalDragon, and the procedure is stored in queue for later use. So they should all have their own copy.

I don't see it.

That is what you would expect indeed, but not how it works, a reference to msg is stored, not msg itself. This can be changed by making msg a parameter to the anonymous function, but then that doesn't match the signature of queue(). And queue (and synchronize to a less degree, I hardly use that nowadays) are my main usecase for anonymous functions.

Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on July 02, 2019, 01:41:09 pm
Ah, yes, it's not a parameter of the anonymous function, but of the called function.

Things like this are why I always try to program as I would in Pascal, no matter the language. If my co-workers allow it, of course.
Title: Re: A suggestion for a new FPC feature
Post by: PascalDragon on July 03, 2019, 01:54:19 pm
Ok, I'll bite. I got the other stuff wrong, so I probably don't get this one either.

Msg is in scope. On the one hand, the variable msg changes every loop, but on the other hand the parameter msg should be copied. As the anonymous function isn't executed immediately, it stores msg as a field, according to the explanation of PascalDragon, and the procedure is stored in queue for later use. So they should all have their own copy.

I don't see it.
The internal state object is shared for all anonymous functions created inside a function. So they all will have the same reference to msg.

I'd be careful to expand on anonymous functions. It is very limited.

It is one of the few pascal features that regularly bite me.

A typical template that goes wrong is:

Code: Pascal  [Select]
  1. procedure  tsomethread.queueit(const msgtypes : array of integer);
  2. var msg : Tsomemessage;
  3.      i :integer;
  4. begin
  5.   for i:=0 to high(msgtypes) do
  6.      begin
  7.         msg:=translate(msgtypes[i]);
  8.         queue(procedure
  9.                     begin
  10.                      callwithmessasage (msg);
  11.                    end
  12.                  );
  13.      end;
  14. end;
  15.  
  16.  

Can you spot the problem?
That was another thing I wanted to experiment with using the lambda syntax: have variables by default be copies instead of references and have references declared explicitly like this:
Code: Pascal  [Select]
  1. lambda (...) with var x as inc(x)
The with ... clause could be used to declare variables as by reference instead of by value.
Title: Re: A suggestion for a new FPC feature
Post by: Martin_fr on July 03, 2019, 02:45:48 pm
That was another thing I wanted to experiment with using the lambda syntax: have variables by default be copies instead of references and have references declared explicitly like this:
Code: Pascal  [Select]
  1. lambda (...) with var x as inc(x)
The with ... clause could be used to declare variables as by reference instead of by value.

IMHO The lambda syntax is so not Pascal.

Personally I am contra the whole inline declaration. But if needs must be...

1) About copy vs ref
My proposal:
Code: Pascal  [Select]
  1. queue(
  2.   procedure
  3.   var msg: string = msg;
  4.   begin
  5.     callwithmessasage (msg);
  6.   end
  7. );
  8.  
Using entirely existing syntax.
"msg" in the right hand expression of the var block, refers to the outer "msg".

2)  Just because every other language forgets to distinguish between a "closure" and an "inline declaration", do we need to do the same? After all Pascal is about expressing things more clearly.
A closure (no matter if declared inline, or as a nested proc) should be marked as such by an appropriate keyword/modifier.
Title: Re: A suggestion for a new FPC feature
Post by: marcov on July 03, 2019, 03:10:16 pm
I don't like the lamba either (and the inferring of variables even less).

But the trouble is indeed that the delphi syntax only allows to specify how to catch variables by making them parameters, but that hits the signature.  Syntax wise, some way to mark values are byvalue would be enough, and martin's syntax is not bad.
Title: Re: A suggestion for a new FPC feature
Post by: fcu on July 03, 2019, 04:54:03 pm
off topic  :-\
i was always confusing about the range declaration in the array
in c it looks resonable
Code: C  [Select]
  1.  #define ARRAY_MAX 16
  2.  int int_array[ARRAY_MAX]
  3.  
i hope fpc team think about it
Code: Pascal  [Select]
  1. const ARRAY_MAX = 16;
  2. var int_array : array[ARRAY_MAX] of longint; // looks nice without 0 and ARRAY_MAX-1
  3.  

Title: Re: A suggestion for a new FPC feature
Post by: howardpc on July 03, 2019, 05:41:48 pm
In Pascal you can of course write
Code: Pascal  [Select]
  1. const
  2.   ArrayHigh = 15;
  3. type
  4.   TArrayRange = 0..ArrayHigh;
  5. var
  6.   int_array: array[TArrayRange] of LongInt;
Title: Re: A suggestion for a new FPC feature
Post by: fcu on July 03, 2019, 06:25:01 pm
In Pascal you can of course write
Code: Pascal  [Select]
  1. const
  2.   ArrayHigh = 15;
  3. type
  4.   TArrayRange = 0..ArrayHigh;
  5. var
  6.   int_array: array[TArrayRange] of LongInt;

but it becomes worse
i talking about less typing
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on July 03, 2019, 06:56:17 pm
but it becomes worse
i talking about less typing
Programming isn't about typing less, it's about writing code that is easy to understand and maintain.

simple fiddling with the above example
Code: Pascal  [Select]
  1. type
  2.   ARRAY_RANGE = 0..15;
  3.  
  4. var
  5.   SomeArray[ARRAY_RANGE] of <whatever you want here>;
  6.  
  7. begin
  8. ...
  9.   for I in ARRAY_RANGE do <again whatever you want>
  10. end;
  11.  

it sure beats the rather deficient junk C programmers have to write
Code: Pascal  [Select]
  1. #define ARRAY_ELEMENT_COUNT 16
  2. int TheArray[ARRAY_ELEMENT_COUNT];
  3. for (I = 0; I < ARRAY_ELEMENT_COUNT; I++)
Not only is that a whole lot of typing, it is far from being as easy to understand and maintain.

NOTE: the post editor automatically uppercases the letter I (that would not be welcome in a real C program.)

and if for some reason you need the count of elements in the array a simple const after the type declaration does it
Code: Pascal  [Select]
  1. const
  2.   ARRAY_COUNT = high(ARRAY_RANGE) - low(ARRAY_RANGE) + 1;

Combine the above with enumerated types (no 0 thru 15 but <somename> .. <someothername>) when applicable and you can write crystal clear code.

ETA:

The problem is that writing code that is easy to read and understand doesn't make the programmer look "hard core" and, that, seems very important to some programmers (a lot of them love Perl.)
Title: Re: A suggestion for a new FPC feature
Post by: devEric69 on July 03, 2019, 07:13:26 pm
Quote
Programming isn't about typing less [SNIP]

Just a relative: I don't really agree with this statement, because the less you type, the less precise the thought and therefore its subsequent understanding or re-reading is, so understandable...
For a programming language, a strong typing is therefore an strong advantage, that should not "fade away" behind less to write for a new grammar change (the proof by the absurd: we can very well only use a unique global variable of the variant type, but it quickly becomes incomprehensible; less ancient languages, like Php, are becoming more typified, precisely to "gain in semantics").
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on July 03, 2019, 07:25:35 pm
Just a relative: I don't really agree with this statement, because the less you type, the less precise the thought and therefore its subsequent understanding or re-reading is, so understandable...
It seems to me you are contradicting your own point.  Precision and accuracy very often require additional typing to increase them and, since programming is about precision and accuracy (among other things), it follows that the goal isn't to type less but to enhance and extend the number of mechanisms the language provides for the programmer to achieve greater precision and accuracy.


Title: Re: A suggestion for a new FPC feature
Post by: devEric69 on July 03, 2019, 07:31:57 pm
Okay, re-phrase like that, I agree :) .
Title: Re: A suggestion for a new FPC feature
Post by: marcov on July 03, 2019, 07:45:03 pm
off topic  :-\
i was always confusing about the range declaration in the array
in c it looks resonable

Yeah, I  always also feel very limited in having to forcedly start arrays at 0 in C. It looks reasonable, but it is limitations forced on you. C's form of  bondage and discipline.
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on July 03, 2019, 08:43:50 pm
Okay, re-phrase like that, I agree :) .
Good :)  I thought we agreed.


Yeah, I  always also feel very limited in having to forcedly start arrays at 0 in C. It looks reasonable, but it is limitations forced on you. C's form of  bondage and discipline.
Starting at an index different than zero can really complicate pointer arithmetic which is quite common in C (and just as common in Pascal depending on what you're doing.)

I rarely use a low bound different than zero - even in Pascal - for that very reason.  That way expressions that calculate an offset in memory can directly use the zero based array index to compute displacements instead of adjusting the index by - low(array)


Title: Re: A suggestion for a new FPC feature
Post by: SymbolicFrank on July 03, 2019, 09:41:05 pm
The problem is that writing code that is easy to read and understand doesn't make the programmer look "hard core" and, that, seems very important to some programmers (a lot of them love Perl.)

Yes, but even simpler: if I was too cryptic or quick-and-dirty, and they ask me a year later to make some changes, I don't understand it myself.
Title: Re: A suggestion for a new FPC feature
Post by: marcov on July 03, 2019, 09:51:13 pm
Starting at an index different than zero can really complicate pointer arithmetic which is quite common in C (and just as common in Pascal depending on what you're doing.)

Well avoiding pointers is hard, because that is the way of C. Even for something as simple as a by reference parameter.

A lot of it would be unnecessary with a mature language, and then also the limitation seems artificial.

Quote
I rarely use a low bound different than zero - even in Pascal - for that very reason.  That way expressions that calculate an offset in memory can directly use the zero based array index to compute displacements instead of adjusting the index by - low(array)

Not daily. Most of my arrays start with zero. But I wouldn't want to be forced to do that. Arrays for subranges of enums are an example.
Title: Re: A suggestion for a new FPC feature
Post by: PascalDragon on July 04, 2019, 09:39:42 am
But the trouble is indeed that the delphi syntax only allows to specify how to catch variables by making them parameters, but that hits the signature.  Syntax wise, some way to mark values are byvalue would be enough, and martin's syntax is not bad.
I'm definitely open to suggestions here though I don't think that "overloading" variable initialization with that is a good idea (especially if - as the example shows - both the inner and outer scope variable share the same name). Introducing a with section wouldn't be that unpascalish though as it can be nicely read from left to right:
Code: Pascal  [Select]
  1. queue(
  2.   procedure
  3.   with msg // by value
  4.   //with msg as var // by ref (default)
  5.   begin
  6.     callwithmessasage (msg);
  7.   end
  8. );
Okay, the with msg as var would conflict with a following var section, but similar to this syntax (maybe with var msg like for parameter declarations?)...
Title: Re: A suggestion for a new FPC feature
Post by: marcov on July 04, 2019, 09:52:35 am
Fine with me. The initialized constant is maybe to ambiguous, since Delphi doesn't do initial local vars.
Title: Re: A suggestion for a new FPC feature
Post by: Zoran on July 04, 2019, 10:48:18 am
NOTE: the post editor automatically uppercases the letter I (that would not be welcome in a real C program.)

For C code, you should use tag [code=C], not [code=Pascal]. Let's see the difference and whether i is uppercased:

Code: C  [Select]
  1. #define ARRAY_ELEMENT_COUNT 16
  2. int TheArray[ARRAY_ELEMENT_COUNT];
  3. for (i = 0; i < ARRAY_ELEMENT_COUNT; i++)

comparing to [code=Pascal]
Code: Pascal  [Select]
  1. #define ARRAY_ELEMENT_COUNT 16
  2. int TheArray[ARRAY_ELEMENT_COUNT];
  3. for (i = 0; i < ARRAY_ELEMENT_COUNT; i++)

Edit:
i is not uppercased, not even with [code=Pascal], I don't know how it happened to you.
Anyway, mark C code as C, not Pascal.
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on July 04, 2019, 11:33:52 am
For C code, you should use tag [code=C], not [code=Pascal].
I normally use the "code" dropdown and, at least on my machine, it doesn't offer a "C" option.

It works when setting the option manually but I didn't know that "C" was a valid option since it's not found in the dropdown. It doesn't automatically uppercase i, that is nice! :)

Code: C  [Select]
  1. #define ARRAY_ELEMENT_COUNT 16
  2. int TheArray[ARRAY_ELEMENT_COUNT];
  3. for (i = 0; i < ARRAY_ELEMENT_COUNT; i++)
^ yup, that worked.

Thank you @Zoran, that is definitely an improvement.


Title: Re: A suggestion for a new FPC feature
Post by: Martin_fr on July 04, 2019, 12:47:21 pm
I normally use the "code" dropdown and, at least on my machine, it doesn't offer a "C" option.
There is a C option.


... Well now there is. Just added.
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on July 04, 2019, 01:23:52 pm
... Well now there is. Just added.
Excellent!... thank you. :)
Title: Re: A suggestion for a new FPC feature
Post by: lucamar on July 04, 2019, 01:26:46 pm
OffTopic, but ...

Martin, is there some place where we can see which highlighters are installed in the forum?
Title: Re: A suggestion for a new FPC feature
Post by: Handoko on July 04, 2019, 01:37:52 pm
where we can see which highlighters are installed in the forum?
Title: Re: A suggestion for a new FPC feature
Post by: Zoran on July 04, 2019, 01:41:55 pm

@Handoko, Lucamar wants to know about those not listed in this combo box, but supported.

OffTopic, but ...

Martin, is there some place where we can see which highlighters are installed in the forum?

Let's try a few:
[code=C++]  -- automatically replaced by C
Code: C  [Select]
  1.  

[code=C#]  -- automatically replaced by C
Code: C  [Select]
  1.  

[code=Java] -- suported!
Code: Java  [Select]
  1.  

It seems that "C++" and "C#" are automatically replaced with "C".
On the other hand, "Java" is recognized.

Martin, would you add "Java" to the combobox, please.
Title: Re: A suggestion for a new FPC feature
Post by: Handoko on July 04, 2019, 01:44:05 pm
Oh, I'm sorry. I didn't read the whole thread.
Title: Re: A suggestion for a new FPC feature
Post by: lucamar on July 04, 2019, 01:57:06 pm
Oh, I'm sorry. I didn't read the whole thread.

No problem, don't worry.

It's just that this happened another time, only IIRC that time the poster was using [code=pascal] for C code; as is obvious that tends to render most of the code as if it were a comment. Having a place to look for all the valid highlight modifiers would ... maybe not prevent it, but help correct it. And it would be a nice addition to the "Forum" article in the wiki :)
Title: Re: A suggestion for a new FPC feature
Post by: ASerge on July 04, 2019, 03:09:17 pm
Continue offtopic. The assembler is also recognized:
Code: ASM  [Select]
  1. mov  eax, edx
  2. jmp  @@L1 ; Comment

Title: Re: A suggestion for a new FPC feature
Post by: 440bx on July 04, 2019, 03:16:48 pm
It's just that this happened another time, only IIRC that time the poster was using [code=pascal] for C code; as is obvious that tends to render most of the code as if it were a comment.
I remember that! <chuckle>  at the time, I pointed out that I agreed with you, I didn't know the options in the dropdown did not include all the languages the formatter can handle.  That's why I used Pascal for C.

It's definitely nicer when using the format that is for the target language.
Title: Re: A suggestion for a new FPC feature
Post by: Martin_fr on July 04, 2019, 04:08:26 pm
OffTopic, but ...
Martin, is there some place where we can see which highlighters are installed in the forum?
We have GeSHi installed. ( https://codebirth.com/index.php?topic=81.0 )

The "[Select]" is copied js from IIRC the built-in code.
And some other fine tuning, so copy and paste works from most browsers...

I added asm and Java too. (Though I really do not know why we need the latter)
Title: Re: A suggestion for a new FPC feature
Post by: marcov on July 04, 2019, 04:16:14 pm
I added asm and Java too. (Though I really do not know why we need the latter)

Android/ppcjvm
Title: Re: A suggestion for a new FPC feature
Post by: Zoran on July 04, 2019, 10:53:03 pm
I added asm and Java too. (Though I really do not know why we need the latter)

Android/ppcjvm

Or someone might want to show some java code, when asking how to do it in Pascal.
I just assumed that, when any programming language is already supported by forum highlighter, it is good to have it listed there.

OffTopic, but ...
Martin, is there some place where we can see which highlighters are installed in the forum?
We have GeSHi installed. ( https://codebirth.com/index.php?topic=81.0 )

There I found the link to list of supported languages (https://www.mediawiki.org/wiki/Extension:SyntaxHighlight#Supported_languages)

So, perhaps too many for the combo box, but perhaps this link should be put somewhere.
Title: Re: A suggestion for a new FPC feature
Post by: lucamar on July 05, 2019, 12:12:21 am
There I found the link to list of supported languages (https://www.mediawiki.org/wiki/Extension:SyntaxHighlight#Supported_languages)

So, perhaps too many for the combo box, but perhaps this link should be put somewhere.

I'll add it to that wiki page. Thanks Zoran!

ETA: Done! See: Forum (https://wiki.freepascal.org/Forum).

I was going to copy/paste the full list but it's too long! Instead I just added the link; we'll see how much time it stays unbroken :)
Title: Re: A suggestion for a new FPC feature
Post by: GAN on July 05, 2019, 02:45:33 am
Starting at an index different than zero can really complicate pointer arithmetic which is quite common in C (and just as common in Pascal depending on what you're doing.)

Well avoiding pointers is hard, because that is the way of C. Even for something as simple as a by reference parameter.

A lot of it would be unnecessary with a mature language, and then also the limitation seems artificial.

Quote
I rarely use a low bound different than zero - even in Pascal - for that very reason.  That way expressions that calculate an offset in memory can directly use the zero based array index to compute displacements instead of adjusting the index by - low(array)

Not daily. Most of my arrays start with zero. But I wouldn't want to be forced to do that. Arrays for subranges of enums are an example.

I use a lot of arrays that starts with one, for example array of months 1..12 it's better than 0..11. Also in arrays that have codes wich starts from 1. It's very usefull.
Title: Re: A suggestion for a new FPC feature
Post by: 440bx on July 05, 2019, 03:38:40 am
I use a lot of arrays that starts with one, for example array of months 1..12 it's better than 0..11. Also in arrays that have codes wich starts from 1. It's very usefull.
No doubt.  There are times when being able to start at something other than zero can be useful and clear.  Keeping track of Months is a good example of that since, by convention, January is month 1 not 0.
Title: Re: A suggestion for a new FPC feature
Post by: PascalDragon on July 05, 2019, 09:40:37 am
Fine with me. The initialized constant is maybe to ambiguous, since Delphi doesn't do initial local vars.
Hey, we more or less agreed on a language extension! I should probably mark that in a calendar. :P
Title: Re: A suggestion for a new FPC feature
Post by: marcov on July 05, 2019, 10:01:58 am
Fine with me. The initialized constant is maybe to ambiguous, since Delphi doesn't do initial local vars.
Hey, we more or less agreed on a language extension! I should probably mark that in a calendar. :P

One that Delphi doesn't have!.  Sure, just mark 05-07-2024, and remind me it is time for the next one by then  O:-)