[C] Compitino informatica dove sono gli errori??

[tory_debra]

Nono mai studiato su wikipedia... Ho gli appunti e il libro di aguilar solo che non c'era scritto da nessuna parte come verificare se malloc fosse andato a buon fine così ho cercato su internet ed è saltato fuori wikipedia

[vaeVictis]

Nono mai studiato su wikipedia... Ho gli appunti e il libro di aguilar solo che non c'era scritto da nessuna parte come verificare se malloc fosse andato a buon fine così ho cercato su internet ed è saltato fuori wikipedia

Ci sono altre fonti online. Io per esempio ho trovato molto buone queste due.
cplusplus
cpplearn

[vaeVictis]

dato che wikipedia non sostituisce un buon manuale che insegnerebbe

Codice: Seleziona tutto

if ( !(array = malloc(n * sizeof(double)) )

Ne approfitto per farti una domanda, vbextreme. Te la stavo facendo in privato, ma forse è meglio parlarne qui. Non credo sia OT, anzi.
Mi chiedevo, siamo sicuri che quell'istruzione, per il controllo, sia preferibile a questa

Codice: Seleziona tutto

if ( (myArray =(double *) malloc (myArraySize * sizeof(double))) == NULL )

?

[M_A_W_ 1968]

Mi chiedevo, siamo sicuri che quell'istruzione, per il controllo, sia preferibile a questa

Codice: Seleziona tutto

if ( (myArray =(double *) malloc (myArraySize * sizeof(double))) == NULL )

?

Domanda retorica.
Le norme di stile, a cominciare dalla basilare MISRA/C 2012, impongono in particolare tre regole che dirimono definitivamente la questione, più una che discuteremo in calce, chiamata in causa indirettamente dal codice sopra citato.

1) Il confronto implicito con lo zero (e valori assimilabili) è esplicitamente proibito, eccetto il caso di variabili di tipo booleano (supportato apertamente dagli standard successivi al C'89, e comunque emulabile tramite enum con un preciso e diffuso idioma).

2) I valori di ritorno delle funzioni di libreria (e UDF) devono essere sistematicamente controllati.

3) Assegnazione e controllo devono essere mantenuti rigorosamente separati. Quindi l'unica forma ammissibile in un buon codice è in realtà la seguente:

Codice: Seleziona tutto

    myArray = (double *)malloc (myArraySize * sizeof(double));
    if (NULL == myArray)
    {
        ...
    }

Nessuna preoccupazione inerente le prestazioni deve inficiare l'uso sistematico di tale idioma, anche nei casi limite in cui si usa esplicitamente una variabile temporanea altrimenti non necessaria.

4) Nei confronti tra una variabile (possibile lvalue) e una costante, è sempre opportuno anteporre quest'ultima, in modo da trasformare in un errore sintattico (una costante non può essere un lvalue) quello che è invece un potenziale errore semantico in caso della fin troppo frequente involontaria sostituzione di "==" con "=".

[vaeVictis]

Non pensavo di essere pizzicato così fragorosamente nel mio essere retorico, la prossima volta cercherò di essere più criptico
Grazie per il chiarimento al punto 3). Era quello che chiedevo, non sapendo però che le due cose dovessero essere tenute separate proprio per norme di stile.

Grazie anche per l'ulteriore chiarimento nel punto 4). Avevi già scritto un messaggio in cui sottolineavi l'importanza di porre la costante a sinistra dell'operatore ==, ma non ne avevo capito le motivazioni e non avevo mai avuto modo di chiederti lumi, cosa che ho fatto ora con il mio precedente messaggio di evocazione del M_A_W, che a quanto pare ha funzionato

[tory_debra]

avrei di nuovo bisogno di aiuto...

Codice: Seleziona tutto

#include <stdio.h>
#include <stdlib.h>
#include "/home/tori/Scrivania/es.h"
int main ()
{
	struct punto a [2];
	int scelta = 0;
	int i;

	

	while (scelta!=5)
	{
		printf ("1 inserisci coord\n");
		printf ("2 cancella coord\n");
		printf ("3 media delle x, y o z\n");
		printf ("4 modulo di uno dei punti\n");
		printf ("5 esci\n");
		scanf ("%d", &scelta);
	
		switch (scelta)
		{
			case 1:
			{
				inserisci (a);
				break;
			}
			case 2:
			{
				cancella (a);
				break;
			}
			case 3:
			{
				media (a);
				break;
			}
			case 4:
			{
				/* modulo (a); */
				break;
			}
			case 5:
			{
				break;
				
			}
			default:
			{
				printf ("inserire scelta valida \n");
				break;
			}
		}
		
		for (i=0;i<3;i++)
		{
			printf ("coord x punto %d: %.2f\n", i+1, a[i].x);
			printf ("coord y punto %d: %.2f\n", i+1, a[i].y);
			printf ("coord z punto %d: %.2f\n\n", i+1, a[i].z);
		}
	}
	return 0;
}

le funzioni funzionano...
se appena avviato il programma si preme 5 esce senza problemi, mentre se prima inserisco i dati (con l'opzione 1) e poi voglio uscire con 5 mi da un errore di segmentazione (con annesso core dump) e poi esce. perchè?

[vbextreme]

il mio reference recita:

La conversione forzata non è piu necessaria [...] e potenzialmente dannosa se malloc o una funzione che ne fa le veci non è dichiarata void*. Il cast esplicito può impedire il rilevamento di un errore nel codice.D'altro canto, prima dell'avvento dello standard ANSI, la conversione forzata del tipo era realmente necessaria, e continua ad esserlo nel c++

Mi farebbe piacere trovare la riga dell'ANSI/ISO cui recita il contrario.

Ricordando che NULL altro non è che una define dal valore 0 ed avendo una variabile puntatore a double(non una variabile boleana, ne tantopiu impementata con l'enum{FALSE,TRUE}) otteniamo un confronto fra variabile e 0 quindi non permesso.

La forma:

Codice: Seleziona tutto

if ( !array )

è comunque preferibile proprio per non incorrere nel classico errore:

Codice: Seleziona tutto

if ( array = NULL )

invertire dunque il NULL o dimenticarsi un segno di ugualianza è fin troppo facile e quindi da evitare il piu possibile

[quasi dimenticavo]

What is MISRA ?

MISRA's Mission Statement

To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software.

MISRA, The Motor Industry Software Reliability Association, is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles and other embedded systems. To this end MISRA publishes documents that provide accessible information for engineers and management, and holds events to permit the exchange of experiences between practitioners.

Le linee guida del MISRA sono dunque indirizzate ai sistemi embedded ed non sembra essere uno standard a largo spettro quale l'ANSI/ISO.
Non fraintendete è ottimo leggere entrambi ma io mi chiedo, fino a che punto uno standard indirizzato ai sistemi embedded possa essere valido sui computer normali?
[/quasi dimenticavo]

[vaeVictis]

La cosa che non mi convince, vbextreme, è
1) in questo modo si sfrutta l'essere "falsy" dell'array, usato come condizione di un if?
2) La negazione di una struttura dati, a livello di performance... rispetto alla verifica che il puntatore non sia "NULL"... non è meno performante?

[vbextreme]

1) la negazione di una variabile trasforma il suo risultato in un tipo booleano dunque !ptrdouble sarà trasformato in boleano (teoricamente) e poi testato, non usando il ! non trasformiamo la variabile in boleana ed utilizziamo (in questo caso) un confronto tra un puntatore a double e uno 0.
2) Naturalmente le perforance potrebbero risentirne, ma in questi anni ho imparato che qualche nanosecondo in meno è meglio che un probabile bug in futuro.

Vorrei ricordarti che essendo NULL una define potrebbe benissimo accadere:

Codice: Seleziona tutto

#undef NULL
#define NULL 1

Anche se illogico(ma la mente umana può andare ben oltre a questo...) è tuttavia fonte di possibili errori IMPOSSIBILI da trovare

[tory_debra]

se ho capito quello di cui state parlando... il malloc ritorna un NULL (o zero vabbè) se fallisce quindi non c'è bisogno di trasformare in un tipo bool con il ! ...

[vbextreme]

@tory_debra il discorso è molto piu sottile....
questione di stile, ma alla fine funzionano tutte.

struct s *p = malloc(sizeof (struct s) + sizeof (double [m]));
...
...
The expression !E is equivalent to (0==E).

[M_A_W_ 1968]

il mio reference recita:
[...]
mi chiedo, fino a che punto uno standard indirizzato ai sistemi embedded possa essere valido sui computer normali?

Abbiamo avuto modo di tornare su questi argomenti a più riprese. All'epoca dei miei studi, questi concetti erano oggetto della prima lezione in qualsiasi corso di programmazione in linguaggio C: a quanto pare, non è più così.

A causa delle condizioni disagiate nelle quali compongo questo messaggio, e del numero iperbolico di ripetizioni di questa vera e propria FAQ (anche su questi stessi forum), mi limiterò ad accennare per l'ennesima volta i capisaldi della questione.

I riferimenti obbligatori per un generico programmatore in linguaggio C, su qualsivoglia piattaforma, sono:

1) Lo standard di codifica aziendale. In sua vece, uno standard di codifica di terze parti, ovvero in mancanza di meglio un generico manuale di stile (come quelli citati qui).

2) I manuali dell'ambiente di sviluppo. Il fatto che siano cartacei, in PDF, o in un qualsivoglia formato di help online è ovviamente irrilevante. Purché siano aggiornati, fatto che non deve ovviamente darsi per scontato.

3) Un reference della libreria standard o altro manuale per la consultazione, affiancato da eventuali testi applicativi e di algoritmica (si veda ad esempio, su tutti, il Sedgewick "Algoritmi in C").

Si nota immediatamente che nel sintetico elenco non compare lo standard del linguaggio. E questo avviene per il banale motivo che gli standard, specialmente C'99 e C'11, non sono destinati in alcun modo al generico sviluppatore, ma solamente ad una ristrettissima platea di specialisti che si occupano, nell'ordine, di produrre compilatori, preprocessori, librerie, parser e altri tools, nonché per quei pochissimi sfigati che, lungi dal rappresentare un Olimpo informatico, sono in qualche modo costretti ad affrontare spinosissime problematiche di porting tra compilatori e piattaforme eterogenee, senza però avere la possibilità di fare ricorso a frameworks appositamente concepiti e altri validi strumenti per il cross-platform development.

Sfortunatamente nel mondo scolastico e accademico, per motivazioni molto varie ma invariabilmente fallaci, si ritiene che fare appello allo standard (e, peggio mi sento, al più recente standard disponibile) sia una Via Regia per la conoscenza universale del linguaggio C. Non è così, anzi nulla vi è di più deleterio e deformante che inculcare simili idee.
Lo standard non vi spiega come dovete scrivere il codice: anzi, al contrario! Nella sua genericità, esso può permettersi di ignorare problematiche fondamentali nell'engineering (ma se vogliamo "locali") come prestazioni, leggibilità e robustezza, limitandosi invece a chiarire quali idiomi devono essere accettati da un compilatore, quali sono gli aspetti dipendenti dall'implementazione, eccetera, astraendo dalle reali problematiche delle singole piattaforme, dai problemi della implementazione di determinate funzioni e famiglie di funzioni della libreria standard, eccetera eccetera eccetera.
Inoltre, la mera promanazione degli standard non significa in alcun modo che il codice nel mondo reale si adegui immediatamente. Una stima ragionevole della base di codice C esistente ci dice, infatti, che la ripartizione si conforma a quanto segue:

C'89: 99,5%
C'99: 0,4999%
C'11: tracce insignificanti.

Peraltro, almeno 80% del codice ascritto alla categoria C'89 è in realtà destinato a piattaforme embedded, e risulta condizionato in modo pesantissimo da estensioni proprietarie, violazioni dello standard di base, eccezioni, verticalizzazioni, omissioni, funzioni stub ed altre simpatiche amenità tipiche dei cross-compiler per piattaforme embedded a 8 e 16 bit di datapath (ossia, assieme ai 4 bit, la schiacciante maggioranza dei circa 50 miliardi di sistemi embedded che costituiscono l'hardware in campo).

Last, but not least. In ordine al punto 1) viene spesso citato lo standard MISRA/C 2012, che è il più blando e generalista tra quelli che ruotano attorno alla galassia normativa inerente i sistemi embedded anche moderatamente critici, tanto da essere ordinariamente impiegato (come testimoniano migliaia di richieste contrattuali) anche nel mainstream pur essendo nato in seno all'industria automotive.
Il motivo di fondo per una simile scelta, che non dovrebbe essere neppure necessario spiegare, è che se seguendo tali regole di codifica si impara a scrivere sorgenti che sarebbero in linea di massima ammissibili anche in applicazioni laddove l'errore non è contemplato, sicuramente si sarà conseguito un optimum ingegneristico di robustezza, mantenibilità, leggibilità - anche se si sta scrivendo null'altro che un generico programmino applicativo per un comunissimo PC mainstream. Inoltre le regolette sintattiche di norme come MISRA/C e assimilabili sono verificabili automaticamente con banalissimi parser, disponibili anche a costo nullo, che tutti i programmatori dovrebbero imparare ad usare sistematicamente per verificare la "bontà" del proprio codice, assieme a tools dedicati come (SP)lint e derivati (nonché debugger, profiler, memory integrity checkers e altro ancora, ma questo è già un altro paio di maniche).

[vbextreme]

Quasi mi tratti come il primo arrivato, postando un link secolare che rispecchia ormai la mia biblioteca se non per l obfuscated che dovrebbe arrivare a giorni.
Il mio reference si riferiva proprio al c89, dando un occhiata al volo al c11 non l ho trovato, ma viene usata la forma senza il cast.
Se dunque il compilatore deve essere sotto standard senza cast, perché io devo metterlo? E ancora qui non hai linkato niente se non divulgazione di cose già lette, rilette e ormai divenute trite.

Il mondo dei chipettini che tu tanto adori è molto variegato e come tu ben saprai molto meglio di me, in quel settore spesso nemmeno ci sono compilatori completamente standard o a volte si preferisce utilizzare compilatori non standard perché più "performanti". Questo mondo va messo sotto regole un po più restrittive in modo da rendere il codice piu sicuro e portabile ma spesso cose che nell embedded è regola nel mainstream è opzionale se non addirittura da scartare.
Vorrei però tralasciare queatultima parte, uno per la mia inesperienza in tale settore, ma sopratutto perché è alquanto off-topic.

Mi interesserebbe invece vedere il perché ed il percome delle tue affermazioni.
Le mie come già scritto si basano su libri di testo anche da te citati, ansi/iso e lo stesso manuale sul gnu gcc che tu stesso consigli di leggere.

Quasi mi dimenticavo della FAQ

[M_A_W_ 1968]

Quasi mi tratti come il primo arrivato...

Se non proprio l'ultimo arrivato (così si dice in lingua italiana), sei comunque un autodidatta piuttosto noto da altri forum per la confusione e la limitatezza delle tue esperienze, nonché per il tuo assai rocambolesco "percorso formativo", se vogliamo usare questo simpatico eufemismo. Niente di personale, s'intende: le polemiche e i flames mi fanno vento agli alluci.

Ad usum delphini, potrei e dovrei dire: ragazzi miei, continuate pure a scrivere il vostro codice come vi pare. Nel migliore dei casi, non lascerà mai il vostro HD. Quindi, baloccatevi come meglio credete. E nell'eventualità contraria, se e quando qualche altro professionista seriamente preparato leggendo gli strafalcioni, gli idiomi deprecati, le omissioni da lamer vi riderà in faccia, o vi farà comunque notare lacune e incongruenze, sarà un problema tutto vostro. Come suol dirsi, il sottoscritto i suoi esami li ha già sostenuti. Tutti. Nelle appropriate sedi, da un bel pezzo, e sempre col massimo dei voti.

Francamente trovo del tutto ridicolo, se non fosse tragico, il fatto che le stesse identiche parole e i medesimi riferimenti (tranne ovviamente esempi di sorgenti e librerie soggetti a non disclosure, e ci mancherebbe...) forniti ex cathedra ad allievi laureati e addottorati già formati in ambiente multinazionale, con relativi ottimi risultati pratici nel prosieguo delle loro carriere, vengano invece accolte online con scetticismo e polemiche da persone con una frazione di tali esperienze applicative, per non parlare di titoli e formazione: anche perché la cosa sta diventando davvero troppo frequente e diffusa per essere rubricata come episodica, al di là del singolo personaggio folkloristico e colorito VBE, le cui sortite ormai non son nuove. Non riesco quindi a scrollarmi di dosso l'impressione di elargire perle ai porci, peraltro sulla base di riferimenti solidi, condivisi e perfino scontati per una pletora di altri professionisti con i quali ho condiviso lunghi anni di cammino sul lavoro e online.


Comunque sia, caro VBE, a prescindere dal fatto che del cast non ce ne frega molto, e infatti non vi abbiamo dedicato attenzione alcuna:
1) Tutti i compilatori decenti emettono un warning in sua assenza. Sono solo le implementazioni che contano quando scrivi del codice C per il mondo reale: inutile appellarsi stolidamente al salvifico standard, per la mera pigrizia che impedisce di digitare una manciata di tasti. Portando alle estreme conseguenze tale attitudine, si finisce facilmente per produrre roba in stile IOCC. Banale applicazione di principi fondamentali squadernati nei testi stracitati, a quanto pare mai a sufficienza.

2) La presenza di codesto innocuo cast non reca alcun nocumento al codice, alle prestazioni, allo strato di ozono o al moto planetario nel sistema solare. Per contro, tale cast rende invece il codice maggiormente leggibile e chiaro, e facilita di molto il lavoro di parser e analizzatori statici di codice. Capisco la mancanza di basi, ma hai davvero bisogno di vedere una simile banalità specificata nel dettaglio da una "fonte autorevole"? Non sei in grado di arrivarci da solo applicando i principi di engineering del codice elencati (ad esempio) nel Pressman e studiando i sorgenti delle libreria e il codice prodotto dal tuo compilatore monogamicamente preferito? Perché questo, in sostanza, fanno gli autori delle norme di stile... ingegneria significa sostanzialmente best practices e manualità, in un quadro scientifico di fondo.


Queste elementari considerazioni di sano buonsenso sono peraltro esplicitamente contenute in quasi tutti i testi citati in quella bibliografia. E, a proposito di buonsenso, voglio davvero sperare che tu non pensi di conoscere tali testi meglio del sottoscritto. Forse farai meglio a leggerli con maggiore attenzione, facendo attenzione soprattutto ai principi basilari e lasciando perdere lo standard del linguaggio, che - come già spiegato innumerevoli volte - ha tutt'altri scopi rispetto ai coding standards internazionali e loro derivati.


PS: La FAQ citata è piuttosto pedestre, specialmente farraginose risultano le argomentazioni addotte nel caso di "dimenticanza" dell'include file relativo alla malloc() e affini.
In primo luogo, la probabilità che in un codice applicativo la malloc() sia l'unica funzione (o costante) del sorgente il cui prototipo (risp. definizione) risiede nell'include referenziato è inferiore a quella di azzeccare un "sei" al superenalotto.
Secondariamente, se il compilatore non proviene da una busta di patatine, emette un warning in ogni caso.
Infine: automazione. Oggi anche l'ultimo ambiente di sviluppo è in grado almeno di suggerire (quando non di aggiungere automaticamente) tutti gli include files sulla base delle funzioni richiamate nei sorgenti, dunque la probabilità di certi errori è decisamente irrilevante, mentre continuano perfettamente a sussistere tutte le argomentazioni da me sopra addotte - posto che che comunque si tratta di questione speciosa e marginalissima nel contesto di questa discussione.

A questo punto, pare chiaro che non interverrò ulteriormente nel thread, che per quanto mi attiene può esser chiuso: questo improduttivo OT si è trascinato fin troppo, e poi sono francamente arcistufo di dedicare il pochissimo tempo libero a queste futili e pretestuose polemiche con degli insipienti. Ultimo avviso ai naviganti: se i vostri insegnanti o - peggio - i vostri riferimenti scelti a casaccio non hanno sortito l'effetto culturale desiderato, non è certo un problema del sottoscritto! Anche perché stiamo parlando di assolute banalità discusse trilioni di volte in modo corretto e sensato su forum e mailing list, non certo di conoscenze oscure, iniziatiche ed esoteriche. Non si può dir altro che turpe ignorare est quod omnibus scire convenit.

[vbextreme]

Caro omino verde, si perchè il mio modo di fare è sempre stato in grado di strapparti qualche risposta in piu delle classiche frasi che comunemente rilasci nei forum.
Forse non sarò alla tua alteza o nemmeno a quella dei tuoi alievi, e nonostante le mie parole siano solo leggera brezza spirata da uno dei tanti "porci" riportano esattamente quel che è scritto sui manuali che molti dei visitatori dei forum legge.
Sarebbe dunque cortese anche se certo non obbligatorio dare spiegazioni delle proprie affermazioni in modo chiaro e comprensibile a tutti e non celato dietro all' n-essima arcaica parola che sembra voler dir tutto ma in pratica non dice niente.

a prescindere dal fatto che del cast non ce ne frega molto, e infatti non vi abbiamo dedicato attenzione alcuna:

Che è poi la domanda a cui ho risposto, si quel cast che è implicito nel linguaggio c, si quello che a nessuno sembra proprio non importare.
1) Quali flag usi per ricevere il suddetto warning?
2) Dunque può essere usato a gusto, stile ANSI o stile MISRA

Sicuramente io avrò letto poco, non si legge mai abbastanza, ma di mio posso invitarti a rileggerti il topic del thread ed invitarti a non uscire per l'n-esima volta offtopic rischiando di ricadere in "polemiche inutili", magari rispondendo alle domande, in modo non solo da illuminare il "povero" vbextreme ma anche tutte quelle persone che in qualche modo non posseggono tale bagaglio.
Qui non hai i superpoteri e non puoi dunque chiudere la porta in faccia a chi non ti pare, e anche questo penso sia concetto di "comunità".Come è anche ormai risaputo che nessuno è obbligato a rispondere ad un thread sopratutto per innescare flames inutili.

Dato che io non seguo la tua strada e volendo rimanere in "tema" continuo la risposta a @vaeVictis. Dopo aver espresso le mie motivazioni sul cast, porto una FAQ di Stroustrup sull'utilizzo della define NULL, acnhe se essa si riferisce al c++ e non al c la trovo comunque molto interessante.

Il primo arrivato, colui che quando entra nella stanza non vede niente, non sa cosa fare può solo aspettare che entri un'altro e che lo possa aiutare.

[vaeVictis]

@tory_debra
In riferimento al tuo ultimo post di domanda relativa al crash del programma, cortesemente posta tutto il codice, anche le funzioni che usi e che presumibilmente definisci altrove.

p.s.:
Mi sento un po' responsabile della deriva "coding di ferro" che ha preso la discussione... che spettacolo!

[tory_debra]

Codice: Seleziona tutto

struct punto
{
	double x;
	double y;
	double z;
};

struct punto* inserisci (struct punto []);
struct punto* cancella (struct punto []);
void media (struct punto []);	


#include <stdio.h>
#include <stdlib.h>
#include "/home/tori/Scrivania/es.h"

int main ()
{
	struct punto a [2];
	int scelta = 0;
	int i;

	

	while (scelta!=4)
	{
		printf ("1 inserisci coord\n");
		printf ("2 cancella coord\n");
		printf ("3 media delle x, y o z\n");
		printf ("4 esci\n");
		scanf ("%d", &scelta);
	
		switch (scelta)
		{
			case 1:
			{
				inserisci (a);
				break;
			}
			case 2:
			{
				cancella (a);
				break;
			}
			case 3:
			{
				media (a);
				break;
			}
			
			case 4:
			{
				printf("Hai scelto di uscire! \n");
				break;
				
			}
			default:
			{
				printf ("inserire scelta valida \n");
				break;
			}
		
		}
		printf ("\n scelta:   %d \n", scelta);
		for (i=0;i<3;i++)
		{
			printf ("coord x punto %d: %.2f\n", i+1, a[i].x);
			printf ("coord y punto %d: %.2f\n", i+1, a[i].y);
			printf ("coord z punto %d: %.2f\n\n", i+1, a[i].z);
		}
	}
	return 0;
}


struct punto* inserisci (struct punto a[])
{
	int i;

	for (i=0;i<3;i++)
	{
		printf ("coord x punto %d\t", i+1);
		scanf ("%lf", &(a[i].x));
		printf ("coord y punto %d\t", i+1);
		scanf ("%lf", &(a[i].y));
		printf ("coord z punto %d\t", i+1);
		scanf ("%lf", &(a[i].z));
	}
	
	return (a);
}


struct punto* cancella (struct punto a [])
{
	int i;

	for (i=0;i<3;i++)
	{
		a[i].x = 0.0;
		a[i].y = 0.0;
		a[i].z = 0.0;
	}
	
	return (a);
}


void media (struct punto a [])
{
	int i;
	double mediax, mediay, mediaz = 0.0;

	for (i=0;i<3;i++)
	{
		mediax += a[i].x;		
		mediay += a[i].y;	
		mediaz += a[i].z;
	}
	
	printf ("media delle x:\t %f\n", (mediax/3));
	printf ("media delle y:\t %f\n", (mediay/3));
	printf ("media delle z:\t %f\n", (mediaz/3));

}

eccola


invece come si assegna ad una struct? perchè così

Codice: Seleziona tutto

struct studente
{
	char nome [15];
	char cognome [15];
	int matricola;
};

int main ()
{
        struct studente* info;
	     info[0] = {"Santa", "Pazienza", 967657};
        info[1] = {"MariaFortuna", "Incostante", 098223};
}

è sbagliato.
poi basta, l'esame l'ho fatto

Mi sento un po' responsabile della deriva "coding di ferro" che ha preso la discussione... che spettacolo!

la discussione l'ho fatta io

[gila75]

Sempre inerente alla ormai famosa questione
Noto spesso qui e altrove si scrive:

Codice: Seleziona tutto

if (NULL==a)

Quando io invece trovo più logico e "umano" scrivere :

Codice: Seleziona tutto

if (a==NULL)

Ci sono differenze anche se magari minime?

[SuperStep]

@gila75, non ci sono differenze nei due modi, se a==NULL, allora anche NULL==a (principio matematico).

E' solo una questione di preferenze, quello che puo' variare (ma non in c), e' l'ordine delle condizioni:

condizione1 & condizione2 != condizione2 & condizione1. Non tanto nell'ordine, e nella logia; ma in fattore di calcoli. Linguaggi piu' evoluti del c (o magari compilatori C diverso dal gcc che ricordo non implementi questa tecnica) evitano di eseguire la seconda condizione se la prima risulta falsa e l'operatore e' AND. In quanto, qualsiasi condizione AND falso, sara' false, quindi se la seconda condizione e' lunga, eviti di seguirla, faccio un codice descrittico

Codice: Seleziona tutto

Codice A: if(CONDIZIONE_1 && CONDIZIONE_2){ ...code... }
Codice B: if(CONDIZIONE_1){if(CONDIZIONE_2){ ...code...}}

Rimarco il concetto: (Il C non ha questa feature da quanto ne so)

(Esempio liguaggio basso livello C)
Nel codice_A ambedue le condizioni verranno controllate anche se la prima e' falsa.
Nel codice_B la seconda condizione viene controllata solo se la prima condizione risulta essere vera
Tesi: Codice_A != Codice_B

(Esempio linguaggio alto livello Java)
Codice_A == Codice_B

[Mdfalcubo]

@ vbextreme e M_A_W: siamo in una sezione tecnica, le vostre diatribe personali risolvetele privatamente. Non tollereremo oltre altri off topic. Grazie per la collaborazione.