Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 19
  1. #1

    [OT] Perché tutti odiano il C++

    Perché molta gente odia il C++?!

    Wikiquote - C++

    [Anche Java è messo male...! Che sia la OOP?]

  2. #2
    Utente di HTML.it
    Registrato dal
    Jan 2011
    Messaggi
    1,469
    OT, forse perchè col C++ non ci si fa un granchè più di quello che si fa col C

    e Java è il tipico "write-once-debug-everywhere"
    - fine OT

  3. #3
    Originariamente inviato da franzauker
    OT, forse perchè col C++ non ci si fa un granchè più di quello che si fa col C

    e Java è il tipico "write-once-debug-everywhere"
    - fine OT
    Ma il C è venerato da molti, mentre il C++ è discriminato dai più. Se sono simili, come mai?
    A me la OOP sembra un paradigma davvero comodo!

  4. #4
    Utente di HTML.it L'avatar di shodan
    Registrato dal
    Jun 2001
    Messaggi
    2,381

  5. #5
    Utente bannato
    Registrato dal
    Oct 2010
    Messaggi
    1,219
    Secondo me perchè alla fine ci scrivi i sistemi operativi e i driver,adesso non so cosa è possibile fare col c++,ma il solo fatto di poter allocare memoria è indispensabile per gestire la ram.
    I romani usavano le pietre
    Comunque anche il C è criticato,ma non quanto il c++.
    A me non va di usare librerie come windows.h per fare cose che potrei fare in C#.

  6. #6
    Originariamente inviato da shodan
    Meglio riderci sopra, va.
    http://michele.sciabarra.com/page/No...QuelLinguaggio

  7. #7
    Originariamente inviato da ramy89
    Secondo me perchè alla fine ci scrivi i sistemi operativi e i driver,adesso non so cosa è possibile fare col c++,ma il solo fatto di poter allocare memoria è indispensabile per gestire la ram.
    I romani usavano le pietre
    Comunque anche il C è criticato,ma non quanto il c++.
    A me non va di usare librerie come windows.h per fare cose che potrei fare in C#.
    Alla fine mi sembrano tutti criticati, perché non esiste il linguaggio di programmazione perfetto.

    Però mi chiedevo come mai il C++ è criticato più degli altri...

    Io sono ignorante in queste cose, visto che ho iniziato a programmare in C++ e conosco solo quello (oltre a un po' di C, imparato comunque soprattutto tramite analogia con il C++).

  8. #8
    Utente di HTML.it L'avatar di KrOW
    Registrato dal
    Feb 2009
    Messaggi
    281
    Mah ... Io, personalmente, adoro questo linguaggio rispetto al c e a python (che sono gli unici linguaggi da me conosciuti) per diversi motivi: La sintassi, la potenza, la duttilita, l' unione di piu paradigmi di programmazione ecc ... Poi come disse qualcuno, tutto é relativo ....
    C++ 4EVER
    C++ 4ever
    496e2062696e6172696f206e6f6e2063692061767265737469 206e656d6d656e6f2020726f7661746f203a29

  9. #9
    Utente bannato
    Registrato dal
    Oct 2010
    Messaggi
    1,219
    Ma alla fine la potenza sta nel fare le cose veloci,secondo me chi li critica non li sta usando per lo scopo giusto.
    Magari tu usi il c++ per lo scopo per il quale è nato,secondo me chi critica prova a fare cose tipo creare un' interfaccia in C,o fare cose che vanno al di fuori dalle potenzialità del linguaggio.
    Per esempio se si vuole considerare il bash un vero e proprio linguaggio,io lo considero buono.Ma è il "linguaggio" dei sitemi operativi,è chiaro che se provo a farci altre cose lo trovo stupido.
    Ad esempio solo col comando eject espello il disco,in assembly la storia è più lunga,non è che allora l' assembly fa schifo

  10. #10
    Considerazioni in ordine sparso:
    Originariamente inviato da franzauker
    OT, forse perchè col C++ non ci si fa un granchè più di quello che si fa col C
    Rispetto al C credo anche perché ha una grammatica e feature molto più complicate, in parte mal comprese (e forse fin eccessive - un sistema di template turing-completo - anche se è stato in parte involontario - forse non è stata una così grande idea ).

    Ha una libreria standard piuttosto ristretta ma sufficientemente incasinata (tutte le volte che cerco di capire le relazioni tra le classi di iostream o di locale rinuncio ), e per essere retrocompatibile con il C si porta dietro tutta la libreria C, senza proporre alternative più "moderne" per un sacco di cose (una per tutte: gestione di data e ora).

    È terribilmente frammentato a livello di librerie, dato che la STL si è "imposta" (ma neanche troppo) nello standard relativamente di recente, e ogni framework si è inventato le sue varianti di ogni possibile classe di utilità (CString, std::string, wxString, ... e lo stesso per ogni possibile container); di conseguenza, ogni volta che si ha a che fare con una libreria scritta da terzi non si sa mai che container/stringhe/... ha deciso di usare il suo autore, il che è una gran menata. La frammentazione è aumentata dall'assenza di librerie che attualmente ci si aspetta da linguaggi "normali" (grafica, interfacciamento con DB, gestione del filesystem, threading, ...), per cui ognuno si è inventato la propria soluzione.

    Inoltre il C++ non ha un'ABI definita, se non a livello di singolo compilatore (e spesso ci sono incompatibilità anche tra varie versioni), dato che molte caratteristiche possono essere implementate in maniere diverse a livello binario (eccezioni, vtable, layout degli oggetti, eccetera). Fare delle dll C++ che siano effettivamente utilizzabili da più compilatori è spesso un'utopia, e anche le librerie statiche possono porre problemi notevoli (dato che linkare un file oggetto che contiene anche solo una versione diversa della CRT è una menata). In effetti se si vogliono evitare guai la cosa più semplice è compilare tutto con lo stesso compilatore (stessa versione, stessa CRT), oppure utilizzare interfacce C tra i vari componenti (per cui c'è solitamente un'ABI definita a livello di piattaforma) o interfacce standardizzate come COM (il cui utilizzo però è tutt'altro che semplice).

    Dato che la grammatica C++ è estremamente complessa (il significato dei token dipende pesantemente dal contesto), il parsing dei sorgenti è un gran casino ed è estremamente lento, il che si riflette anche nel fatto che gli IDE hanno i loro problemi a capire i sorgenti C++ (e il fatto che ci sia il preprocessore che può stravolgere completamente il significato di ogni token non aiuta); questo rende molto complessa la creazione di tool di refactoring e di generazione/gestione automatica del codice. Lo stesso sistema "a header" ereditato dal C poi è sicuramente piuttosto primitivo rispetto alle altre soluzioni che si sono impiegate in altri linguaggi.
    Tutto questo ovviamente garantisce tempi di compilazione+linking luuuunghi, cosa in genere non desiderabile.

    Sempre per la grammatica incasinata, risulta spesso difficile per i compilatori fornire errori comprensibili; se poi entrano in gioco i template (spesso ovattati da typedef nel codice) la questione messaggi di errore si fa ancora più tragica.

    Il grado di supporto per lo standard C++ varia molto tra i vari compilatori attualmente in uso, il che spesso costringe a contorsioni strane per far sì che codice tecnicamente ineccepibile sia digeribile da vari compilatori parzialmente bacati (basta vedere i workaround di boost per avere un'idea di ciò).

    Parti del linguaggio sono sempre state viste come "opzionali" (vedi ad esempio le eccezioni), spesso per buoni motivi, ma questo ha costretto molte librerie ad essere sviluppate per poter funzionare con e senza i pezzi in questione. Sempre a proposito delle eccezioni, sono state fornite come strumento privilegiato per riportare gli errori, ma senza un adeguato supporto da parte della libreria standard per creare codice exception-safe (fino al C++-03 l'unico smart pointer disponibile era std::auto_ptr).

    La STL è una gran figata, ma il linguaggio non assiste molto a programmare "nel suo stile": i functori sarebbero una grande idea, ma fornire degli algoritmi che operano con essi senza fornire le lambda functions è stata un'idiozia; grazie al cielo C++0x sta rimediando.

    Il supporto per Unicode latita: invece di fornire una cazzo di classe-stringa che operi correttamente con gli encodings più diffusi (UTF-8, UTF-16) in C++0x si sono inventati di creare un po' di tipi primitivi aggiuntivi per Unicode e poco altro; per gestirlo in maniera sensata si deve sempre ricorrere ad altre liberie (ad esempio ICU, o le classi-stringa di altre librerie) o a codice non portabile.

    La const correctness di base non è male, ma ci sono molti corner case in cui è un casino gestirla correttamente (vedi ad esempio l'overloading di funzioni che restituiscono riferimenti in versione const/non const, dove bisogna ricorrere a trucchi stranissimi con static_cast e const_cast).

    I template sono uno strumento potentissimo, ma dalla sintassi spesso strana e poco intuitiva (le specializzazioni parziali dei template e le funzioni template dentro a classi template richiedono delle contorsioni mentali notevoli); la questione del typename per chiarificare l'interpretazione di alcune istruzioni non è immediata, e i vari compilatori hanno diversi gradi di "condono" per la sua assenza, per cui è facile abituarsi a metterlo solo andando per tentativi. Lo stesso fatto che alla fine l'unico modo per avere template usabili in maniera semplice sia includerli in tutti i sorgenti non aiuta il compilatore a velocizzare il parsing, e richiede lavoro aggiuntivo per il linker nel rimuovere le definizioni duplicate.

    Dato che il C++ è un linguaggio molto usato, supportato da più compilatori ed è standard ISO, ogni modifica al core del linguaggio e alla libreria standard va con i tempi dell'ISO (e con i veti dei suoi vari membri), il che significa che, se emergono problemi in caratteristiche del linguaggio, per la successiva revisione bisogna comunque aspettare una decina d'anni. Nel frattempo ogni compilatore implementa a livello di estensioni più o meno proprietarie spizzichi e bocconi delle nuove caratteristiche proposte per il nuovo standard, con il risultato che se ci si vuole mantenere portabili comunque non le si possono utilizzare. Inoltre, anche dopo l'uscita dello standard comunque, se si vuole mantenere la compatibilità con i compilatori un pelo più vecchi, bisogna evitare le feature più recenti.

    Il fatto che sia un linguaggio a paradigma di programmazione multiplo fa sì che non ne incoraggi nessuno, pertanto non aiuta il programmatore in termini di rigore e aderenza ad un paradigma (questo non è propriamente un difetto, ma può essere un handicap per chi sta imparando il linguaggio).

    Diverse feature sono o parziali duplicazioni di ciò che già esiste nel C e che viene supportato per retrocompatibilità, o estensioni di caratteristiche del C in maniere non ovvie (puntatori/reference, class/struct, ...).

    Tutte questi problemi hanno sicuramente delle ragioni storiche e si possono certamente giustificare, ma ciò non toglie che restino dei problemi.
    Amaro C++, il gusto pieno dell'undefined behavior.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.