; after then

[cdbc]

Hi
After I got used to it, it's the first thing I setup on a new install 
...I miss it instantly, when it's not there 
Regards Benny

[Curt Carpenter]

Is there a wiki on "(IDE) things to setup after a new install"?

[Martin_fr]

Is there a wiki on "(IDE) things to setup after a new install"?

Not that I am aware off. And there are too many things... And it doesn't just end at enabling stuff, all the neat little bit where codetools can do stuff for you (see my signature for the link), there probably are some you don't know yet.

And lots of other commands the IDE has.

- See the links in my sig
- browse through the IDE options
  - browse all the commands you can assign in the keymap
  - check the mouse settings
- browse the list of packages

=> With that info, be welcome to start such a wiki page.


Here is another bit that you may found useful.
Have you ever single stepped in the debugger, and at some point you look at a watch and you realize: that has the wrong value.
Then you ask yourself, did it have that value one step back? or 2 steps back?
If you did the stepping, and the value was evaluated (shown in watches), but you didn't pay it attention => the history window gives you access to the last 20 (or something) times you stepped (but only values that had been evaluated, it does not backward compute).

Hunting a mem leak? Copy it from console, and paste into "view > leaks and traces", and you can click the lines in the trace and the IDE jumps to the locations.

You can install a file browser.

IDE scout => search for features

...

[Curt Carpenter]

Thank you very much for the links:  I'll spend some time over the next few days exploring them and taking some notes.  I don't doubt that I'm only using a small fraction of all the tools the IDE provides -- despite quite a few years of use!.

[dseligo]

Wonder how many man-hours have been spent trying to find this problem when the ; is off screen?  It's a classic! 

Maybe it would be a nice new feature for FPC to emit warning when there is only empty statement.

In cases like this, e.g.:

Code: Pascal  [Select][+][-]

1. If a = b then ;
2.  
3. repeat
4. until a = b;
5.  
6. while a = b do ;
7.  
8. procedure x;
9. begin
10. end;
11.  
12. case a of
13. 1:;
14. end;

[Martin_fr]

Maybe it would be a nice new feature for FPC to emit warning when there is only empty statement.

Any of those empty loop can be a perfectly valid spin lock. Any of the vars can be altered by another thread (and dirty read may be fine).

Empty procedure may be needed to take the address of, if you have code that insists on a code ref, and you don't want it to do anything.

Empty "if" could also happen, if the evaluation of the condition has side effects. (and maybe the partial bool eval is used for some trickery)

[440bx]

another reason to have a "then ;" is when it is followed by an "else".  This saves from having to "not" the condition which if complex could extend over several lines and made harder to read by the presence of the "not".

[Martin_fr]

another reason to have a "then ;" is when it is followed by an "else".  This saves from having to "not" the condition which if complex could extend over several lines and made harder to read by the presence of the "not".

Not exactly, there is no ";" allowed before the else. But you would have the empty statement after the "then"

[440bx]

Not exactly, there is no ";" allowed before the else. But you would have the empty statement after the "then"

You're absolutely right.  I momentarily forgot that in Pascal the ; is a statement separator not a terminator. 

[dseligo]

Maybe it would be a nice new feature for FPC to emit warning when there is only empty statement.

Any of those empty loop can be a perfectly valid spin lock. Any of the vars can be altered by another thread (and dirty read may be fine).

Empty procedure may be needed to take the address of, if you have code that insists on a code ref, and you don't want it to do anything.

Empty "if" could also happen, if the evaluation of the condition has side effects. (and maybe the partial bool eval is used for some trickery)

FPC emits warnings for other stuff that are valid also.

I think this empty statements are programming errors in more cases than i.e. if you don't use parameter of method like this:

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
2. begin
3.   WriteLn('OnClose');
4. end;

And code above is also valid, and annoys more frequently than it would annoy warning for empty statement (when they are valid).

[Martin_fr]

FPC emits warnings for other stuff that are valid also.

True... But also:

Empty statement.
Not: Some selected empty statement.

A lot of code will give warnings.

Code: Pascal  [Select][+][-]

1. if foo = bar then begin
2.   DoAbc;
3.   DoXyz;
4. end;

Do you see the empty statement in the above code?

It's after "DoXyz;" => the semicolon is not a statement terminator, but a separator. After the last statement, no separator is needed.

But lots of code has them. And that are all empty statements.

[dseligo]

FPC emits warnings for other stuff that are valid also.

True... But also:

Empty statement.
Not: Some selected empty statement.

A lot of code will give warnings.

Code: Pascal  [Select][+][-]

1. if foo = bar then begin
2.   DoAbc;
3.   DoXyz;
4. end;

Do you see the empty statement in the above code?

It's after "DoXyz;" => the semicolon is not a statement terminator, but a separator. After the last statement, no separator is needed.

But lots of code has them. And that are all empty statements.

You are correct - and in this case I add ; on purpose (and out of a habit) - because if I need to write some more lines below, I don't need to add ; in previous line.

Also, FPC has much bigger priorities now than this.

[valdir.marcos]

IOW, the compiler should be _predictable_ and that _requires_ ensuring its basic types and definitions are immutable, otherwise predictability goes out the window thereby causing all kinds of headaches.

The point is that such identifiers are considered part of the namespace of the System unit. And due to ordinary language rules it's possible to redeclare symbols declared in another unit, cause they're still accessible using System.*. It also applies to intrinsics like Length, High, etc. or funnily enough Break and Continue (cause they're not keywords in the language sense).

Very interesting.