Ridurre la ripetizione del tipo di ritorno delle funzioni

Alcune opzioni:

• Un alias come using Settings = std::map<std::string, std::string> riduce la digitazione, ma viene comunque ripetuto

Settings readSettings() {
    Settings settings;

    for(std::string rawSetting; std::getline(settingsFile, rawSetting); )
        settings.insert(parseRawSettingIntoPair(rawSetting));

    return settings;
}

• Costruisci direttamente il valore restituito da una coroutine - ancora abbastanza prolisso

std::map<std::string, std::string> readSettings() {
    using coro_t = boost::asymmetric_coroutine<std::pair<std::string, std::string>>;
    coro_t::pull_type source([&](coro_t::push_type& sink) { 
        for(std::string rawSetting; std::getline(settingsFile, rawSetting); )
            sink(parseRawSettingIntoPair(rawSetting));
    });
    return { begin(source), end(source) };
}

• Entrambi (perché perché no: P)

Puoi semplicemente utilizzare typedef.

typedef std::map<std::string, std::string> Settings;

Settings readSettings() {
    Settings settings;
    for(std::string rawSetting; std::getline(settingsFile, rawSetting); )
        settings.insert(parseRawSettingIntoPair(rawSetting));
    return settings;
}

... materiale non proprio rivoluzionario, ma fa il lavoro. Per quanto riguarda la ridondanza, è tutta sintassi come la vedo io - non come qualcosa che è soggetto a bug in fase di runtime.

Cercare di rendere il codice più facile da leggere e scrivere possibile non dovrebbe precedere che sia sicuro e collaudato in modo da non doverti preoccupare di cambiarlo continuamente e rileggerlo se me lo chiedi, ma il semplice esempio di typedef sopra è una soluzione rapida e semplice per facilitare lo sforzo senza perdere molto tempo a pensarci o richiedere al compilatore di dedurre il tipo di ritorno dall'implementazione con auto (che richiederebbe l'implementazione per essere visibile a chiamanti come hai indicato).

Finalmente è facile cambiare Settings in un tipo diverso che ha gli stessi requisiti di interfaccia se ne hai mai bisogno - richiede solo di cambiare una riga di codice.

Solo per completezza, ecco un approccio che non restituisce il risultato come raccolta STL. Invece, passa i dati in un callback. Questo può o non può soddisfare i requisiti del tuo progetto; è menzionato qui solo per completezza.

Due avvertimenti.

Innanzitutto, la firma per std::function è più brutta di std::map , con parentesi angolate annidate (modello), parentesi (gli argomenti della funzione) e void per nessun vantaggio.

In secondo luogo, se la persona che fornisce il callback fa qualcosa di stupido all'interno del callback (come provare a modificare la raccolta o manipolare la stessa classe), può essere attivato un comportamento non definito. In altre parole, questo approccio di callback è fragile a meno che tutti gli utenti del codice non siano ben informati.

Ancora una volta, questo è fornito per completezza, non come pratica raccomandata.

void readSettings(std::function<
    void(const std::string& key, const std::string& value)> func)
{
    for(std::string rawSetting; std::getline(settingsFile, rawSetting); )
    {
        std::string key;
        std::string value;
        std::tie(key, value) = parseRawSettingIntoPair(rawSetting);
        func(key, value);
    }
}

La motivazione principale per scrivere questa risposta è se il chiamante (consumatore dei dati) è già noto per che rifiuta di utilizzare lo stesso tipo di raccolta STL come funzione. In questo caso, l'insistenza del chiamante nell'usare un tipo diverso significa che il codice della colla è necessario , quindi l'autore della funzione potrebbe anche trasformarsi nel codice della colla.

Tale situazione si verifica quando i due lati del codice sono gestiti da diversi campi di sviluppatori.