it-swarm.it

C'è qualche motivo per usare C ++ invece di C, Perl, Python, ecc.?

Come sviluppatore Linux (lato server), non so dove e perché dovrei usare C++.

Quando vado a esibirsi, la prima e l'ultima scelta è C.

Quando "performance" non è il problema principale, i linguaggi di programmazione come Perl e Python sarebbe una buona scelta.

Quasi tutte le applicazioni open source che conosco in quest'area sono state scritte in C, Perl, Python, Bash script, AWK o persino PHP, ma nessuno usa C++ .

Non sto discutendo di altre aree come la GUI o le applicazioni web, sto solo parlando di Linux, CLI e demoni.

C'è qualche motivo soddisfacente per usare il C++?

166
Ehsan

Quando ho intenzione di esibirmi, la prima e l'ultima scelta è C.

Ed è qui che dovresti eseguire il backup. Ora, non posso affatto parlare per lo sviluppo del server. Forse non c'è davvero alcun motivo convincente per preferire il C++ rispetto alle alternative.

Ma in generale, la ragione per usare il C++ piuttosto che altri linguaggi è proprio la prestazione. La ragione di ciò è che C++ offre un mezzo di astrazione che ha, a differenza di tutte le altre lingue che conosco, nessun sovraccarico di prestazioni in fase di esecuzione.

Ciò consente di scrivere un codice molto efficiente che ancora ha un livello di astrazione molto elevato.

Considera le solite astrazioni: funzioni virtuali, puntatori a funzione e linguaggio PIMPL. Tutti questi si basano sull'indirizzamento indiretto che è in fase di esecuzione risolto dall'aritmetica del puntatore. In altre parole, comporta un costo in termini di prestazioni (per quanto piccolo possa essere).

Il C++, d'altra parte, offre un meccanismo indiretto che comporta nessun costo (prestazioni): modelli. (Questo vantaggio viene pagato con un tempo di compilazione (talvolta enormemente aumentato).

Considera l'esempio di una funzione di ordinamento generica.

In C, la funzione qsort accetta un puntatore a funzione che implementa la logica in base alla quale gli elementi sono ordinati l'uno rispetto all'altro. Java Arrays.sort La funzione è disponibile in diverse varianti; uno di questi ordina oggetti arbitrari e richiede che gli venga passato un oggetto Comparator che funzioni in modo molto simile al puntatore della funzione in qsort di C. Ma ci sono molti altri sovraccarichi per i "native" Java. E ognuno di essi ha una propria copia del metodo sort - un'orribile duplicazione del codice.

Java illustra una dicotomia generale qui: o hai la duplicazione del codice o incorri in un sovraccarico di runtime.

In C++, la funzione sort funziona in modo molto simile a qsort in C, con una piccola ma fondamentale differenza: il comparatore che viene passato alla funzione è un modello parametro. Ciò significa che la sua chiamata può essere in linea . Non è necessaria alcuna indiretta per confrontare due oggetti. In un circuito stretto (come nel caso qui) questo può effettivamente fare una differenza sostanziale.

Non sorprende che la funzione C++ sort superi sort di C anche se l'algoritmo sottostante è lo stesso. Ciò è particolarmente evidente quando l'attuale logica di confronto è economica.

Ora, non sto non dicendo che C++ è a priori più efficiente di C (o di altre lingue), né che a priori offre un'astrazione più elevata. Ciò che offre è un'astrazione che è molto alta e incredibilmente economica allo stesso tempo, quindi spesso non è necessario scegliere tra codice efficiente e riutilizzabile.

310
Konrad Rudolph

Vedo troppi programmatori C che odiano il C++. Mi ci è voluto un po 'di tempo (anni) per capire lentamente cosa è buono e cosa è male. Penso che il modo migliore per esprimere sia questo:

Meno codice, nessun sovraccarico di runtime, più sicurezza.

Meno codice scriviamo, meglio è. Questo diventa rapidamente chiaro in tutti gli ingegneri che lottano per l'eccellenza. Risolvi un bug in un posto, non in molti: esprimi un algoritmo una volta e lo riutilizzi in molti luoghi, ecc. I greci hanno persino un modo di dire, fatto risalire agli antichi spartani: "dire qualcosa in meno parole, significa che sei saggio al riguardo ". E il fatto è che se usato correttamente , C++ ti permette di esprimerti in molto meno codice di C, senza costare la velocità di runtime, mentre essere più sicuro (ovvero rilevare più errori in fase di compilazione) rispetto a C.

Ecco un esempio semplificato dal mio renderer : quando si interpolano i valori dei pixel attraverso la linea di scansione di un triangolo. Devo iniziare da una coordinata X x1 e raggiungere una coordinata X x2 (da sinistra a destra di un triangolo). E attraverso ogni passaggio, attraverso ogni pixel che passo, devo interpolare i valori.

Quando interpolo la luce ambientale che raggiunge il pixel:

  typedef struct tagPixelDataAmbient {
      int x;
      float ambientLight;
  } PixelDataAmbient;

  ...
  // inner loop
  currentPixel.ambientLight += dv;

Quando interpolo il colore (chiamato ombreggiatura "Gouraud", dove i campi "rosso", "verde" e "blu" sono interpolati da un valore di passo per ogni pixel):

  typedef struct tagPixelDataGouraud {
      int x;
      float red;
      float green;
      float blue;  // The RGB color interpolated per pixel
  } PixelDataGouraud;

  ...
  // inner loop
  currentPixel.red += dred;
  currentPixel.green += dgreen;
  currentPixel.blue += dblue;

Quando eseguo il rendering con l'ombreggiatura "Phong", non interpolo più un'intensità (luce ambientale) o un colore (rosso/verde/blu) - Interpolo un vettore normale (nx, ny, nz) e ad ogni passo, devo ri -calcolare l'equazione dell'illuminazione, in base al vettore normale interpolato:

  typedef struct tagPixelDataPhong {
      int x;
      float nX;
      float nY;
      float nZ; // The normal vector interpolated per pixel
  } PixelDataPhong;

  ...
  // inner loop
  currentPixel.nX += dx;
  currentPixel.nY += dy;
  currentPixel.nZ += dz;

Ora, il primo istinto dei programmatori C sarebbe "diamine, scrivere tre funzioni che interpolano i valori e chiamarli in base alla modalità impostata". Prima di tutto, questo significa che ho un problema di tipo: con cosa lavoro? I miei pixel PixelDataAmbient sono? PixelDataGouraud? PixelDataPhong? Oh, aspetta, dice l'efficiente programmatore C, usa un sindacato!

  typedef union tagSuperPixel {
      PixelDataAmbient a;
      PixelDataGouraud g;
      PixelDataPhong   p;
  } SuperPixel;

..e poi hai una funzione ...

  RasterizeTriangleScanline(
      enum mode, // { ambient, gouraud, phong }
      SuperPixel left,
      SuperPixel right)
  {
      int i,j;
      if (mode == ambient) {
          // handle pixels as ambient...
          int steps = right.a.x - left.a.x;
          float dv = (right.a.ambientLight - left.a.ambientLight)/steps;
          float currentIntensity = left.a.ambientLight;
          for (i=left.a.x; i<right.a.x; i++) {
              WorkOnPixelAmbient(i, dv);
              currentIntensity+=dv;
          }
      } else if (mode == gouraud) {
          // handle pixels as gouraud...
          int steps = right.g.x - left.g.x;
          float dred = (right.g.red - left.g.red)/steps;
          float dgreen = (right.g.green - left.a.green)/steps;
          float dblue = (right.g.blue - left.g.blue)/steps;
          float currentRed = left.g.red;
          float currentGreen = left.g.green;
          float currentBlue = left.g.blue;
          for (j=left.g.x; i<right.g.x; j++) {
              WorkOnPixelGouraud(j, currentRed, currentBlue, currentGreen);
              currentRed+=dred;
              currentGreen+=dgreen;
              currentBlue+=dblue;
          }
...

Senti che il caos sta scivolando dentro?

Prima di tutto, è sufficiente un errore di battitura per bloccare il mio codice, poiché il compilatore non mi fermerà mai nella sezione "Gouraud" della funzione, per accedere effettivamente a ".a". valori (ambientali). Un bug non rilevato dal sistema di tipo C (ovvero durante la compilazione) indica un bug che si manifesta in fase di esecuzione e richiederà il debug. Hai notato che sto accedendo a left.a.green Nel calcolo di "dgreen"? Il compilatore sicuramente non te lo ha detto.

Quindi, c'è ripetizione ovunque: il ciclo for è lì per tutte le volte che ci sono modalità di rendering, continuiamo a fare "destra meno sinistra divisa per passi". Brutto e soggetto a errori. Hai notato che ho confrontato usando "i" nel loop di Gouraud, quando avrei dovuto usare "j"? Il compilatore è di nuovo silenzioso.

Che dire dell'if/else/ladder per le modalità? Cosa succede se aggiungo una nuova modalità di rendering, tra tre settimane? Ricorderò di gestire la nuova modalità in tutto il "if mode ==" in tutto il mio codice?

Ora confronta la bruttezza sopra, con questo set di strutture C++ e una funzione template:

  struct CommonPixelData {
      int x;
  };
  struct AmbientPixelData : CommonPixelData {
      float ambientLight;
  };
  struct GouraudPixelData : CommonPixelData {
      float red;
      float green;
      float blue;  // The RGB color interpolated per pixel
  };
  struct PhongPixelData : CommonPixelData {
      float nX;
      float nY;
      float nZ; // The normal vector interpolated per pixel
  };

  template <class PixelData>
  RasterizeTriangleScanline(
      PixelData left,
      PixelData right)
  {
      PixelData interpolated = left;
      PixelData step = right;
      step -= left;
      step /= int(right.x - left.x); // divide by pixel span
      for(int i=left.x; i<right.x; i++) {
          WorkOnPixel<PixelData>(interpolated);
          interpolated += step;
      }
  }

Ora guarda questo. Non facciamo più una zuppa di tipo sindacale: ne abbiamo di tipi specifici per ogni modalità. Riutilizzano le loro cose comuni (il campo "x") ereditando da una classe base (CommonPixelData). E il template rende il compilatore CREATE (ovvero generare codice) le tre diverse funzioni che avremmo scritto in C, ma allo stesso tempo, essendo molto severi sui tipi!

Il nostro ciclo nel modello non può andare in giro e accedere a campi non validi - il compilatore abbaia se lo facciamo.

Il modello esegue il lavoro comune (il ciclo, aumentando di "passo" ogni volta) e può farlo in un modo che semplicemente NON può causare errori di runtime. L'interpolazione per tipo (AmbientPixelData, GouraudPixelData, PhongPixelData) viene eseguita con operator+=() che aggiungeremo nelle strutture - che sostanzialmente dettano come ogni tipo è interpolato.

E vedi cosa abbiamo fatto con WorkOnPixel <T>? Vogliamo fare lavori diversi per tipo? Chiamiamo semplicemente una specializzazione modello:

void WorkOnPixel<AmbientPixelData>(AmbientPixelData& p)
{
    // use the p.ambientLight field
}


void WorkOnPixel<GouraudPixelData>(GouraudPixelData& p)
{
    // use the p.red/green/blue fields
}

Cioè - la funzione da chiamare, viene decisa in base al tipo. In fase di compilazione!

Per riformularlo di nuovo:

  1. minimizziamo il codice (tramite il modello), riutilizzando parti comuni,
  2. non usiamo brutti hack, manteniamo un sistema di tipi rigoroso, in modo che il compilatore possa controllarci in ogni momento.
  3. e soprattutto: nulla di ciò che abbiamo fatto ha QUALSIASI impatto di runtime. Questo codice verrà eseguito SOLO più velocemente del codice C equivalente - in effetti, se il codice C utilizzava i puntatori a funzione per chiamare le varie versioni WorkOnPixel, il codice C++ sarà più veloce di C, perché il compilatore sarà in linea la chiamata di specializzazione del modello WorkOnPixel specifica del tipo!

Meno codice, nessun sovraccarico di runtime, più sicurezza.

Questo significa che il C++ è l'essere-e-e-tutto-dei-lingue? Ovviamente no. Devi ancora misurare i compromessi. Le persone ignoranti useranno C++ quando avrebbero dovuto scrivere uno script Bash/Perl/Python. I neofiti del C++ in grado di innescare creeranno classi annidate profonde con ereditarietà multipla virtuale prima che tu possa fermarle e inviarle a pacchetti. Utilizzeranno la meta-programmazione complessa Boost prima di rendersi conto che ciò non è necessario. Utilizzeranno ANCORA char*, strcmp e macro, anziché std::string E modelli.

Ma questo non dice altro che ... guarda con chi lavori. Non esiste un linguaggio per proteggerti dagli utenti incompetenti (no, nemmeno Java).

Continua a studiare e usare il C++ - semplicemente non sovrascrivere.

167
ttsiodras

RAII per il bambino vincitore.

Scherzi a parte, la distruzione deterministica in C++ rende il codice molto più chiaro e sicuro senza alcun sovraccarico.

79
Motti

C'è qualche motivo soddisfacente per usare il C++?

  1. Modelli e STL. Scambia un po 'di tempo di costruzione (e alcuni messaggi di errore potenzialmente incomprensibili) con un lotto di utili strumenti di astrazione e risparmio di manodopera, senza un apprezzabile riscontro delle prestazioni di runtime (sebbene l'impronta binaria possa essere un po' più grandi).

    Ci vuole un po 'di tempo per avvolgere la testa (mi ci sono voluti un paio d'anni prima di fare clic), ma una volta fatto può rendere la vita un lotto più semplice.

  2. L'elaborazione del testo in C++ è ordini di grandezza meno doloroso di quanto non sia in C.

70
John Bode

Sì.

Se stai cercando l'efficienza eseguibile, sei in C o C++, quindi mi concentrerò su quello.

Anche prima che i modelli fossero comuni, ho preferito usare C++ su C per i tipi di file eseguibili discussi già a metà degli anni '90 per due motivi molto semplici: polimorfismo degli oggetti e [~ # ~] raii [~ ~ #] .

Ho usato oggetti C++ polimorfici per tutti i tipi di cose interessanti. Ad esempio, stavo lavorando su un sistema Linux incorporato con overlay di frame buffer su OMAP e XScale ARM. Le due architetture hardware hanno funzionalità di overlay diverse con API molto diverse. Ho usato un virtuale comune " Overlay "classe base per esporre una vista idealizzata degli overlay, quindi ha scritto le classi" OmapOverlay "e" XScaleOverlay "che sono state istanziate in modo appropriato in fase di esecuzione, a seconda dell'architettura su cui il codice ha rilevato che era in esecuzione.

Per semplificare eccessivamente, RAII è l'idea di allocare risorse connesse a un oggetto durante il costruttore dell'oggetto, o forse più tardi nella vita dell'oggetto, e le risorse vengono deallocate o rilasciate nel distruttore dell'oggetto. È davvero bello in C++, perché gli oggetti che sono variabili automatiche vengono distrutti quando escono dall'ambito. Per qualcuno che è ugualmente competente in C e C++, è molto più facile evitare perdite di risorse e memoria in C++. Inoltre non vedi molto codice C++ con il meme C molto comune di un'etichetta alla fine di una funzione che precede un mucchio di chiamate a free() e vari goto nel blocco funzione saltando lì.

Sono pienamente consapevole del fatto che puoi fare tutte queste cose con C: è solo molto più lavoro, molte più righe di codice, e ciò che finisci è molto più brutto e spesso più difficile da capire. C'è un codice polimorfico in tutto X server internals, e man, è fugace e strano e spesso difficile da rintracciare.

Lavoro molto anche con le tecnologie GNOME come GTK + e Clutter, che sono tutte scritte in C usando il sistema GObject. GObject è come il sistema a oggetti C++ con la copertina Nice rimossa e tutti i brutti interni esposti, e di solito richiede una mezza dozzina di righe di codice per fare ciò che farebbe una chiamata al metodo C++ a una riga. Attualmente sto scrivendo un po 'di ClutterActors, e mentre la matematica è davvero interessante, penso costantemente: "Tutto ciò sarebbe molto più succinto e comprensibile in C++".

Spesso penso anche: "Sai, se stavo scrivendo questo in C++ invece di C, sarei fuori in salotto a guardare MythBusters con mia moglie invece di sedermi nel mio ufficio alle 21:00 ".

41
Bob Murphy

Il C++ è veloce quanto il C (alcune cose sono più veloci, altre più lente) e offre astrazioni e organizzazione migliori. Le classi funzionano in modo simile ai tipi primitivi, consentendo di utilizzare grandi quantità di codice senza tenerne conto. Il sovraccarico dell'operatore e i modelli consentono di scrivere codice che funzioni meglio se le rappresentazioni dei dati cambiano. Le eccezioni possono consentire una più facile gestione degli errori. Il compilatore può essere usato per controllare più cose in fase di compilazione.

Il prezzo che paghi per questo è una curva di apprendimento abbastanza brutta, ed è più facile commettere errori sottili rispetto alla maggior parte delle altre lingue che conosco.

Quindi, non posso dire se varrebbe la pena impararlo per quello che stai facendo ora. Puoi certamente cavartela con combinazioni di Python o Perl e C, ma C++ offre sia astrazione che prestazioni in un pacchetto difficile da abituare.

29
David Thornley

Considero il C++ come un linguaggio degli anni '90, un linguaggio di un'epoca passata.

Allora era grande perché offriva costrutti e meccanismi linguistici di livello superiore a un costo inferiore in termini di prestazioni. Era lo strumento universale per lo sviluppo di tutto, dalle applicazioni della rubrica al software avionico, e questo ha ispirato la OO mania. OOP ha risolto la fame e l'AIDS, e sì, Incolpo il C++ per aver cercato di farmi il lavaggio del cervello alla fine degli anni '90, quando ho iniziato a programmare che non vale la pena imparare qualsiasi linguaggio non OO.

Ora che l'hardware è avanzato così tanto e sono apparsi linguaggi moderni più moderni, non riesco a vedere il C++ che rimane una scelta rilevante per la maggior parte delle programmazioni applicative ad eccezione del software ad alta intensità computazionale in cui hai ancora bisogno di astrazione (giochi, simulazioni fisiche, CAD sistemi, ecc.) Anche quest'ultimo può essere evitato se si scrive un motore compatto e modulare in C e si dispone di una logica applicativa di livello superiore delegata a un linguaggio di script pulito.

Se devi scendere al metal usa C in modo sicuro e quando devi andare di alto livello, fallo in un linguaggio moderno che non pubblicizza l'incapsulamento mentre puoi modificare liberamente ogni byte tramite un puntatore.

28

Secondo Linus , no:

Quando ho guardato per la prima volta il codice sorgente di Git due cose mi sono sembrate strane: 1. C puro invece di C++. Non ho idea del perché. Per favore, non parlare di portabilità, è BS.

[~ # ~] tu [~ # ~] sei pieno di cazzate.

Il C++ è un linguaggio orribile. È reso più orribile dal fatto che molti programmatori scadenti lo usano, al punto che è molto più facile generare cazzate totali e assolute. Francamente, anche se la scelta di C dovesse fare nulla ma tenere fuori i programmatori C++, questo di per sé sarebbe un motivo enorme per usare C.

In altre parole: la scelta di C è l'unica scelta sana. So che Miles Bader ha scherzosamente detto "per farti incazzare", ma in realtà è vero. Sono giunto alla conclusione che qualsiasi programmatore che preferirebbe che il progetto fosse in C++ su C è probabilmente un programmatore che io preferirei preferirei pisciare spento, in modo che non venga e rovini qualsiasi progetto con cui sono coinvolto.

Il C++ porta a scelte di progettazione davvero pessime. Inevitabilmente inizi a utilizzare le funzioni di libreria "Nice" del linguaggio come STL e Boost e altre cazzate totali e totalmente, che possono "aiutare" a programmare, ma causano:

  • quantità infinita di dolore quando non funzionano (e chiunque mi dica che STL e soprattutto Boost sono stabili e portatili è così pieno di BS che non è nemmeno divertente)

  • modelli di programmazione astratti inefficienti in cui due anni dopo notate che alcune astrazioni non erano molto efficienti, ma ora tutto il codice dipende da tutti i modelli di oggetti Nice attorno ad esso e non è possibile risolverlo senza riscrivere l'app.

In altre parole, l'unico modo per fare C++ buono, efficiente, a livello di sistema e portatile finisce per limitarti a tutte le cose che sono sostanzialmente disponibili in C. E limitare il tuo progetto a C significa che le persone non lo rovinano e significa anche che hai un sacco di programmatori che in realtà comprendono problemi di basso livello e non rovinano le cose con qualsiasi idiota schifezza da "modello a oggetti".

Quindi mi dispiace, ma per qualcosa come git, in cui l'efficienza era un obiettivo primario, i "vantaggi" del C++ sono solo un errore enorme. Il fatto che anche noi incazziamo le persone che non riescono a vederlo è solo un grande vantaggio aggiuntivo.

Se vuoi un VCS scritto in C++, gioca con Monotone. Veramente. Usano un "database reale". Usano "Belle librerie orientate agli oggetti". Usano "Nice C++ abstract". E francamente, come risultato di tutte queste decisioni di progettazione che sembrano così attraenti per alcune persone CS, il risultato finale è un disastro orribile e irraggiungibile.

Ma sono sicuro che ti piacerebbe più di Git.

      Linus
21
Jeremy Heiler

Non credo che ci sia alcun motivo convincente per usare il C++. Se vuoi fare OO programmazione, puoi usare Python invece e scrivere le parti che richiedono prestazioni veloci in C.

EDIT: ci sono altri linguaggi che si interfacciano bene con C, quindi se non ti piace Python, ci sono alternative.

18
Larry Coleman

C'è un motivo per usare il C++? Certamente.

Alcune persone potrebbero semplicemente preferire usare C++ su altre opzioni. Chiedere se c'è un motivo per usare il C++ è come chiedersi perché dobbiamo avere centinaia di gusti di gelato. Non a tutti piace semplicemente attenersi alla Vaniglia.

Se gli sviluppatori sono già molto competenti con il C++, la loro domanda potrebbe non essere "perché usarlo?", Ma piuttosto "perché no?". Sembra che ci sia questa cosa alla moda anti-C++ in corso in SO in questo momento, ma ci crediate o no, non tutti si abbonano a questo. Alcune persone potrebbero semplicemente apprezzare il C++ meglio delle altre lingue.

C++ deve essere utilizzato per le app? Ovviamente no. Ma questa stessa domanda esatta può essere fatta anche per qualsiasi altra lingua. Esistono pochissimi casi in cui una determinata lingua deve essere utilizzata per un'applicazione.

13
GrandmasterB

Sto passando da C a C++ e penso che il guadagno sia considerevole, anche se non hai bisogno di template e OOP.

  • Migliore gestione della memoria
  • Sistema di tipo più forte
  • Una libreria standard migliore
  • Namespace
  • eccetera.
12
Oliver Weiler

Sono sorpreso che nessuno lo abbia ancora menzionato, ma C++ ci ha introdotto a riferimenti , che quasi risolvono tutti i problemi e le insidie ​​dei puntatori:

void ModifyVar(int& var)
{
    var = 5;
}

int test = 4;
ModifyVar(test);

Invece di:

void ModifyVar(int * var)
{
    *var = 5;
}

int test = 4;
ModifyVar(&test);

Molto più sicuro e anche più facile ... e senza il sovraccarico del passaggio per valore.

8
Nathan Osman

Il dove e perché di solito saranno:

  • familiarità
  • funzionalità linguistiche desiderate
  • librerie specifiche che si desidera utilizzare
  • requisiti di prestazione

Per la programmazione lato server puoi spesso scegliere tra una miriade di lingue diverse, compilate o interpretate. Di solito la scelta della lingua dipende dalla piattaforma su cui tu o il tuo team sarete più efficaci. O se non hai ancora una squadra, la disponibilità di competenze sul mercato.

In una nota a margine non capisco davvero di decidere di usare C/C++ in base alle prestazioni (solo) poiché molti linguaggi di scripting sono estensibili con C/C++. Ottieni il vantaggio di un linguaggio di sviluppo rapido unito alla capacità di migrare le porzioni lente in estensioni C/C++. Certamente se stai programmando sistemi in cui ogni operazione conta è comprensibile, ma nella maggior parte dello sviluppo di app non capisco.

5
dietbuddha

C++ vs Python vs Perl non può essere giudicato facilmente. Dipende dal progetto e dai requisiti.

C++ ha un arsenale di utility di molto tempo fa, in esecuzione su molte piattaforme. Ma è doloroso iniziare a camminare attraverso i flussi semplicemente passando String a Integer e viceversa.

Il C++, d'altra parte, ha un pessimo accordo con le dipendenze dalle librerie. Una volta compilato qualcosa in GCC X o VC++ Y, non puoi fare affidamento sul fatto che il codice verrà eseguito dalla versione successiva di quegli strumenti. Lo stesso inferno è su Windows, lo stesso inferno è anche su Unix.

Perl, prende il potere dal mondo Unix ma soprattutto come strumento di espressione regolare. Questo è ciò che viene utilizzato la maggior parte del tempo. Insieme ad alcuni strumenti piuttosto seri che persino Java non può farlo normalmente (controlla come caricare un file su un server web), Perl è "fallo".

Python è facile, flessibile e un linguaggio dinamico. Così facile che puoi inviare un numero intero a una funzione, lo script si aspetta una stringa, ma puoi avere un risultato! Inaspettato però, ma un risultato. Quindi il programmatore deve essere molto cauto. INATTIVO offre un po 'di debug, ma quando TELNET è su un sistema o SSH su tre livelli in basso e vuoi trovare il tuo problema, il il debugger non sarà lì per stare accanto a te. Ma può fare un ottimo lavoro di matematica veloce.

Java è un ecosistema di parole d'ordine, tecnologie aliene e parole grosse e quando vuoi semplicemente caricare un file sul server web, scopri che puoi farlo solo se il server ha JSP . Se vuoi chiamare librerie di sistema o funzioni di sistema come il monitoraggio, scopri che devi scavare molto. E forse per raggiungere JNI e OK ... pensi poi ... "Perché, Signore?"

A parte questo, Java è un ottimo strumento per le suite business e il multithreading, mi è piaciuto molto.

Velocemente per fare un programma e mostrare al tuo CV "Oh, lo so anche quella tecnologia" e il tuo aspirante capo, lasciati stupire! Anche se la tecnologia potrebbe non essere quella necessaria ... (OK, gente, odio Spring Framework ....)

4
hephestos

Linux? Che dire di "Pascal orientato agli oggetti" o "D"?

Suggerimenti:

3
mramirez

La cosa da tenere a mente quando si sceglie una lingua, è quale beneficio otterrai dall'usarla e quanto tempo ci vorrà per ottenerla.

L'idea principale tra linguaggi come python e Perl è fare di più con meno tempo di lavoro, ma con più tempo di CPU. In effetti passerai più tempo a programmare uno script python o Perl di quanto non verrà eseguito, ma ottieni il mio punto.

Il vantaggio di C/C++ è che sono veloci, ma a un costo di sintassi e digitazione forte: devi fare molto da te in modo che il computer non debba sceglierlo al momento della compilazione.

Quando crei un codice, alcune righe verranno eseguite molto più di altre e quelle righe sono quelle che rappresentano un problema. D'altra parte, tutto il resto del codice, quello su cui hai trascorso molto tempo, viene eseguito molto meno spesso. Potresti averlo sentito, ma è la famigerata regola 80/20 e non sarai in grado di bypassare tale regola.

La soluzione a questo problema è quella di utilizzare un linguaggio più semplice (più semplice intendo più amichevole per gli sviluppatori: meno digitazione, interpretazione pigra, molte routine e cose preesistenti, ecc.) Per fare tutto il codice.

Lo farai così rapidamente rispetto a se lo avessi fatto con C o C++, ci sarebbe voluto molto più dolore al cervello.

Il tuo programma sarà lento, ma con un profiler, isolerai la parte eseguita l'80% delle volte e li eseguirai con C o C++.

Pregando in questo modo, hai risparmiato molto tempo e il tuo programma è tanto efficiente, tanto veloce, ha molte meno possibilità di perdere memoria e hai risparmiato tempo.

I linguaggi di scripting sono stati progettati per essere dalla parte dello sviluppatore, ma l'ottimizzazione è ancora possibile. Ovviamente puoi essere un mago del modello di progettazione o un voodoo STL o persino un guerriero LISP e forse un monaco haskell. Ma le lingue ci fanno parlare con i computer, le lingue non sono fatte per noi BE computer!

3
jokoon

Il C++ che uso si chiama C con le classi!

2
willspeak

No, per niente. Se non hai bisogno delle prestazioni e c'è una libreria che puoi usare l'altra lingua, non preoccuparti di C/C++. Lo faccio solo al giorno d'oggi quando prendo di mira sistemi embedded che non possono (facilmente?) Eseguire lingue. A volte uso C perché sto scrivendo un plugin, ma davvero no.

Tuttavia, non vorrei usare Python, Perl, ecc. Per evitare di usare C. La mia preferenza è in realtà C #, perché mi piace una buona libreria (che è un punto di forza di .NET) e mi piacciono i linguaggi tipizzati staticamente. Boo è una buona alternativa. Ma davvero Haskell , OCaml , D , ML e tutto va bene.

0
user2528

In realtà c'è una sola risposta a tutte le domande formate in questo modo. Il miglior motivo per usare la tecnologia X invece della tecnologia Y (dove X e Y sono approssimativamente allo stesso livello [come quasi tutti i linguaggi di programmazione contemporanei sono]) è perché conosci già X e non conosci Y.

(ma dopo l'arrivo di Haskell, non c'è stato motivo di usare nient'altro)

0
vegai