[Risolto][C] keyword static

[gila75]

Ribadisco anche che non tutto si può capire subito, ad esempio sul k&r viene illustrato il funzionamento della malloc(), subito ho pensato di aver ben capito ma una mia vera implementaziome di tale funzione sono riuscita a costruirla solo dopo anni.

Sicuramente! Però quando senti:

Peraltro, leggendo i tuoi interventi, la strutturale incompletezza di codesto libro si deduce facilmente anche dal fatto che chi ha studiato su altri testi non pone domande basilari come quelle che spesso ti trovi costretto a fare, e anzi di norma ne conosce anche le risposte, seppure magari parziali.

indubbiamente rimani deluso e scoraggiato, pensando che tutto quello che hai fatto fino adesso sia stato fatto per nulla.
Certamente corrisponde a verità. Bhà...inizio a domandarmi se non è troppo complessa la cosa.
Comunque lagne a parte del "buon Gila" come ha detto M_A_W (sarebbe davvero assurdo fare un ot sulle lagne...l'ot dell' ot ) )
Ora cerco di capire un po' di cose poi mi faccio sentire

[vbextreme]

La libreria standard

Ultimamente sto iniziando a considerare che la "libreria standard" come dice il nome è una libreria e non parte del linguaggio.
Questa mia considerazione mi è nata dopo aver scritto un paio di firmware in c senza includere niente della 'STD' e scrutando dentro a tale pacchetto si vede solo codice c unito a chiamate di sistema( forse in qualche microcontrollore un po di assembly ) è dunque un miniframework che permette di interagire col sistema ma non di vitale importanza, su windows si potrebbe benissimo farne a meno.
Togliendo anche quel mini pacchetto, del linguaggio ne rimane veramente poco.

Non penso poi bastino solo 1200 pagine per un libro sul "c for linux" già il gapil ne conta parecchie e non affronta proprio tutto e in alcuni frangenti è abbastanza grossolano e se poi aggiungiamo tutta la documentazione per i device, cosa fondamentale da imparare per un programmatore linux, allora le 1200 pagine iniziano a stare strettine e poi sempre con la speranza che sia suddiviso in più volumi.Ho un libro da ~1000 pagine e vi assicuro che passa la voglia di leggerlo, PESA! e di certo non riesci nemmeno a portarlo in bagno, no! meglio sicuramente trattare poche cose per ogni libro ma fatte bene, preferisco comprarne uno in più.
Quasi dimenticavo, la stessa documentazione delle funzioni "STD" sotto compilatore GCC è abnorme!si è vero che in mezzo ci sono molteplici chiamate di sistema unix ma teoricamente sarebbe sempre da mettere tutto dentro al libro per non parlare poi di tutte quelle sfumature che ha tale compilatore...

i ndubbiamente rimani deluso e scoraggiato, pensando che tutto quello che hai fatto fino adesso sia stato fatto per nulla

Avresti dovuto leggere certe tirate di orecchie che mi son preso in passato...
Mi hanno sicuramente aiutato, perciò continua a leggere e rileggere il libro e poi comprarne un'altro, magari uno di quella lista sopra citata e leggilo e rileggilo vedrai che tra un altro paio di tirate di orecchie impari anche tu.

p.s. ho le orecchie come jumbo causa maw...ahahhahahahag

[gila75]

p.s. ho le orecchie come jumbo causa maw...ahahhahahahag

Dumbo!!!! Vb non jumbo!!!!
Grazie per l'incoraggiamento.
Dai mi metto a vedere un po' ste variabili static ecc...

[vbextreme]

scusa Gila ma cosa dovrei dire io del mio italiano??????

[gila75]

e dai...non si può essere bravi in tutto

[gila75]

ok, ho messo insieme le idee:
main:

Codice: Seleziona tutto

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "search_str.h"



int main(void)
{
   
    char str [500]="oggi vado a casa mia dolce casa";
    char word[500]="casa";
    int n=0; 
    extern int i;

    printf ("trovati %d\n",search (str,n,word));
    printf ("valore i(nel modulo search.c)=%d\n",i);
    return 0;
}

.h

Codice: Seleziona tutto

#ifndef SEARCH_H
#define SEARCH_H


int search(char copy_str[],int n,char copy_word[]);


#endif

.c

Codice: Seleziona tutto

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "search_str.h"
int  i=200;

int search(char copy_str[],int n,char copy_word[])
{
    char *found;
    char *p=copy_str;
    int len;
   
    len=strlen(copy_word);
    while (*p!='\0')
    {
        found=strstr(p, copy_word);
        if (found==NULL)
            return 0;
        p=found+len;
        n++;
        printf ("trovato in pos %d\n", found-copy_str);
    }   
       
    return n;
}

come vedete nel main metto:

Codice: Seleziona tutto

extern int i;

che informa che in altre parti potrò trovare la variabile i
mentre nel file.c
metto:

Codice: Seleziona tutto

int  i=200;

in questo modo dal main ho accesso a i e quindi posso stampare il valore.
Se però nel file c metto:

Codice: Seleziona tutto

int  static i=200;

rendo la variabile i protetta, pur essendo globale nel modulo e anche in compilazione ottengo:

Codice: Seleziona tutto

search.c:8:13: warning: ‘i’ defined but not used [-Wunused-variable]
/tmp/ccgsHUA2.o: In function `main':
/home/gila/Scrivania/3d.c:19: undefined reference to `i'
collect2: ld returned 1 exit status

Giusto ho capito bene?
Se è corretto adatto lo stesso ragionamento con le funzioni

Quindi deduco che l'accoppiata extern/static sia una sicurezza doppia: posso dichiarare extern una variabile (per sbaglio), ma nel modulo metto static perchè so che solo li deve essere visibile ,già la compilazione m'informa no?

[gila75]

Nella speranza che qualcuno mi risponda al post sopra, faccio altre domande/considerazioni.
Da quanto ho capito suddividere un programma in più file è comodo per questi motivi:
se i moduli sono progettati bene e non hanno poche o nessuna dipendenza, possono essere modificati senza stravolgere tutto, oppure
riutilizzati per altri programmi.
Possono lavorare più programmatori contemporaneamente senza dover consultarsi continuamente su ciò che fa l'altro.
La suddivisione in più moduli poi se non ho capito male è alla base della programmazione ad oggetti, che nel C se non erro è primitiva.
Alla base della programmazione ad oggetti (sempre da ciò che a sommi capi ho capito), c'è l'incapsulamento e l'information hiding .
Cioè non rendere condivisibili alcune operazioni.
Per esempio il main potrebbe e dovrebbe essere all'oscuro di ciò che fa un modulo, o meglio di come lo fa.
Questo mi fa pensare che si debba fare uso di tipi incompleti.
Potrei dichiarare un tipo incompleto nel main, e poi implementare il tutto in un modulo .c per esempio make_struct.c (nome a caso).
In questo modo il main non saprebbe nulla della struttura, che rimarrebbe confinata nel modulo, magari con una funzione static che isola maggiormente.
Un esempio che ho letto in rete è: il main è quando mettiamo la chiave nel quadro per accendere la macchina, il modulo è il funzionamento del motore, che può essere diesel,
benzina o altro, ma poco importa, il gesto della chiave rimane lo stesso.
Quindi credo che anche gli ADT lavorino in questo modo, creare dei tipi astratti che poi i moduli concretizzano.
Volevo appunto fare una prova del genere: dichiarare un tipo incompleto di struttura nel main e poi implementarla in un modulo .c e magari in un altro la stampa dei membri.
é un ragionamento valido ?
Mi scuso se come ha detto M_A_W sono domande un po' sciocche...ma se il manuale che ho è un po' scarso, per ora ci posso fare poco.
A dire il vero ne ho un altro sugli algoritmi, ma mi sono fermato appunto qui.
Se avete voglia di leggere tutta sta pappaerdella e mi sapete dire...ve ne sarei grato.

[vbextreme]

esatto gila, stai ingranando la marcia giusta.
Riguardo gli adt se vuoi degli esempi l' EF ne è pieno prova ad aprire easythread e vedrai una catasta di adt per ogni meccanismo di threading.Questo obbliga l'utilizzatore ad appoggiarsi alle funzioni della libreria non permettendogli di accedere direttamente alla struttura rafforzando così la sicurezza e la relativa stabilità.
La controparte è la easylist che lascia più libero il programmatore con l'uso 'piu conosciuto' delle liste non adotta quindi gli adt ma lascia libero accesso alla struttura.

[gila75]

Grazie Vb della risposta.
Apenna posso faccio la prova della struttura che dicevo, e intanto guardo i codici che dicevi.
Sicuramente c'è ancora molto da studiare.
Per ora mi fermo e studio, poi più avanti mi farò vivo

[gila75]

Rieccomi.
Ho provato ad implementare un rudimentale tipo di dato astratto, in questo caso solo una struttura, che doverebbe essere protetta (a me no di clamorose gaffe).
main:

Codice: Seleziona tutto

#include <stdlib.h>
#include <stdio.h>
#include "struct.h"




int main(void) 
{   
    Stack s1;
    s1=create();
    stampa(s1);
    return 0;
} 

.h

Codice: Seleziona tutto

#ifndef STRUCT_H
#define STRUCT_H



typedef struct stack_type *Stack;
Stack create(void);
void stampa(Stack s1);

#endif

.c

Codice: Seleziona tutto

#include <stdlib.h>
#include <stdio.h>
#include "struct.h"




struct stack_type{
int num;
int num_2;
};

Stack create(void)
{
    Stack s=malloc(sizeof(struct stack_type));
    if (s==NULL)
    {
        puts("abort");
        exit(1);
    }
    s->num=33;
    s->num_2=22;

   
    return s;


}
void stampa(Stack s1)
{
    printf ("%d\n", s1->num);
    printf ("%d\n", s1->num_2);
}

Le operazioni sono basilari: creare una struttura, inserire il valore dei membri e stamparli... nulla di chè.
Se non ho capito male, così nascondo al main che cosa è Stack, che è solo prototipato nel .h con typedf, ma viene implementato nel modulo .c
In questo modo Stack dovrebbe essere un'astrazione nel main, che però viene concretizzato nel file.c
Se non erro la scrittura:

Codice: Seleziona tutto

typedef struct stack_type *Stack;

dovrebbe essere un tipo incompleto, perchè stabilisce che Stack è un puntatore ad una struttura con tag stack_type, ma non dice nulla sulla sua dimensione
che invece verrà realizzata nel file c.
Una volta dichiarato il tipo Stack, possiamo dichiarare delle variabili di quel tipo .
Spero sia corretto, io credo che possa essere se pur basilare e rozzo un tipo di dato astratto, giusto?

[vbextreme]

perfetto, puoi dirlo che gli adt sono fantastici!
peccato solo che tutta quella "astrazione" comporti un notevole calo prestazionale e un disgustevole richiamo a funzione anche solo per ritornare un valore intero.
In buona sostanza quella struttura nascosta è stata la mamma degli oggetti.
Bisogna usarla con parsimonia e ricordarsi sempre e comunque che "un programmatore c sa sempre quello che fa", limitarli un accesso è più una sfida che un piacere.

[SuperStep]

vedi se ti puo' interessare questa discussione in C in cui cercano di emulare il funzionamento dei template di C++ http://stackoverflow.com/questions/1095 ... lates-in-c

[gila75]

perfetto, puoi dirlo che gli adt sono fantastici!
peccato solo che tutta quella "astrazione" comporti un notevole calo prestazionale e un disgustevole richiamo a funzione anche solo per ritornare un valore intero.
In buona sostanza quella struttura nascosta è stata la mamma degli oggetti.
Bisogna usarla con parsimonia e ricordarsi sempre e comunque che "un programmatore c sa sempre quello che fa", limitarli un accesso è più una sfida che un piacere.

Bene
Si, credo che vadano usati solo se necessario, la complessità del codice aumenta un po'.
A naso direi che sono comodi in tutti i casi dove sia necessario fare modifiche senza stravolgere il main e il file .h .
Se il file .h combacia con il file .c come e cosa viene fatto dentro il file c, poco c' importa.
Per esempio nel mio manuale (quello che si parlava con M_A_W, che ha bocciato), viene fatto l'esempio d'implementazione di uno stack.
Prima con vettore statico, poi a liste.
Illustra che se il tutto viene progettato correttamente, il file.h e il main restano immutati, solo il file .c viene modificato. Il tutto all'oscuro del main e del .h
Forse è da li che nasce il termine di programmazione ad oggetti: il file c è un oggetto che fa o rappresenta una cosa a servizio del main.
Il mio è solo un esempio banale, dovrei impegnarmi e studiare ancora un po' e fare esempi più concreti.
Domanda: se io avessi dichiarato per esempio stampa come static o create, avrei ulteriormente protetto tali funzioni giusto ?

vedi se ti puo' interessare questa discussione in C in cui cercano di emulare il funzionamento dei template di C++ http://stackoverflow.com/questions/1095 ... lates-in-c

Grazie Superstep, gli do un occhio, anche se con l'inglese purtroppo non vado a mille...solo quello rudimentale imparato alle superiori

[vbextreme]

@gila stai un po divagando, si uno stack può essere espresso con un adt ma si presume che un "programmatore c" già li conosca e già li sappia utilizzare e quindi bloccarli l'accesso (impedirgli di modificare la struttura come più gli piaccia) è più un disagio che altro.
Discorso ben diverso ad esempio per i file, un oggetto che ci semplifica la vita su più sistemi operativi fa solo che comodo, avere le giuste conoscenze su compe aprire un file su linux e uno su windows è un conto, saperlo fare bene senza combinare "casini" è un'altro, ecco che qui un oggetto (cosi si chiamano le strutture nel c) ci permettono di semplificarci la vita anche se oscurate per leviarci qualche male nessuno si può lamentare.

Ben diverso il discorso dei template, che si traduce in un "semplice" passaggio da pre compilatore atto solo a trasformare un tipo "quasi" sconosciuto in uno "conosciuto".
Più una mancanza di voglia nel dichiarare/chiamare una funzione ..._thistype...
certo una comodità, ma senza tali si può aguzzare l'ingegno e tirare fuori cose straordinarie, vedesi il c++.........................

[gila75]

@gila stai un po divagando, si uno stack può essere espresso con un adt ma si presume che un "programmatore c" già li conosca e già li sappia utilizzare e quindi bloccarli l'accesso (impedirgli di modificare la struttura come più gli piaccia) è più un disagio che altro.

Può darsi che stia divagando in effetti. Il libro faceva l'esempio dello stack, dicendo che se per esempio dopo un po' con un array ci lamentiamo che 100 interi sono pochi, possiamo
passare alle liste se far altro che modificare il file .c.
Credo che sia solo un esempio banale, che nella pratica magari nemmeno si fa, però era per rendere l'idea.

Discorso ben diverso ad esempio per i file, un oggetto che ci semplifica la vita su più sistemi operativi fa solo che comodo, avere le giuste conoscenze su compe aprire un file su linux e uno su windows è un conto, saperlo fare bene senza combinare "casini" è un'altro, ecco che qui un oggetto (cosi si chiamano le strutture nel c) ci permettono

Ti riferisci al descrittore FILE ?

Comunque se l'esempio che ho fatto è corretto, sono già abbastanza contento, almeno la base l'ho capita...intanto proseguo lo studio.
PS @Vb: ho letto che hai citato il galip, non sapevo nemmeno che fosse, ho cercato in rete e ho trovato un manuale vastissimo tra l'altro in italiano.
Tu (tra i tanti presumo) l'hai studiato? Sembra davvero vasto e ben fatto

[vbextreme]

Si mi riferivo al gapil quando parlavo del libro da circa 1000 pagine che poi ho constatato che il mio libro "mal fatto" sul c sharp in realtà ne conta 1432.
Il gapil è stata la prima cosa che ho studiato, un discreto inizio, divaga molto e richiede già una buona conoscenza di base.

Ora dopo aver letto "operating systems design & implementation" e non averci capito una merita mazza sono passato a rileggere per la terza volta "Linux Device Driver" e forse finalmente sono riuscito ad entrare nella logica.
Con la speranza di scrivere il mio primo driver per linux.......

[gila75]

Ora dopo aver letto "operating systems design & implementation" e non averci capito una merita mazza

Bhè è un classico non capire nulla alla prima lettura. Diciamo che è quella per rompere il ghiaccio.
Tu pensa che io cose base del C che credevo di aver capito bene, ciclicamente ci devo ritornare perchè col tempo mi accorgo di nuove cose, e che magari il concetto
è molto più profondo di quello che pensavo.
Tu dicevi che il C è molto semplice per vie delle pochissime parole chiave. Ma questo si traduce in un'enorme flessibilità e potenza, che è una lama a doppio taglio.
Come diceva una publicità: la potenza è nulla senza controllo!!!
Ora torno ad approfondire gli adt. Anzi se hai/avete suggerimenti come esercizio sugli adt, potreste propormeli. Magari cose che a vostro tempo avete fatto per capirli bene.

[gila75]

Vorrei creare un oggetto astratto partendo dal codice sopra.
Praticamente dovrei fare solo un array, implementato dinamicamente nel file .c
Se lo metto nella struttura è uguale, non cambia nulla.
Se invece lo voglio trattare diversamente, non mi riesce, mi potreste dare un suggerimento?

[vbextreme]

Se lo metto nella struttura è uguale, non cambia nulla.
Se invece lo voglio trattare diversamente, non mi riesce, mi potreste dare un suggerimento?

Ovvero?
Non ho inteso

[gila75]

Ovvero?
Non ho inteso

Sono solo prove banali e generiche, ma vorrei capire il concetto, quindi vado per gradi.
Vorrei implementare un dato astratto nel main che lavora su un array dinamico che sarà implementato nel .c e .h
Se lo metto in una struttura ok, è come prima : dichiaro la struttura nel.h e all'interno ci metto un membro array.
Se invece voglio solo fare un array? Ho difficoltà e non so se si deve sempre passare per la struttura oppure no.
Non so se sono stato chiaro, facile che stia farneticando