Markus F. schrieb:
> Dein $HERSTELLER
> betrachtet seine Header eben als Teil der Implementierung. Kann man so
> sehen, finde ich.
Wenn schon müssten aber alle internen Bezeichner mit __ anfangen, und
API's eben nicht. __enable_peripheral ist ein API, und viele interne
Bezeichner nutzen eben kein __ . Daher ist das also inkonsistent.
Der C Standard definiert nichts mit Peripherie-Takten, daher ist eine
Funktion dafür eher nicht in der Standard Bibliothek zu suchen. Die
Funktionen der ST Library braucht man nicht für Standard-Konforme
Programme, man kann ganz ohne sie alle Funktionalität des Standards
nutzen. Die ST Library ist nur eine ganz normale externe Bibliothek.
Das __ ist nur für interne Namen von Standard-Headern, und
Compiler-Builtins erforderlich, damit 100% Standard-Konformer Code,
welcher ausschließlich Standard-Header inkludiert, keine Kollisionen
produzieren kann. D.h. wenn folgender Code einen Fehler produzieren
würde, wäre das __ erforderlich:
1 | #include <stdio.h>
|
2 |
|
3 | int main () {
|
4 | puts ("Hello, World!");
|
5 | }
|
Dem ist aber nicht so; ein korrekterweise "enable_peripheral" genanntes
Makro sorgt nur für Kollisionen wenn man den ST-Header inkludiert, und
dann ist's eh nicht mehr Standard.
Tatsächlich ist die grassierende Nutzung von "__" oder _ +
Großbuchstabe eher auf Unwissen zurückzuführen, auch gerne bei
Include-Guards.
Ein klassisches Gegenbeispiel ist das M_PI bei der GNU Toolchain. Laut
C-Standard ist dieses Programm absolut korrekt:
1 | #include <math.h>
|
2 |
|
3 | int main () {
|
4 | int M_PI = 2;
|
5 | }
|
Aber wenn man es direkt mit "gcc" kompiliert gibt's Fehler, weil der
C-Header math.h fälschlicherweise ein M_PI definiert, was im Standard
nicht vorgesehen ist. Daher müsste das Makro eigentlich "__M_PI" o.ä.
heißen. Allerdings kompiliert der GCC default-mäßig nicht in einem
standard-konformen Modus; wenn man "-std=c99" o.ä. übergibt ist's
korrekt.
Wäre das __enable_peripheral in einem Standard-Header wie "stdlib.h"
o.ä. enthalten, dann wäre das __ erforderlich und korrekt.
