Namensschema für Funktionen

[Walter T. (nicolas)]

Guten Morgen zusammen,

ich gehe gerade alte, nicht mehr ganz frisch riechende Code-Teile durch 
und stelle fest, dass ich nie ein stringentes Namensschema entwickelt 
habe. Ich habe das mal am Beispiel von clamp() durchexerziert, weil das 
eine Funktion ist, die ich für jeden benutzten Datentyp mal 
implementiert habe.

Die Funktion selbst ist nahezu banal:

static inline int_fast8_t clamp(type *a, type llim, type ulim)
{
    assert( llim <= ulim );

    if( *a > ulim )
    {
        *a = ulim;
        return 1;
    }
    else if( *a < llim )
    {
        *a = llim;
        return -1;
    }
    else
    {
        return 0;
    }
}

Von der Namens-Logik aus <math.h> hießen die konkreten Funktionen:

int_fast8_t fclamp(double *a, double llim, double ulim);
int_fast8_t fclampf(float *a, float llim, float ulim);
int_fast8_t flampfl(long double *a, long double llim, long double ulim);

(clamp() wäre nach dieser Logik identisch mit fclamp())

Von der Namens-Logik aus 
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html würde 
für Integer-Datentypen gelten:

int_fast8_t sclamp(int *a, int llim, int ulim);
int_fast8_t sclampl(long int *a, long int llim, long int ulim);
int_fast8_t sclampll(long long int *a, long long int llim, long long int ulim);

int_fast8_t uclamp(unsigned int *a, unsigned int llim, unsigned int ulim);
int_fast8_t uclampl(long unsigned int *a, long unsigned int llim, long unsigned int ulim);
int_fast8_t uclampll(long long unsigned int *a, long long unsigned int llim, long long unsigned int ulim);

Wie sieht es mit den Datentypen aus <stdint.h> aus? Naiv würde ich 
schreiben:

int_fast8_t sclamp32(int32_t *a, int32_t llim, int32_t ulim);
int_fast8_t uclamp16(uint16_t *a, uint16_t llim, uint16_t ulim);

a) Ist das Schema sinnvoll, oder gibt es etwas besseres?

b) Zur konkreten Funktion clamp() (da C keine Templates kennt): Gibt es 
eine "schöne" Variante der Implementierung?

   b1): Was sicherlich funktioniert ist eine Makro-Hölle aus ternären 
Operatoren.

   b2): Tatsächlich implementiert habe ich sclampll() und uclampll(), 
alle anderen Integer-Funktionen rufen diese lediglich auf. Da alle 
Funktionen static inline sind, hoffe ich, daß der Compiler selbst 
erkennt, daß er den Integer nicht aufbohren muß. (Bei allen überprüften 
Listings wurde diese Hoffnung auch nicht enttäuscht, aber das ist ja 
keine allgemeine Bestätigung.)

[Walter T. (nicolas)]

Nachtrag: So schlimm sieht die Makro-Lösung doch nicht aus:

    /* Generische Makro-Funktion fuer Clamp. Nicht fuer den direkten Aufruf gedacht
     * ist lo > hi, ist das Ergebnis unerwartet. */
    #define CLAMP(x, lo, hi) \
        (x) > (hi) ? (x)=(hi), 1 : \
        (x) < (lo) ? (x)=(lo), -1 : \
        0\



    static_inline int sclamp32(int32_t *x, int32_t lo, int32_t hi)
    {
        return CLAMP(*x, lo, hi);
    }

Die andere Frage bleibt natürlich.

[Walter T. (nicolas)]

Ist der Wunsch nach ein wenig Ordnung im Quelltext so banal oder so 
abwegig?

[Tom (Gast)]

Als Freund der Autovervollständigung würde ich die Funktionen nur im 
Suffix unterscheiden(clamp_u8, clamp_i32 etc.). Für meinen Geschmack ist 
das weniger hässlich; warum man die Datentypkennzeichnung auf Pre- und 
Suffix des Funktionsnamens verteilen sollte, erschließt sich mir nicht.

[Kolja L. (kolja82)]

Tom schrieb:
> würde ich die Funktionen nur im
> Suffix unterscheiden(clamp_u8, clamp_i32 etc.). Für meinen Geschmack ist
> das weniger hässlich;

So gehe ich bei der Benennung von Messstellen vor.
Im coden habe ich zu wenig Erfahrung.

Jeder Name, den ich vergebe, sollte selbsterklärend sein.
Klappt aber nur, wenn das Projekt auch wirklich fertiggestellt wird...

[Wilhelm M. (wimalopaan)]

Ich habe sehr wohl gelesen, dass es hierbei um C geht. Trotzdem gebe ich 
zu bedenken: warum nicht einfach Deinen Code mit einem C++ Compiler 
übersetzen und in diesem Fall einfach die Möglichkeit nutzen, Funktion 
zu überladen? Du kannst zwar templates benutzen, aber wenn Dir das zu 
"kompliziert" erscheint, reicht auch schlichtes Überladen.

Natürlich gibt es wie

- Inkompatibilitäten (Klassiker: unions)
- C-Erweiterungen (fixed-point, _flash)

Derartiges kannst Du weiterhin in C TUs belassen.
Wenn Du eh am Refaktorieren bist, kannst Du das ja mal checken ...