C Test CUNIT

[nasio91]

Salve signori è da ore che sto sbattendo la testa su sta cosa

#include <stdio.h>
#include <stdlib.h>
#include "CUnit/Basic.h"

int fattoriale (int num)
{
int i;
int fatt=1;

for(i=num;i>1;i--)
{
fatt=fatt*i;
}
return fatt;

}

void test_fattoriale (void)
{
CU_ASSERT_EQUAL (fattoriale (4), 12 );
CU_ASSERT (fattoriale (3) == 6);
CU_TEST (fattoriale (6) == 720);
}




int main(void)
{
test_fattoriale();
return 0;
}


Quando compila da sempre questo errore sui test "undefined reference to CU_assertimplementation"

Come ambiente uso Eclipse che è obbligatorio per questo esamino che devo preparare, qualcuno sa come posso risolvere? Grazie anticipatamente a chiunque risponderà

[nasio91]

Originariamente inviato da Antonio23

devi imparare a usare il linker...

questo per quelli che "bisogna iniziare a programmare usando visual studio etc"..

Ok ho aggiunto le librerie cunit e cunit_dll, adesso il problema non si presenta più, però per qualche strano motivo compila e crasha

[71106]

Originariamente inviato da Antonio23

devi imparare a usare il linker...

questo per quelli che "bisogna iniziare a programmare usando visual studio etc"..

LOL

[tomminno]

Originariamente inviato da nasio91

Ok ho aggiunto le librerie cunit e cunit_dll, adesso il problema non si presenta più, però per qualche strano motivo compila e crasha

Hai provato in debug?

[71106]

Originariamente inviato da coffe_killer

La mia era solo una battuta, tranquillo.....non siate sempre così suscettibili quando si parla di questi argomenti

Abbi pazienza ma e' un continuo martellare, sia sui forum che dal vivo... I fanatici di questi IDE mufloni sono ovunque.

Ti sorprenderebbe sapere quanto e' produttiva la gente che usa vim e compila da linea di comando, te lo garantisco.

[tomminno]

Originariamente inviato da Antonio23

devi imparare a usare il linker...

questo per quelli che "bisogna iniziare a programmare usando visual studio etc"..

Io ho cominciato a sviluppare con DJGPP sotto DOS, ma come funziona il processo di compilazione per C/C++ te lo spiegavano a lezione. Anche perchè faceva parte del programma di esame.

[tomminno]

Originariamente inviato da 71106

Abbi pazienza ma e' un continuo martellare, sia sui forum che dal vivo... I fanatici di questi IDE mufloni sono ovunque.

Ti sorprenderebbe sapere quanto e' produttiva la gente che usa vim e compila da linea di comando, te lo garantisco.

Intato il problema del linker l'ha risolto in un attimo a quanto pare

[71106]

Originariamente inviato da tomminno

Intato il problema del linker l'ha risolto in un attimo a quanto pare

Non mi sembra. E comunque per certa gente non esistono i cosiddetti "problemi col linker". Io invece appartengo a una categoria intermedia: di problemi col linker ne avevo solo quando usavo Visual Studio.

[71106]

Originariamente inviato da tomminno

Io ho cominciato a sviluppare con DJGPP sotto DOS, ma come funziona il processo di compilazione per C/C++ te lo spiegavano a lezione. Anche perchè faceva parte del programma di esame.

Ai miei corsi di programmazione ci hanno espressamente detto di non usare Visual Studio e in generale altri IDE, quindi anche saper usare editor di testo semplice e linea di comando era parte del programma d'esame.

[71106]

Originariamente inviato da coffe_killer

Dipende sempre da cosa uno debba fare. Io senza le features di visual studio farei fatica ora a lavorare, vista l'infinità di tool e la comodità, nonostante in università gli IDE fossero quasi banditi. Non vedo dove sia il problema del linker, e non capisco onestamente chi definisce visual studio "il male".

Ai tempi in cui seguivo io i corsi di programmazione, Visual Studio oggettivamente era il male (parliamo della versione 6) perche' il compilatore non aderiva strettamente allo standard del C++ e di conseguenza era il modo giusto per imparare un C++ leggermente diverso e oggettivamente sbagliato. E parlo di cose piuttosto basilari come lo scope delle variabili di iterazione dei cicli for. Il fix di questa feature nelle versioni successive di Visual Studio ha di fatto creato un'incompatibilita' coi sorgenti preesistenti.

A livello accademico, ti fanno usare editor e basta per farti le ossa, poi sul lavoro invece, dove si predilige la produttività, l'utilizzo degli IDE è un passaggio pressochè obbligato.

Non sempre: dove lavoro io e' il contrario.

(a parte che non usiamo tecnologie Microsoft e quindi Visual Studio sarebbe comunque fuori gioco, e che i nostri vim sono talmente "aumentati" con plugin vari da essere quasi degli IDE, pero' continuiamo sempre a compilare da linea di comando)

[71106]

Originariamente inviato da Antonio23

un IDE maschera tutto cio' che avviene dalla scrittura del sorgente alla formazione del binario. comunque non ho detto che non bisogna mai usare IDE, ma quando qualcuno arriva a dover aprire un topic su un forum perche' non capisce cosa possa andar male, vuol dire che l'uso di un IDE maschera dei dettagli vitali durante l'apprendimento.

Quoto e aggiungo: non solo durante l'apprendimento. Certe volte ti serve di esaminare quei dettagli, e l'IDE te lo rende piu' difficile.

[71106]

Originariamente inviato da coffe_killer

Suo discorso Vim, ok che non è un ide, ma come avete detto, con tutti i plugin installati praticamente lo è, quindi indirettamente anche chi usa Vim "pimpato" usa un ide....

Con qualche piccola differenza come: si avvia in un nanosecondo, richiede un epsilon delle risorse di Visual Studio, si limita a fornire quell'1% di feature che servono a noi, e non nasconde il processo di build.

[71106]

Originariamente inviato da coffe_killer

Sempre discorso degli usi che si fanno, noi VS lo utilizziamo per il fantastiliardo di funzioni che offre, e noi ne usiamo davvero tante.

Auguri.

[tomminno]

Originariamente inviato da 71106

Ai tempi in cui seguivo io i corsi di programmazione, Visual Studio oggettivamente era il male (parliamo della versione 6) perche' il compilatore non aderiva strettamente allo standard del C++ e di conseguenza era il modo giusto per imparare un C++ leggermente diverso e oggettivamente sbagliato. E parlo di cose piuttosto basilari come lo scope delle variabili di iterazione dei cicli for. Il fix di questa feature nelle versioni successive di Visual Studio ha di fatto creato un'incompatibilita' coi sorgenti preesistenti.



Non sempre: dove lavoro io e' il contrario.

(a parte che non usiamo tecnologie Microsoft e quindi Visual Studio sarebbe comunque fuori gioco, e che i nostri vim sono talmente "aumentati" con plugin vari da essere quasi degli IDE, pero' continuiamo sempre a compilare da linea di comando)

Perchè non usate dei buildserver?
Non vedo tutto questo problema nel compilare schiacciando un tasto piuttosto che aprire una shell e avviare uno script di compilazione. Che poi è quello che fanno tutti gli IDE eh! Perchè non vorrai dirmi che ogni volta digiti a mano la linea di comando per compilare vero?

[tomminno]

Originariamente inviato da Antonio23

un IDE maschera tutto cio' che avviene dalla scrittura del sorgente alla formazione del binario. comunque non ho detto che non bisogna mai usare IDE, ma quando qualcuno arriva a dover aprire un topic su un forum perche' non capisce cosa possa andar male, vuol dire che l'uso di un IDE maschera dei dettagli vitali durante l'apprendimento.

Secondo me vuol semplicemente dire non aver studiato...

[tomminno]

Originariamente inviato da Antonio23

un IDE maschera tutto cio' che avviene dalla scrittura del sorgente alla formazione del binario. comunque non ho detto che non bisogna mai usare IDE, ma quando qualcuno arriva a dover aprire un topic su un forum perche' non capisce cosa possa andar male, vuol dire che l'uso di un IDE maschera dei dettagli vitali durante l'apprendimento.

L'argomento di esame era il linguaggio C/C++ non gcc, quindi dovevi conoscere le nozioni che stanno dietro al linguaggio non i parametri per compilare da linea di comando con gcc. Non usare l'IDE ti obbliga a conoscere i parametri di una particolare implementazione di compilatore C, ma di compilatori C era pieno il mondo e non potevi conoscerli tutti.

[tomminno]

Originariamente inviato da 71106

Auguri.

Ecco un elenchino di funzionalità che dubito manchino in qualunque flusso di programmazione:
Code browsing, Refactoring, Debugger, Profiler, Unit Testing, SCV, Code Validator, Issue tracker (forse questa proprio comune non è)

Se devo prendere un editor di testo e aggiungere tutte queste funzionalità, beh alla fine ho ricreato un IDE. Tanto vale che utilizzi uno strumento integrato piuttosto che avere un'accozzaglia di plugin non pensati per funzionare insieme.

[tomminno]

Originariamente inviato da Antonio23

mm, non ho capito. l'esame al massimo e' Informatica I, non linguaggio C/C++. Perche' se fosse stato linguaggio C/C++ non ti avrebbero nemmeno dovuto insegnare cosa sia un compilatore, ma solo a fare programmi carta e penna.

Una parte di Informatica I e' studiare il processo di compilazione, linking e loading (ai miei tempi), se lo fai fare all'IDE non vedo l'utilita' di studiarlo, se non lo fai fare all'IDE sei costretto a studiarlo.

L'esame era comporto dalla parte teorica, quindi tutti i dettagli per passare da un file di testo col sorgente ad un binario (più altre cose tipo grammatiche regolari e roba simile), e dalla parte pratica, insegnata col C/C++. Ma una volta che ti eri studiato la teoria sul libro, premere play su un IDE o digitare a mano una riga di comando chilometrica non faceva nessuna differenza, anche perchè per la pratica eri valutato per i file sorgente scritti, non per gli eventuali script di compilazione.
A cosa serve studiare (parlo di università, non lavoro) i dettagli dei parametri da riga di comando di un compilatore, visto che ogni compilatore ha le sue opzioni? -O3 o /O2 fa veramente differenza?

[71106]

Originariamente inviato da tomminno

Perchè non usate dei buildserver?

Nel nostro caso e' un po' sciocco chiamarli cosi' ma si, diciamo che ne usiamo. Cio' che forse ti sorprendera' e' che sono del tutto indipendenti dall'IDE.

Non vedo tutto questo problema nel compilare schiacciando un tasto piuttosto che aprire una shell e avviare uno script di compilazione.

man tmux. La shell e' gia' aperta.

Il motivo per cui il bottone e' male e' gia' stato esemplificato da Antonio23. Incidentalmente, anche noi usiamo build system personalizzati.

Che poi è quello che fanno tutti gli IDE eh! Perchè non vorrai dirmi che ogni volta digiti a mano la linea di comando per compilare vero?

Si. Se credi che sia lunga una quaresima ti sbagli perche' sei abituato a Visual Studio. Esistono i makefile / buildfile / analoghi.

Originariamente inviato da tomminno

L'argomento di esame era il linguaggio C/C++ non gcc, quindi dovevi conoscere le nozioni che stanno dietro al linguaggio non i parametri per compilare da linea di comando con gcc. Non usare l'IDE ti obbliga a conoscere i parametri di una particolare implementazione di compilatore C, ma di compilatori C era pieno il mondo e non potevi conoscerli tutti.

Fortunatamente la command line di quella fogna di gcc e' abbastanza standard, difatti quella di clang e' compatibile. Ad ogni modo non era uno spreco di tempo impararla all'universita' insieme al linguaggio, anzi: giocare coi flag forniva un'idea molto piu' chiara del processo di compilazione.

Originariamente inviato da tomminno

Ecco un elenchino di funzionalità che dubito manchino in qualunque flusso di programmazione:
Code browsing, Refactoring, Debugger, Profiler, Unit Testing, SCV, Code Validator, Issue tracker (forse questa proprio comune non è)

Ma non c'e' motivo di ammassare tutto in un unico software che gira in locale e per essere avviato ha bisogno di caricare tutto, anche se per quella giornata ne userai solo l'1%. Qui da noi le feature che dici sono implementate da servizi che girano sui server e a cui accediamo tramite il browser, per cui in locale facciamo girare solo vim e Chrome.

[tomminno]

Originariamente inviato da 71106

Nel nostro caso e' un po' sciocco chiamarli cosi' ma si, diciamo che ne usiamo. Cio' che forse ti sorprendera' e' che sono del tutto indipendenti dall'IDE.

Si io mi riferivo al fatto che in certi contesti lo sviluppatore nemmeno compila, lo fa il buildserver per lui

Si. Se credi che sia lunga una quaresima ti sbagli perche' sei abituato a Visual Studio. Esistono i makefile / buildfile / analoghi.

E perchè un progetto visual studio cosa credi che sia? Visual Studio non è altro che un editor grafico di "makefile".
Comunque devi studiarti le opzioni di compilazione o del linker, specialmente per le ottimizzazioni (cosa che a livello universitario difficilmente serve) e devi sapere che se hai a che fare con librerie esterne come andare a configurarle, ma questa è proprio la base. Sicuramente in C# è più semplice che con C++

Fortunatamente la command line di quella fogna di gcc e' abbastanza standard, difatti quella di clang e' compatibile. Ad ogni modo non era uno spreco di tempo impararla all'universita' insieme al linguaggio, anzi: giocare coi flag forniva un'idea molto piu' chiara del processo di compilazione.

Nel 2000 credo che clang nemmeno esistesse

Ma non c'e' motivo di ammassare tutto in un unico software che gira in locale e per essere avviato ha bisogno di caricare tutto, anche se per quella giornata ne userai solo l'1%. Qui da noi le feature che dici sono implementate da servizi che girano sui server e a cui accediamo tramite il browser, per cui in locale facciamo girare solo vim e Chrome.

Gli IDE sono semplicemente dei frontend, ovvio che la parte server dei servizi non gira a bordo della macchina del singolo sviluppatore.
Trovarsi tutte le funzioni integrate e pensate appositamente per funzionare insieme all'interno di un unico software agevola la vita.
Debug e Refactoring come li fate con Vim? Dubito seriamente che siano possibili con Chrome

Che poi non capisco chi mai non userebbe un IDE per sviluppare in C# o Java? E non vedo perchè complicarsi ancora di più la vita in C++.