Creazione di una libreria const-correct (C++) che si basa su una libreria non costante alla costante

Question

Sto costruendo una libreria in C++ (principalmente per divertimento) a cui sto lavorando da un po 'di tempo (anni, haha , è solo un hobby)

Recentemente ho cambiato alcune delle basi (leggi, dipendenze della libreria) in un'altra libreria. Sfortunatamente, la biblioteca non è affatto interessata da "costituttezza". Sono un po 'OCD e mi piace sfidarmi a fare cose "The Right Way ™", quindi mi piacerebbe rendere la mia libreria costante. Ho iniziato questo alcune volte, e alcune parti sono; So che è meglio iniziare da const-correct dall'inizio, ma questo non è veramente rilevante o pronto per il dibattito. Il fatto è che sono interessato a dargli un serio ritorno, ma l'altra libreria mi impedisce di farlo.

Come, potresti chiedere?

Beh, se sto chiamando un metodo che dovrebbe essere chiaramente const (in realtà non cambia nulla), e il mio metodo è anche un candidato per la costante (nuova parola), non posso garantire la costanza sul mio metodo fino a quando anche l'altro metodo è const.

Esempio:

// Bad third-party library 

struct Foo 
{ 
    void should_be_const() {} 
}; 

// My library 

struct Bar 
{ 
    Foo my_foo; 
    void should_be_const() const 
    { 
     my_foo.should_be_const(); // ERROR! Not a const function! 
    } 
}; 

Questo è solo apparente a me da prove empiriche e dalla mia ricerca e comprensione di const-ness. Tuttavia, questa potrebbe essere una comprensione falsamente formata, quindi sono aperto (e fiducioso?) A ciò che è sbagliato e mostrato diversamente (anche se ciò scuoterebbe le fondamenta della mia comprensione della haha)

Cos'è un'anima povera fare se lui (o lei) vuole scrivere una libreria corretta ma una dipendenza non è scritta in quel modo?

Spero che questa sia una domanda appropriata per SO. Per favore (sono sicuro che lo farai) fammi sapere se non lo è o se c'è un sito StackExchange migliore per pubblicarlo.

P.S. Ho trovato this SO question, ma speravo che l'argomento/la soluzione potesse essere elaborata.

Answer 1

L'altra domanda a cui si fa riferimento fornisce un buon vantaggio su quali sono i problemi, ma non condivido un po 'la risposta. Le interfacce nelle librerie secondarie si suddivideranno in quattro casi.

1. Cose che non sono costanti e non ci si può aspettare di essere.
2. cose correttamente dichiarati const

3. Cose che logicamente dovrebbero essere const, e

   3a. Sono implementati come tali ma non sono dichiarati in tal modo

   3b. non sono state implementate in quanto tale

Caso 1 è facile - se si vuole il vostro da essere const, allora avete bisogno di fare una copia di ingresso prima di chiamare tale interfaccia. Un cast sarebbe semplicemente sbagliato e finirà per causare un crash o un altro errore. Il caso 2 non è un problema. Quindi i casi 3 lo sono.

Sfortunatamente, la realtà è che i casi 3a e 3b devono essere trattati in modo identico al caso 1 perché sono indistinguibili. L'implementazione potrebbe cambiare in base alla piattaforma o alla versione. Quindi, dovresti creare una copia e quindi chiamare l'interfaccia. Notate che ho detto "dovrebbe."La realtà è che la maggior parte di noi userà un const_cast per chiamare interfacce che pensiamo di capire (per esempio strcmp) .Si tratta di un giudizio su quanto siamo fiduciosi nell'implementazione.Personalmente, non mi preoccuperei di strcmp. qualsiasi livello di livello superiore potrebbe utilizzare qualcosa come strtok che rompe le cose