Hi Przemek, > the #pragma low level behavior strictly depends on > current compiler implementation. It may change in > the future or may need some completely different > implementation for modified compiler code so it should > not be sth what we can define as strict part of language [snip] > If you want the we can add such resetting but in such case we > should start from updating current list of programs to check > which are usable in such case (I hope that so far no one used > current functionality using files with compiler pragma settings > without real code to control switches between compiled modules). > Anyhow I would like to note that this may change in the future > and such functionality cannot be sth what may block farther > compiler optimizations.
Okay, points taken. I'd say let's focus on those pragmas while have a per file or per line effect, or which you think are worthy in this regard. BTW, I don't think we should cover everything with pragmas. Much of the fine tuning you mention would probably be better as non-controllable from #pragmas. (even though I use -km+ and -ko+ in hbmk2.prg) > The cost of resetting PP should be acceptable if user does not > use -u harbour compiler switch with his own long list of PP > directives in .ch file. Parsing such .ch file for each .prg > module for sure will be noticeable in the total compilation > time. That's good. > BTW we can also introduce #pragma push/pop which can be used > by user to resolve the problem of interaction between compiler > switches in much more flexible way. It's very good idea. Maybe it even makes the per file issue easier to fix, since it's possible to internally issue a push/pop at the beginning/end of each separate source. Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
