Newsgroup: it.comp.lang.c++
Titolo: STL e conflitti con i capi

Ciao a tutti,
il mio quesito e' semplice semplice.
Il mio capo si rifiuta di farmi utilizzare le stringhe ed i vettori della
STL, adducendo motivi di velocita', ottimizzazioni e di futuri possibili
problemi.
L'alternativa e' quella di utilizzare librerie di stringhe fatte in azienda
o utilizzare la "sempreverde" tecnica C (char * al posto di string e array
di valori al posto di vector).
Dico questo perche' quando qualcuno qua fa domande su possibili
implementazioni di codice al cui interno si notano usi di array e di char *,
voi fate sempre notare che in C++ non si fa e magari, nella risposta
cambiate il codice originale con codice STL.
Purtroppo la triste realta' aziendale vede miscugli di codice C mascherato
da C++, in sostanza del C con classi con ereditarieta' e virtual a gogo', ma
tutto ignorando la STL e molto altro.
Abbiate comprensione per chi posta domande C++ senza uso di STL, io li
capisco
Maurus

 problemi.
Da noi č "vietato" usare STL solo in programmi MFC... 
-- 
Luc.

 Luc.
E come mai?
Mi incuriosisce cio' perche' anche noi abbiamo progetti MFC (vecchiotti).
So che in alternativa a std::string ci sono le CString MFC cosi' come ci
sono i CStringArray al posto di std::vector<std::string>.
Il guaio e' che essendo un progetto enorme e vecchiotto non possiamo
cambiare le settings come per esempio abilitare la macro UNICODE che mi
permetterebbe di utilizzare le CString gestendo anche stringhe unicode.
Non potendolo fare avevo pensato di utilizzare la STL ma ho avuto lo stop.
Ci sono conflitti possibili fra STL e MFC ?
Riassumendo:
-Debbo utilizzare MFC
-Non posso utilizzare la macro UNICODE
- ho la necessita' di gestire array di stringhe e stringhe unicode e non.
Maurus

 capisco
Loro forse si, ma i loro responsabili...
 
Non ce l'ho con te, e conosco persone che basano opinioni non del tutto
diverse da quelle del tuo caso su una grande esperienza (reale, non anni
passati a ripetere gli stessi errori). Purtroppo spesso questi punti di
vista non hanno nessuna base concreta e ragionevole e si fondano
sostanzialmente sull'ignoranza e sulla pigrizia.
Ciao,
Nicola

 - ho la necessita' di gestire array di stringhe e stringhe unicode e non.
STL. Per forza.
-- 
Luc.

 Nicola
Alla prossima
Maurus

 tutto ignorando la STL e molto altro.
E questo e' male.
Nella mia esperienza ho incontrato "capi" che promuovevano 
la semplicita' nel codice.  Questa e' cosa buona e giusta, a mio 
avviso: piu' le cose sono semplici, maggiore e' la probabilita' che
funzionino.  Ma troppo spesso questo atteggiamento mascherava la 
loro ignoranza circa argomenti un po' piu' articolati (come
la libreria standard del C++).  Il fatto, cioe', di avere una
pigrizia mentale, che non li porta ad approfondire certi aspetti,
porta ad utilizzare vecchi sistemi collaudati, ma enormemente piu' 
difficoltosi, rispetto all'uso di tecniche nuove.
In altri termini, non si puo' rinunciare al beneficio di std::string e 
std::vector solo per un'innata sfiducia nei loro confronti.
E' come se, abituati a salire le montagne sul muletto, qualcuno
ci offrisse una bella jeep 4x4 e gli dicessimo: no grazie, non
mi fido, il muletto d'altronde ha sempre fatto il suo dovere.
E' stupido e controproducente.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 interne, che farebbero rimanere ognuno sulle proprie posizioni.
IMHO basta premettere: "sono obbligato ad usare <feature [del C | home 
made ]> quindi non posso usare <feature del C++>"


Immagino che la sua replica, come quella di tanti responsabili sara' che per
far si' che poi tutti possano usare la jeep al posto del muletto, occorre
uno sforzo globale, perche' ora tutti nella ditta sanno usare il muletto, ma
se tu usassi la jeep obbligheresti gli altri a scuole guide non volute e
costose.
Del muletto conosce pregi e difetti, ma ha paura che la jeep lo lasci in
panne.
Maurus

 stato puro o no?
La questione e' usare lo strumento piu' appropriato per ciascun
problema. In funzione di quanto e come le tue strutture dati cambiano
dimensione sara' piu' indicata una tecnica piuttosto che un'altra. 
Chiaro che se devi memorizzare i nomi dei mesi dell'anno e' difficile
battere l'array di dodici array di caratteri (salvo che poi qualcuno non
ti chieda di "internazionalizzare" l'applicazione...)
Ciao,
Nicola

costose.
Eh, ma questo si chiama "appiattimento" e non va affatto
bene.  Si diventa l'ultima ruota del carro, proprio perche'
il peso di essere la prima e' troppo grande.  Io non so chi
sono queste persone che programmano senza avere un minimo di
stimolo ad imparare a guidare comodamente la jeep anziche'
continuare a spezzarsi la schiena ancorati al dorso del
mulo, ma mi fanno veramente pena.
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]

 ha scritto nel messaggio
news:a7pfku$mgdc6$1...@ID-125555.news.dfncis.de...

Dietro la libreria standard c'è un grosso lavoro volto a rendere disponibili
le principali strutture dati unite a prestazioni mediamente accettabili.
Ogni sviluppo
di codice simile ripropone gli stessi problemi incontrati dai progettisti
della libreria e sconfina quindi nel reinventare la ruota.
Si tratta inoltre di codice ampiamente utilizzato e quindi assai "rodato"
perciò anche sul piano dell' affidabilità non vedo controindicazioni,
piuttosto il contrario.
Con un hardware che segue una legge di progressione esponenziale nelle
prestazioni sono davvero poche le situazioni che richiedono ottimizzazioni
tali
da giustificare una scrittura ad hoc di un componente presente nella
libreria standard. Il successo di macchine virtuali (java o .net) indica che
si è disposti a compromessi ben peggiori. Inoltre, e non è cosa da poco,
sarebbe un grosso vantaggio per una azienda avere una base di codice
uniforme, portabile e già nota ad ogni programmatore che entrasse a far
parte del team.
Il problema credo sia la massa di codice già scritto, che costituisce il
patrimonio ma anche la zavorra di queste aziende. Riscrivere codice o
cambiare metodi in un gruppo costa e non porta vantaggi economici immediati
e quindi generalmente non si investe in tal senso. Sarebbe comunque assurdo
non far notare tali contraddizioni e non indirizzare programmatori con meno
esperienza verso un più completo punto di vista.
----
Sergio Bianchi

capisco
Questo non vuol dire che non gli si debba proporre la soluzione che
secondo noi resta migliore(del resto it.comp.lang.c++ esiste
apposta)che sicuramente esclude di utilizzare caratteristiche del C.
Il Ghenio
---------
// TODO: Place your ass here

sostanzialmente sull'ignoranza e sulla pigrizia.
Concordo in pieno. Ciao!!


>e copiati se si sforano le dimensioni. Voi avete soluzioni migliori?
std::vector e' qualcosa di diverso... e onestamente fatico
a pensare a motivi per non usare questa classe invece di
allocazioni dinamiche di array (tranne il gia' citato
problema con le DLL).
Andrea

tutto ignorando la STL e molto altro.
Io non sminuirei cosi' tanto questo uso del C++ che spesso viene
chiamato "C with classes". Il C++ e' un linguaggio multiparadigma
e il fatto che una feature sia presente (es. tipi parametrici o
exceptions) non significa che sia necessario utilizzarla a tutti
i costi in tutti i programmi.
Personalmente ritengo che il sottoinsieme del C++ formato dal C
e dalle classi (ma senza reference e senza usare la semantica
di copia, senza exeptions, senza template e, di conseguenza,
senza STL) possa avere un suo ambito di applicazione dignitoso;
se non altro per la semplicita' rispetto al C++ "completo".
Si tratta in fondo di quanto forniva il Borland Pascal 5.5
with Objects... :)
Andrea