Recent

Author Topic: Does Freepascal has everything "must have" functional features as C does  (Read 2833 times)

PeterHu

  • New member
  • *
  • Posts: 6
Greetings!

Speaking to FPC3.0,just want to know whether freepascal has everything "must have" as those features in C?And how about pointers in fpc,it has the same strong ability as C,let's say in a system programming environment.

I am not tending to leading a language war,rather,just expecting everything C can do freepascal can do as well and nothing "must have" features is missing in Freepascal.

Best Regards,
Peter

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10301
  • FPC developer.

No parameterized macros and no ? operator. But those are not really must haves, and (Object) Pascal provides so much more.....

MarkMLl

  • Hero Member
  • *****
  • Posts: 5233

No parameterized macros and no ? operator. But those are not really must haves...

Arguable.

Different semantics of the case/switch statement, but equivalence can be fudged. Different build system, i.e. no in-depth support for make.

Very strong support for string and dynamic array handling, at the cost of having compiler-generated finalisation blocks to do housekeeping.

Implementation- and platform-specific: limited (at present) attribute support, making it difficult to e.g. specify which section a variable or routine goes into.

Comparing it with other systems languages: no support for coroutine switching at the language level.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10301
  • FPC developer.

No parameterized macros and no ? operator. But those are not really must haves...

Arguable.

Anything opinion based is arguable.

Quote
Different semantics of the case/switch statement, but equivalence can be fudged.

I never considered the broken C switch that defaults to fall-through a "feature".  Even if you consider fall-through itself a feature (I don't, at least not with a modern perspective), it should never have been default nor mixed with normal switch/case usage, too error prone.

Quote
Different build system, i.e. no in-depth support for make.

Having an actually functioning build-in build system rather than having none in the standard and relying on external tools calling platform dependent tools. Keep in mind that even if you step over make not being standard, even then the oft fabled parallelization of make often only gains back some of the time spent on header reparsing.

Quote
Comparing it with other systems languages: no support for coroutine switching at the language level.

Standard or language? What is the language level in M2 ?
« Last Edit: August 08, 2022, 03:50:15 pm by marcov »

MarkMLl

  • Hero Member
  • *****
  • Posts: 5233
Standard or language? What is the language level in M2 ?

M2 had coroutines and TRANSFER() etc. from day one as I understand it.

It must also have had some way of getting at the I/O address space (although I forget the detail, and I don't think C- as standard- has that) but no form of attributes etc. which could be used to select between an arbitrary number of segments (term used loosely) or address spaces.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10301
  • FPC developer.
Standard or language? What is the language level in M2 ?

M2 had coroutines and TRANSFER() etc. from day one as I understand it.

As part of the standard, but could be implemented as pure library solution?

Quote
It must also have had some way of getting at the I/O address space (although I forget the detail, and I don't think C- as standard- has that) but no form of attributes etc. which could be used to select between an arbitrary number of segments (term used loosely) or address spaces.

Aside from the fact that such implementation details don't belong in a standard, the code and datasegments of a cooperative tasks is roughly the same. So the only hardware bit is the stack. Changing the stack to a different segment might upset security software, so that must be done in an OS specific way.

Thaddy

  • Hero Member
  • *****
  • Posts: 11943

No parameterized macros
True. Although macro's are not strictly part of the language.
Quote
and no ? operator.
FPC has a generic ifthen<> (I wrote that) which is more or less the same, although it is not an operator, but a library function.
Black themes should be banned.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 10301
  • FPC developer.

No parameterized macros
True. Although macro's are not strictly part of the language.

In C to my best knowledge they are, which was the point.

Quote
Quote
and no ? operator.
FPC has a generic ifthen<> (I wrote that) which is more or less the same, although it is not an operator, but a library function.
I was not aware that that lazily evaluated?

MarkMLl

  • Hero Member
  • *****
  • Posts: 5233
As part of the standard, but could be implemented as pure library solution?

As part of the language. I'm not sure whether than can be implemented as a standard library routine, since a stack (etc.) context switch is involved.

Similarly, access to addressspaces other than standard memory is a compiler issue since at some point specialist assembler has to be emitted. (I can't remember how e.g. SPARC handled this in C).

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 5233
In C to my best knowledge they are, which was the point.

I think you're right, although I also think that it's defined that the preprocessor is (or at least behaves as) a separate pass.

Quote
I was not aware that that lazily evaluated?

Agreed, was discussed a few weeks ago the PascalDragon's involvement.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 11943
I was not aware that that lazily evaluated?
At least I designed it like that with Boolean evaluation settings in mind.
Suppose two TFunc parameters: then if TFunc1 evaluates to true TFunc2 is never executed because of Boolean shortcut evaluation.
So TFunc2 is Lazy. I believe Michael added an example for it that I added later.
Black themes should be banned.

Thaddy

  • Hero Member
  • *****
  • Posts: 11943
Agreed, was discussed a few weeks ago the PascalDragon's involvement.
Can you point me to that? AFAIK the code that I wrote does what I answered to Marco.
If not, the compiler does not do what I expected.
« Last Edit: August 08, 2022, 04:53:40 pm by Thaddy »
Black themes should be banned.

MarkMLl

  • Hero Member
  • *****
  • Posts: 5233
Can you point me to that? AFAIK the code that I wrote does what I answered to Marco.
If not, the compiler does not do what I expected.

I was thinking of https://forum.lazarus.freepascal.org/index.php/topic,59197.msg441906.html#msg441906 where it's unclear whether laziness is guaranteed.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Thaddy

  • Hero Member
  • *****
  • Posts: 11943
@mark  indeed that depends on shortcut evaluation. I can sort that with push/pop.
@Marco variatic macro's were only introduced in C99, it does not belong to Ansi C or certainly not K&R. It also requires (and still does) a separate lexer and parser and as such multiple passes. That is like FPC does it too, albeit that variatic ( which are untyped ) macro's are indeed not supported by FPC, to my regret. I asked for it many times. But I understand that the single pass concept prevailed for Pascal, since it was designed to be single pass. (Which FPC isn't anymore depending on settings)
« Last Edit: August 08, 2022, 06:48:25 pm by Thaddy »
Black themes should be banned.

bytebites

  • Hero Member
  • *****
  • Posts: 505
IfThen is regular function, nothing related to short-cut evaluation.

 

TinyPortal © 2005-2018