Aiutami a pensare in C ++

È possibile utilizzare piccoli buffer a dimensione fissa per uno dei seguenti motivi:

Vincoli
1. : memoria limitata, prestazioni della cache o altri requisiti di velocità che vietano assolutamente la (ri) allocazione dinamica
2. pigrizia: IMO è principalmente un hang-over di C, che non ha una ricca libreria di contenitori
3. correttezza: se stai abbinando qualche entità esterna (hardware, o un formato di file o un protocollo filo) che ha veramente degli elementi di dimensione, allora perché non li rappresentano esattamente?

Quindi, esaminiamo l'esempio del DB del tuo dipendente.

1. è limitato nella memoria o nelle prestazioni? Non per cominciare, anche se lo stai eseguendo su un orologio da polso in questi giorni
2. siamo o pigri o scriviamo C 20 anni fa? No!
3. stiamo riflettendo qualche verità esterna? Forse se passiamo a un DB in un secondo momento e decidiamo di creare una colonna VARCHAR (100), avere una matrice di dimensioni 100 potrebbe essere ragionevole. Ma lo faremmo per espressività , per non mostrare la nostra leggerezza di basso livello. E inoltre, hai escluso questo caso nella tua domanda.

Il modo giusto per farlo sarebbe probabilmente:

1. scegli un contenitore standard adatto ai tuoi pattern di accesso ( std::list e std::vector sono scelte comuni per tutti gli usi)
2. scrivi alcune classi per rappresentare un dipendente
3. scrivi del codice per (de) serializzare questo dipendente

Se lo fai bene, gestisce tutta la memoria per te e non richiede nulla di lunghezza fissa. Sembrerà un po 'simile alla logica equivalente in Python o javascript.

tl; dr

il tuo problema dichiarato è non un problema di basso livello , quindi non c'è motivo di scambiare chiarezza o semplicità con la magia di basso livello.

Se avevi un problema di basso livello, quelle decisioni di progettazione di basso livello sarebbero derivate dal problema & domini di soluzione.

Utilizzare lo stile di basso livello su un problema di alto livello è solo uno stile sbagliato, perché non corrisponde al dominio problematico.

Solo perché i programmatori C ++ tendono ad addentrarsi negli strati inferiori dell'astrazione più spesso non significa che viviamo sempre lì. Quando ci troviamo di fronte a un problema di alto livello, utilizziamo le astrazioni di alto livello.

Il tuo problema di esempio probabilmente verrebbe risolto con un vector all'inizio, refactored in una classe EmployeeList supportata da un vector mentre la complessità cresceva, quindi refactored per essere supportata da un database man mano che le dimensioni crescevano. I programmatori C ++ non sono preveggenti su come la loro applicazione crescerà o meno. Siamo altrettanto vincolati a principi di progettazione come YAGNI.

Se non ci fosse una libreria standard vector , un buon programmatore C ++ dovrebbe scrivere il suo, e un programmatore cattivo soffrirebbe delle limitazioni che gli sono state date. Le persone che non utilizzano correttamente l'astrazione sono cattivi programmatori in qualsiasi lingua.

Pensavo che un ragazzo di marketing pubblicasse qualcosa per quel famoso tizio che ha scritto quel libro di libri pensanti; "Pensare in C ++", "pensare in Java", "pensare in python" ... Senza offesa, ho adorato i suoi volumi in C ++, il volume 2 era come una parte del mio tavolino quando avevo circa 20 anni.

In base alla mia esperienza, credo che riguardi l'industria e il dominio, se si tratta di sistemi embedded, oppure se stai lavorando su sistemi a latenza estremamente bassa, quindi per impostazione predefinita, non importa se sei una gemma nascosta nell'esecuzione astrazioni, inizierai a pensare di risparmiare memoria usando un union invece di una struttura e poi anche dichiarando le variabili in base all'allineamento dei byte e al padding. non è un dono, solo una pratica che si sviluppa per un periodo di tempo.

Per risolvere i tipici problemi di sviluppo delle applicazioni, può dipendere dal fatto che tu sia un povero ragazzo di generazione x come me, che automaticamente inizia a pensare come dei boomers mentre lavora con loro, al fine di impressionare (o potrebbe essere per rispetto ?? ), fingendo il mio i7 quad-core come commodor-64 al meglio e inutilmente provando a salvare pochi bit per mostrarli. Ma dopo questo risultato, quando provo a uscire per una pausa caffè / fumo con millenials, di solito faccio finta che il vecchio C sia morto, chi se ne frega della memoria più e per favore non sono un dinosauro, gente che scrive questo tipo di codice in pensione molto prima di laurearmi. Un dilemma senza fine sembra fino a quando non lascio il codice.