OliForum Matematico

usando C, ho spesso avuto bisogno di ripetere le stesse stringhe per eseguire le stesse operazioni su valori diversi...
esiste un modo per creare delle funzioni (come abs(a)) da poter utilizzare come tutte le altre?
per esempio, volevo creare una funzione quad(a) che rimandi il quadrato di a, ma per farlo ho capito che dovrei creare una libreria nuova o integrarlo in una già usata...
come si può fare?

non difficile, sotto linux
http://tldp.org/HOWTO/Program-Library-HOWTO/index.html
io l'ho sfruttato per fare un programma modulare

SkZ ha scritto:sotto linux

e sotto windows?

p.s. uso dev-C++

Ah ma allora puoi usare C++? O solo C?
Comunque non ho capito: che problema c'è nel fare brutalmente delle funzioni o delle macro? Che non vuoi copiarle/incollarle in ogni programma che fai?

diciamo che se faccio copia incolla, devo inventare ogni volta decine di nuove variabili, e andarle poi a sostituire...
l'esempio quad(a) ha al massimo 3 stringhe, mentre le funzioni che voglio hanno qualcosa come una cinquantina di stringhe (sarò pure io che ancora non so scrivere sinteticamente )...

Scusa, non ti seguo.
Sai cos'è una funzione in C? O sono io che non ho capito una fava di quello che stai chiedendo?

abs(a)
è una funzione

double cubo(float);
....
double cubo(float c)
{
return (c*c*c);
}

è la definizione di una funzione in un file

io vi chiedo se esiste un modo per "formalizzare" una funzione in modo che io possa utilizzarla in un qualsiasi file, anche non definendola nello stesso, ma semplicemente richiamandola...

tecnicamente no
anche le librerie devono essere caricate e posto
#include <lib.h>
nel sorgente in C, altrimenti il compilatore non sa come trattare quelle funzioni e se la sintassi usata e' giusta

una "libreria" banale e' un header con tutte le funzione definite da includere all'inizio del sorgente, dopo gli include agli header delle librerie standard (buona norma e' includere i propri header dopo quelli si "sistema" )

SkZ ha scritto:(buona norma e' includere i propri header dopo quelli si "sistema" )

Ho sentito sostenere il contrario, con una motivazione ragionevole: se metti i tuoi #include prima, sei sicuro che contengano codice corretto anche senza richiedere "di nascosto" altre librerie.

Boh secondo me se exodd ha fatto una domanda simile non sa bene cos'è un header. In pratica tutte le funzioni nel C hanno una definizione da qualche parte; quando tu fai #include <something> non fai altro che inserire un bel po' di definizioni al tuo codice. Se vuoi avere le tue funzioni sempre disponibili fai un bel file con tutte le definizioni e chiammalo miofile.h o quello che vuoi e poi in ogni sorgente dove usi le tue funzioni metti all'inizio del codiice (come dice SkZ DOPO gli include delle librerie di sistema) #include <miofile> in questo modo avrai tutto disponibile. Se per qualche motivo strano hai problemi di definizioni di variabili usa il namespace. Spero di essere stato d'aiuto.

ps. cosa intendi per "stringhe", esattamente?

@fph: che vuoi dire? non capisco Di solito sei sicuro che il codice giusto è quello delle librerie di sistema, non delle tue se hai problemi di doppia definizione il compilatore ti da errore o warn comunque; o no?

se usi le librerie di "sistema" nelle tue funzioni per forza dovrai mettere le tue definizioni dopo gli include

Attenzione:
#include <header.h>
per gli header di sistema

#include "header.h"
per i propri (mettendo il percorso in caso)

un header e' un'intestazione, una parte di codice spesso comune a piu' sorgenti che viene quindi scritta a parte e ordinato al precompilatore di includere col comando #include
l'estensione standard per un header e' .h

exodd ha scritto:diciamo che se faccio copia incolla, devo inventare ogni volta decine di nuove variabili, e andarle poi a sostituire...

Quello che veramente non riesco a capire è il significato di questa frase. O stai cercando di fare cose complicatissime (multithreading concorrente??), o il problema che esponi non sussiste.

effettivamente da quella frase sembra che tu faccia "copia e incolla" del codice, ma poi l'esempio e' una funzione riusabilissima senza cambi


per codice corto e' preferibile le macro (ovvero sostituzione in linea)
es. la funzione cubo
il pre compilatore sostituisce a CUBO(X) la sua definizione. Attenzione che le parentesi non sono opzionali nella definizione, poiche' la sostituzione dell'argomento e' fatta con copia incolla
diventa
y=x+1*x+1*x+1 (=3x+1)
mentre nella forma scritta giusta
y=(x+1)*(x+1)*(x+1)

la "in-line sostitution" e' migliore per codice corto perche' il programma e' piu' veloce nell'esecuzione (non deve caricare una funzione e non si allunga sensibilmente il codice)

Agi_90 ha scritto:@fph: che vuoi dire? non capisco Di solito sei sicuro che il codice giusto è quello delle librerie di sistema, non delle tue se hai problemi di doppia definizione il compilatore ti da errore o warn comunque; o no?

pippo.h ha scritto: FILE *open_my_damn_file(const char *filename);

pippo1.c ha scritto: #include <stdio.h>
#include "pippo.h"
int main(){}

pippo2.c ha scritto: #include "pippo.h"
#include <stdio.h>
int main(){}

Il codice in pippo.h non e' buon C perche' richiede che il tipo FILE sia definito da qualche parte prima della sua inclusione (e' definito in stdio.h). Pero' se metti le righe nell'ordine di pippo1.c non te ne accorgi (nessun errore in fase di compilazione) perche', mettendo prima l'include di sistema che gli serve, questo errore non viene rilevato dal compilatore.
Esempio stupido ma ce ne possono essere anche con errori piu' sottili (per esempio giocando con la funzione max() o con i namespace del C++), che non vengono rilevati dal compilatore e che fanno cose diverse nei due casi.
Qualcuno invece sa dirmi qual e' il punto a favore dell'altra convenzione?

fph ha scritto:Qualcuno invece sa dirmi qual e' il punto a favore dell'altra convenzione?

Ehm, che devi includere meno roba nei tuoi header?