How to put longstrings globally on?
I tried with {$h+} in project compiler settings (other) with no effect.

Example of this "no effect"? {$H+} should do it.

Rainer Stratmann wrote

How to put longstrings globally on? I tried with {$h+} in project compiler settings (other) with no effect.

Safest method is not to use the generic type "string" in your code. Instead use directly the string type that you need (i.e. "ansistring" or "unicodestring"). That way you don't have to fight with compiler switches at all.

Rainer Stratmann wrote

How to put longstrings globally on? I tried with {$h+} in project compiler settings (other) with no effect.

{$H+} does not go into project settings, it goes directly into the source.

In our previous episode, J?rgen Hestermann said:

> How to put longstrings globally on? > I tried with {$h+} in project compiler settings (other) with no effect. Safest method is not to use the generic type "string" in your code. Instead use directly the string type that you need (i.e. "ansistring" or "unicodestring").

I wouldn't do that. That makes later migration unnecessary involved. Just define an alias and use that everywhere.

But a -Sh in the compiler settings should go a long way.

There is also a "tick" for {$H+} in the compiler options->"parsing". (but I have v1.1 here, not fixes)

leledumbo wrote

Example of this "no effect"? {$H+} should do it.

Is it global (for all sourcefiles) if put on top of the first sourcefile?

In our previous episode, Rainer Stratmann said:

> Example of this "no effect"? {$H+} should do it. Is it global (for all sourcefiles) if put on top of the first sourcefile?

No. This can be easily seen that if one would first compile files 2..5 and only then 1, while compiling 2..5 the compiler would not know about 1 if 2..5 don't USES 1.

No, directives at most have only unit scope.

Yes that works both! Thanks.

Next question is how to put asmmode intel global on?

Rainer Stratmann wrote

Next question is how to put asmmode intel global on?

Type fpc -h (in a console) to see all commandine parameters. Then take a look at the -R switch.

Bart

That works thank you very much.

I am confused about the different methods {ASMMODE ...} in sourcecode and -R ... in the config setup.

You can also set the assembler mode through Lazarus: Go to "Project => Project settings => Compiler settings => Parsing" and there you'll find a radio group box where you can choose the assembler style.

The need for the different ways of configuring is the following:
* FPC is independent of Lazarus, so FPC needs a way to "globally" specify the assembler style (this is also used by Lazarus if you change the option using the above mentioned method)
* the {$ASMMODE ...} switch on the other hand is LOCAL as this allows you to have multiple assembler routines in the same unit that use different styles (mostly used by the System unit which is made up of multiple include files (you can even see that if you look at $fpcdir/rtl/i386/i386.inc where at the top is a routine in Intel style and then the mode is switched to AT&T style)

Regards,
Sven

Marco van de Voort wrote

> Safest method is not to use the generic type "string" in your code. > Instead use directly the string type that you need (i.e. "ansistring" or "unicodestring"). I wouldn't do that. That makes later migration unnecessary involved.

I find it quite naive to believe that a "later migration" (to what?) can be achieved by simply changing the string type. In general, the code needs changes too when doing that. And therefore it would be a good idea to force oneself to have a look at the code by having to change the type definitions.

Just define an alias and use that everywhere.

Of course, that's the best way. But this is a different topic. The alias can also point to "string" again which does not help very much. So the alias should be for a fixed type like ansisting or unicodestring but not for "string".