niente, non funziona neanche così... il problema è che, se anche avesse funzionato, il prototipo che ho scritto in prima battuta è corretto, e difatti su Linux funziona perfettamente. Il mio problema è di carattere più generale, non è solo legato a questo caso, che ho pensato di risolvere trasformando la matrice in un array, ed è: perchè il C _ANSI_ funziona su una piattaforma (Linux) con un certo compilatore (gcc) e non su un\'altra (Windows) con un altro compilatore (cl)? Mi rendo conto della stupidità della domanda, ma mi pare, e i miei studi di ingegneria lo confermano, che se ci sono degli standard sarebbe opportuno che venissero adottati, in modo che chi poi deve lavorarci lo possa fare nella massima tranquillità e semplicità... si sente parlare tanto di portabilità, ma poi quando si deve scrivere un po\' di codice che vada al di là di \"Hello world!!\" ci si imbatte sempre in mille problemi legati a cazzate di questo tipo!!
mi sbaglio??

grazie per la risposta,
ciao.

Non potrei essere più daccordo con te: se ci sono degli standard dovrebbero essere adottati...o quanto meno consultati.

Il fatto che su un compilatore qualsiasi il tuo codice funzioni è un puro caso. Infatti non è possibile dichiarare degli array dinamici senza utilizzare i puntatori, new e delete (oppure malloc e free nel C).

Quando definisci un array, accade anche se l\'array è un parametro di una funzione ad ogni chiamata, il compilatore ha bisogno di sapere, in fase di compilazione, quanta memoria allocare.

Nel tuo caso, invece, la dimensione del parametro image dovrebbe essere modulata a seconda del valore assegnato al parametro w. Non è possibile.

Se vuoi passare ad una funzione una matrice di dimensioni non note a compile-time devi modificare il tuo prototipo in questa maniera:



La responsabilità di gestire i limiti della matrice sono nelle mani del programmatore.

Se vuoi che il chiamante della funzione histogram non sia responsabile di tali dettagli ti conviene aggiungere un\'astrazione sull\'immagine, magari una classe, che gestisca automaticamente l\'allocazione della memoria e che conservi al proprio interno le informazioni sulle dimensioni e passare istanze di questa struttura dati al posto dei primi 3 parametri della tua funzione, o, meglio ancora, implementare la funzione come un membro di tale classe.

Happy Hacking!

a conferma di quello che ho già scritto, cioè che non è un caso che il codice da me postato compili su gcc, ho compilato il programma su VisualDSP++, un ide utilizzato per programmare i DSP della Analog, e funziona tutto perfettamente...
io ho già tratto le mie conclusioni, voi cosa ne pensate??

ciao a tutti,
daniele

L'inusuale dichiarazione proposta è in effetti supportata dallo standard ANSI/ISO (INCITS) C 1999 in alcuni casi ben definiti, e risulta già chiara nel relativo draft pubblicamente disponibile.
Si veda in particolare l'esempio 5 a pagina 120 (corrispondente alla pagina 130 del PDF, i.e. CTRL+N "130") nella sezione 6.7.5.3 "Function declarations, including prototypes" del draft citato.


La specifica C'99 ha inopinatamente resuscitato, come effetto collaterale della introduzione ufficiale dei VLA (variable length array), un potente generatore di errori ed incongruenze di cui la ANSI/ISO C++ 1997 aveva tentato di liberarsi informalmente e con ampio supporto materiale (vector e derivate).

D'altro canto, parlando di DSP, chiunque conosca Numerical C dalla sua nascita sa bene che:

a) Proprio i VLA sono da sempre una delle caratteristiche salienti delle estensioni introdotte da GCC (da cui deriva appunto Numerical C) !

b) Lo standard C'99 ha accolto la quasi totalità dei nuovi costrutti GNU/Numerical C (numeri complessi, nuova sintassi per gli array, VLA etc.).

c) Una parte consistente del manuale del compilatore VisualDSP++ (come quelli della quasi totalità di cross-compilatori embedded) è dedicata a descrivere le innumerevoli estensioni e variazioni rispetto allo standard ANSI/ISO C++ 1997, tra le quali ve ne sono alcune specifiche per inizializzatori non costanti e per la compatibilità esplicita con GCC.

Queste osservazioni storiche spiegano perfettamente l'ampio supporto dei compilatori GCC a quei costrutti alquanto inusuali: la loro introduzione come features proprietarie si deve proprio a tali compilatori.
Il recepimento nello standard è avvenuto molti anni dopo.

Detto questo, si deve comunque ricordare che nell'antecedente standard ANSI/ISO 1997 relativo a C++ (un draft recente è pubblicamente disponibile qui) non si fa minimamente menzione di tale forma.

A fortiori, riassumendo lo Stroustrup⁽¹⁾ che di tale standard è l'ispiratore, il padre e l'artefice:
Le espressioni sintatticamente valide in C++ per una dichiarazione di funzione che impieghi array old style con subscritti espliciti con singola omissione sono
nella seconda forma B..Z sono tutte COSTANTI NOTE A TEMPO DI COMPILAZIONE, ossia combinazioni arbitrarie di una o più delle seguenti tipologie:
- Costanti numeriche intere esplicite;
- Costanti simboliche dichiarate tramite const (unsigned) int o idiomi equivalenti;
- Interi positivi (naturali non nulli) dichiarati indirettamente tramite #define (pessima pratica di programmazione, ma formalmente corretta).
Riguardo al range ammissibile, le costanti di cui sopra saranno obbligatoriamente tutte risolvibili a compile time come interi positivi.
Si veda anche questo esempio, che fa appunto uso di const.

Il metodo formalmente consigliato dal creatore del linguaggio C++ per l'impiego di array dinamici come parametri, unico metodo ufficialmente previsto in C++ '97, è il passaggio del puntatore accompagnato da un int per ogni dimensione dell'array.

Come noto, il nome stesso dell'array è un puntatore implicito dal contenuto costante, in quanto coincide funzionalmente quasi ovunque con il puntatore al primo elemento dell'array, con restrizioni solo sull'uso come Lvalue. Si tratta inoltre dell'unico tipo di dato predefinito per il quale, dato un array A, l'espressione logica (A == &A) venga valutata come TRUE. La scrittura &A è formalmente corretta, sebbene del tutto priva di effetto ed equivalente al semplice nome dell'array.
 
Bjarne specifica inoltre che, se si vuole realmente impiegare C++ come OOL "moderno", robusto, portabile, manutenibile, nei limiti consentiti dal linguaggio (alla fin dei conti non si parla di Eiffel o Smalltalk), è ampiamente preferibile dimenticarsi gli array C-style ed impiegare direttamente vector, valarray, list, string.

Gli array multidimensionali C-style sono effettivamente considerati legacy per C++, nello Stroustrup ed in quasi tutta la letteratura subordinata e derivata, inclusi gli standard interni per la codifica derivati da raccomandazioni normative della massima autorevolezza come DO178A/B, D6-35071, ESA PSS05, MISRA/C++ e simili.

Nessuna meraviglia, quindi, che alcuni compilatori C/C++ anche molto recenti possano richiedere l'uso di switch e/o direttive #pragma per supportare appieno una sintassi di fatto peculiare del C'99, o magari scegliere di non supportarla affatto, vista la presenza di alternative stilisticamente più pulite e meno error-prone in C++.

In definitiva, un simile stile di dichiarazione è effettivamente standard per il C'99, ma non lo è per C++ '97 né per il "classico" C'89.

---

(1) "The C++ Programming language, 3rd ed.", Addison Wesley 1997, pag. 838 e seguenti.

Non conosco VC, ma presumo che, dato che il nuovo stile di dichiarazione confligge apertamente con i controlli sintattici standard di C++, si debba in qualche modo dire esplicitamente al compilatore di accettare quella scrittura quando sta compilando codice C. E\' solo un\'ipotesi, ma tu puoi agevolmente verificarla compulsando i manuali.

Thread soggetto a taglia&cuci obbligato. Era veramente un peccato vedere questo thread rovinato dagli ultimi 4 interventi!!

--------------------
Per coloro che leggessero il thread solo dopo il riedit:
i post tagliati non contenevano informazioni pertinenti con l\'argomento della discussione

Assolutamente corretto. Così consigliano i Testi Sacri, e nella mia esperienza lo confermano svariati milioni di linee di codice professionalmente disponibili in librerie, frameworks, applicazioni prodotte negli ultimi 15/20 anni.

Naturalmente ciò che vale in C (C89, repetita juvant) vale anche in C++ laddove vi sia effettiva necessità, ad esempio nella programmazione system-level, di manipolare determinate aree di memoria come array: si usano i puntatori nelle funzioni subordinate.

BTW nel tuo esempio c\'è un asterisco di troppo, a meno che tu non intenda esplicitamente utilizzare un array di puntatori a double.