Eclipse: automatisches Entfernen von Tabs vor Präprozessoranweisungen verhindern

[Ralf (Gast)]

Hi,

kann man Eclipse das automatische Entfernen von Tabs vor 
Präprozessoranweisungen abgewöhnen? Konfigurieren kann man ja alles 
mögliche und noch mehr, nur das offenbar nicht :/

Ich ziehe es vor, Headerdateien eben so zu schreiben:

#ifndef _BLA_H_
  #define _BLA_H_

  #define xyz 1
  ...
#endif

Setze ich einen Tab und dann #, so geht auch schon der Tab flöten. 
Gleiches Spiel wenn man beispielsweise zwischen zwei #define-Anweisungen 
noch eine Anweisung setzen will und am Zeilenanfang Enter drückt, um 
eine neue Zeile einzufügen - die Zeile, die versetzt wird verliert den 
Tab argl das kekst...

Oder ist es absolut heiliger K&R-Stil, dass Präprozessoranweisungen 
IMMER am Zeilenanfang stehen?

Ralf

[Vn N. (wefwef_s)]

Grundsätzlich lässt sich der Stil unter "Window->Preferences->C/C++" 
umstellen.

[Sven P. (Gast)]

Früher(tm) gab es wohl Präprozessoren, die unbedingt eine Raute in der 
ersten Spalte sehen wollten. Ich hab so einen noch nicht gefunden, weiß 
es also auch nur aus zweiter Hand.

Man hat sich dann wohl so beholfen:

#if TOKENS
#  include <...>
#endif

[jack (Gast)]

Oder Eclipse will dir sagen dass es deine übermäßige Benutzung von 
verschachtelter Präprozessor-Magic nicht gut findet :-)

[Michael (Gast)]

jack schrieb:
> Oder Eclipse will dir sagen dass es deine übermäßige Benutzung von
> verschachtelter Präprozessor-Magic nicht gut findet :-)

Was bitte soll daran falsch sein, den Inhalt eines IF-Blockes 
einzurücken?

[Ralf (Gast)]

vn nn schrieb:
> Grundsätzlich lässt sich der Stil unter "Window->Preferences->C/C++"
> umstellen.
Joa, da hab ich auch umgestellt was ich unpassend fand - das o.g. kann 
man dort entweder nicht einstellen oder ich hab's nicht gefunden.

Sven P. schrieb:
> Man hat sich dann wohl so beholfen: ...
Hm, okay, das wär die Kompromissvariante :) An den Versuch das so zu 
schreiben hab ich gar nicht gedacht.

jack schrieb:
> Oder Eclipse will dir sagen dass es deine übermäßige Benutzung von
> verschachtelter Präprozessor-Magic nicht gut findet :-)
oO Für jede Fehleinstellung blinkts irgendwo rot auf, und da hat nix 
geblinkt, also ist es an sich in Ordnung :)

Michael schrieb:
> Was bitte soll daran falsch sein, den Inhalt eines IF-Blockes
> einzurücken?
Frag ich mich auch, allerdings wäre es hier ja ein "Spezialfall".

Ralf

[Vlad T. (vlad_tepesch)]

Michael schrieb:
> Was bitte soll daran falsch sein, den Inhalt eines IF-Blockes
> einzurücken?

falsch ist daran, dass es ein Präprozessorkommando ist und kein 
if-block.
Und präprozessor-Kommandos nun mal in der ersten Spalte beginnen sollten 
(auch wenn sich, wie bereits erwähnt, kein compiler daran stört)

[Karl H. (kbuchegg)]

Vlad Tepesch schrieb:

> Und präprozessor-Kommandos nun mal in der ersten Spalte beginnen sollten
> (auch wenn sich, wie bereits erwähnt, kein compiler daran stört)


Hatte ich ehrlich gesagt auch immer gedacht.
Dann hab ich im C-Standard nachgesehen: Nope. Leerzeichen sind erlaubt.

[Vlad T. (vlad_tepesch)]

seltsam, ich meine genau deswegen auch mal nachgeschaut zu haben.

aber hier der absatz:

6.10    Preprocessing directives

Different implementations have had different notions about whether white space is permissible
before and/or after the   signalling a preprocessor line.  The C89 Committee decided to allow any
#
white space before the  , and horizontal white space (spaces or tabs) between the   and the
# #
directive, since the white space introduces no ambiguity, causes no particular processing problems,
35
and allows maximum flexibility in coding style.

http://www.open-std.org/jtc1/sc22/wg14/
http://www.open-std.org/jtc1/sc22/wg14/www/projects#9899

Also scheinbar wirklich egal.

aber schon deswegen, weil die meisten IDEs mit zurücksetzen nerven, 
würde ich hakus Lösung benutzen. Schöner aussehen tut es meiner Meinung 
nach sowieso.