Does Freepascal has everything "must have" functional features as C does

[PeterHu]

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]

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

[MarkMLl]

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

[marcov]

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

Arguable.

Anything opinion based is arguable.

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.

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.

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 ?

[MarkMLl]

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

[marcov]

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?

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]

No parameterized macros

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

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.

[marcov]

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.

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]

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

[MarkMLl]

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.

I was not aware that that lazily evaluated?

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

MarkMLl

[Thaddy]

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.

[Thaddy]

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.

[MarkMLl]

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

[Thaddy]

@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)

[bytebites]

IfThen is regular function, nothing related to short-cut evaluation.