[C] 'private' functie declareren

[Verwijderd]

Ik wil sommige (hulp)functies zodanig gebruiken dat ze alleen binnen in de source file zichbaar zijn en gebruikt kunnen worden, oftewel; ze komen niet in de header file (interface) voor.
Als ik ze gewoon declareer (dus void mijn_functie() {} ), dan krijg ik een warning dat er een type mismatch is, omdat de compiler de files wel in de source ziet staan, maar nergens in de header.
Hoe kan ik dit oplossen?

[BoAC]

Een type mismatch Zoals in je TS staat zie ik geen variablen.. Kun je de code op de regel waarop de foutmelding wordt gegeven posten?

[koli-man]

Kun je niet de functie declareren bovenin de c file en daarna de implementaties van de functie ergens anders in de c file zetten?

[ Voor 13% gewijzigd door koli-man op 27-09-2005 13:50 ]

[igmar]

Verwijderd schreef op dinsdag 27 september 2005 @ 13:42:
Ik wil sommige (hulp)functies zodanig gebruiken dat ze alleen binnen in de source file zichbaar zijn en gebruikt kunnen worden, oftewel; ze komen niet in de header file (interface) voor.
Als ik ze gewoon declareer (dus void mijn_functie() {} ), dan krijg ik een warning dat er een type mismatch is, omdat de compiler de files wel in de source ziet staan, maar nergens in de header.
Hoe kan ik dit oplossen?

Met een static functie :

code:

static void blaat(void);

static void blaat(void)
{
    ......
}

[.oisyn]

Verwijderd schreef op dinsdag 27 september 2005 @ 13:42:
Als ik ze gewoon declareer (dus void mijn_functie() {} ), dan krijg ik een warning dat er een type mismatch is,

Hmm vaag, post je exacte code eens? Heb je de naam "mijn_functie" eerder gedeclareerd met een ander type?

omdat de compiler de files wel in de source ziet staan, maar nergens in de header.

Deze conclusie klopt niet, tenzij je een hele vage compiler gebruikt. Headers zijn niets anders dan files die in-place worden ingelezen op het moment dat je ze #include. De inhoud van een header copypasten in een sourcefile op de plek van de #include geeft exact hetzelfde resultaat. Daarnaast hoef je functies niet te declareren voor je ze definieert.

[Verwijderd]

koli-man schreef op dinsdag 27 september 2005 @ 13:49:
Kun je niet de functie declareren bovenin de c file en daarna de implementaties van de functie ergens anders in de c file zetten?

Had hier helemaal niet aan gedacht. Dit werkt.


bedankt voor de reacties

[BoAC]

code:

#include <stdio.h>

int main(int argc, char *argv[])
{
        bla();
        return 0;
}

void bla()
{
        printf("test\n");
}

Door de warning-level hoger te zetten zou de TS gezien hebben dat op regel 5 een

code:

warning: implicit declaration of function `bla'

gehad hebben volgens mijn

* BoAC compiled dit met gcc:

code:

test.c: In function `main':
test.c:5: warning: implicit declaration of function `bla'
test.c: At top level:
test.c:10: warning: type mismatch with previous implicit declaration
test.c:5: warning: previous implicit declaration of `bla'
test.c:10: warning: `bla' was previously implicitly declared to return `int'

en zoals koli-man al zei is dat op te lossen door bla() voor main te declareren

.oisyn schreef op dinsdag 27 september 2005 @ 13:55:
...
Daarnaast hoef je functies niet te declareren voor je ze definieert.

Wel als je ze eerder gebruikt alhoewel je er in C dan geen error maar een warning krijgt.
* BoAC had alleen de implicit declaration verwacht

[koli-man]

Verwijderd schreef op dinsdag 27 september 2005 @ 13:58:
[...]


Had hier helemaal niet aan gedacht. Dit werkt.


bedankt voor de reacties

Kijk ook naar de reactie van Igmar!

[.oisyn]

BoAC schreef op dinsdag 27 september 2005 @ 14:00:
Wel als je ze eerder gebruikt alhoewel je er in C dan geen error maar een warning krijgt.
* BoAC had alleen de implicit declaration verwacht

Lees nog eens goed wat ik zeg

[BoAC]

.oisyn schreef op dinsdag 27 september 2005 @ 14:05:
[...]
Lees nog eens goed wat ik zeg

Kun je een voorbeeld geven? * BoAC begrijpt je dan verkeerd

[.oisyn]

C:

void functie();  // dit is een declaratie

void functie()   // dit is een definitie
{
    printf("Hoi!\n");
}

Een functie hoeft niet gedeclareert te zijn voor je 'm definieert. Hij moet uiteraard wel gedeclareerd of gedefinieerd zijn voor je 'm gebruikt, zoals jij met je voorbeeld aantoont

[MSalters]

Eh, .oisyn, ik wil niet vervelend zijn, maar aangezien de functie al gedeclareerd is bij de { en pas gedefinieerd bij de } declareer je'm dus altijd eerder

(Elke definitie is ook een declaratie)

[.oisyn]

dat is flauw

[NMe]

Mierensex.

Overigens vind ik het persoonlijk wel netter om bovenaan de C-file alle "private" functies wel even te declareren. Dat bespaart in elk geval dit soort problemen, en in combinatie met de H-file kun je veel makkelijker opzoeken welke functies er zijn en hoe ze aangeroepen moeten worden.

[Confusion]

MSalters schreef op dinsdag 27 september 2005 @ 22:44:
Eh, .oisyn, ik wil niet vervelend zijn, maar aangezien de functie al gedeclareerd is bij de { en pas gedefinieerd bij de } declareer je'm dus altijd eerder

(Elke definitie is ook een declaratie)

Zolang er geen ; komt, is het onafgesloten, niet interpreteerbaar en dus geen declaratie, want dat impliceert geldige code.

[igmar]

.oisyn schreef op dinsdag 27 september 2005 @ 14:29:
Een functie hoeft niet gedeclareert te zijn voor je 'm definieert. Hij moet uiteraard wel gedeclareerd of gedefinieerd zijn voor je 'm gebruikt, zoals jij met je voorbeeld aantoont

Het vervelende met als je dat niet doet is dat de compiler een aantal aannames doet over het prototype van de functie, en dat klopt zelden met de praktijk, wat wel eens kan resulteren in vreemde bugs.

Ik vraag me zowiezo af waarom iedereen globals blijft gebruiken, terwijl static functions eigenlijk alleen maar voordelen biedt.

[BoAC]

Wat zijn dan de nadelen van non-static functions in C? In C++ kan ik mij dat voorstellen

[igmar]

BoAC schreef op woensdag 28 september 2005 @ 09:05:
Wat zijn dan de nadelen van non-static functions in C? In C++ kan ik mij dat voorstellen

- Veel meer risico op een name-clash
- Veel meer runtime relocations, vooral bij .so's
- Al die globale functies zijn gewoon lelijk

[Zoijar]

BoAC schreef op woensdag 28 september 2005 @ 09:05:
Wat zijn dan de nadelen van non-static functions in C? In C++ kan ik mij dat voorstellen

In C++ bereik je iha hetzelfde door de functies in een anonymous namespace te declareren/defineren. Je wilt gewoon nooit losse (private) functies met external linkage hebben. External linkage betekent dat het item zichtbaar is buiten de module die je compileert "module public". Internal linkage daarentegen is niet zichtbaar, en dus "module private". Een statische class member in C++ heeft wel external linkage, maar een namespace scope statisch item heeft internal linkage. Ook alle items (statisch of niet) hebben internal linkage in een anonymous namespace. De exacte regels zijn iets uitgebreider (local classes, enums, etc) maar dat is het basis idee.

Het nadeel van een namespace scope non-static functie is dus dat het niet geencapsuleerd is. Als je het bij een class levert is het hetzelfde als een public member die dat niet moet zijn. (want alles dat bij een class module wordt geleverd behoort ook tot die class)

In C++ is het juist niet zo'n groot probleem vanwege namespaces en classes; daar zal je niet zo snel een name clash hebben. In C is het juist een groot probleem. Hoeveel functies max() en min() zijn er wel niet... Als iedereen die met external linkage defineert dan compiled er nooit iets. Vandaar dat je opmerking over het begrijpen van de nadelen in C++ maar niet in C niet helemaal klopt... juist in C is er een groot nadeel, in C++ kan je dit afvangen door goed gebruik van namespaces (of eventueel anonymous namespaces om het hele 'probleem' te omzeilen, zoals gebruikelijk)

[Olaf van der Spek]

igmar schreef op woensdag 28 september 2005 @ 08:12:
Het vervelende met als je dat niet doet is dat de compiler een aantal aannames doet over het prototype van de functie, en dat klopt zelden met de praktijk, wat wel eens kan resulteren in vreemde bugs.

Dat is niet waar. Jij hebt het over de impliciete declaratie (een functie gebruiken zonder declaratie) terwijl .oisyn het heeft over het definieeren zonder declaratie.

[Olaf van der Spek]

-NMe- schreef op dinsdag 27 september 2005 @ 22:58:
Mierensex.

Overigens vind ik het persoonlijk wel netter om bovenaan de C-file alle "private" functies wel even te declareren. Dat bespaart in elk geval dit soort problemen, en in combinatie met de H-file kun je veel makkelijker opzoeken welke functies er zijn en hoe ze aangeroepen moeten worden.

De functie zelf boven alle aanroepen ervan zetten is toch ook voldoende om dit 'probleem' op te lossen?

[.oisyn]

Idd, ik zou private functies ook niet in een header stoppen, ze zijn immers private en niet bedoeld voor anderen om te gebruiken.

[igmar]

OlafvdSpek schreef op woensdag 28 september 2005 @ 10:58:
Dat is niet waar. Jij hebt het over de impliciete declaratie (een functie gebruiken zonder declaratie) terwijl .oisyn het heeft over het definieeren zonder declaratie.

Als je een functie gebruikt terwijl de definitie pas later staat is er altijd sprake van een implicit declaration en doet de compiler aannames. Of praten wij nu langs elkaar heen ?

[igmar]

OlafvdSpek schreef op woensdag 28 september 2005 @ 11:01:
[...]

De functie zelf boven alle aanroepen ervan zetten is toch ook voldoende om dit 'probleem' op te lossen?

En hoe denk je

C:

void func1(void)
{
     func2();
}

void func2(void)
{
   func1();
}

op die manier op te lossen ? Het voorbeeld slaat nergens op, maar het gaat even om het idee. Een declaratie bovenaan lost dit soort problemen op, en de code is ook een stuk makkelijker te lezen op die manier.

[.oisyn]

igmar: [rml].oisyn in "[ C] 'private' functie declareren"[/rml]. Let even op de werkwoorden definieren en gebruiken

[ Voor 24% gewijzigd door .oisyn op 28-09-2005 11:24 ]

[Olaf van der Spek]

igmar schreef op woensdag 28 september 2005 @ 11:22:
En hoe denk je ... op die manier op te lossen ? Het voorbeeld slaat nergens op, maar het gaat even om het idee. Een declaratie bovenaan lost dit soort problemen op, en de code is ook een stuk makkelijker te lezen op die manier.

Ik zei niet dat het altijd op die manier op te lossen is, soms zijn declaraties echt nodig. Maar meestal niet.

Verder vraag ik me ook nu weer af waarom er C gebruikt wordt en niet C++. Dan heb je het hele probleem met implicit declarations niet.

[ Voor 14% gewijzigd door Olaf van der Spek op 28-09-2005 12:26 ]

[NMe]

OlafvdSpek schreef op woensdag 28 september 2005 @ 11:01:
De functie zelf boven alle aanroepen ervan zetten is toch ook voldoende om dit 'probleem' op te lossen?

Leuk puzzelwerk als je een keer bij nader indien een functie wil gaan aanroepen in een andere functie die daar al boven staat. Wanneer je even vantevoren alles declareert is het voor jezelf makkelijker na te zoeken hoe een functie werkt, en bovendien bespaar je jezelf dus puzzelwerk. Natuurlijk is het ook voldoende om goed op de volgorde van je functies te letten, maar in de praktijk vind ik het niet fijn werken.

[Olaf van der Spek]

-NMe- schreef op woensdag 28 september 2005 @ 16:02:
Leuk puzzelwerk als je een keer bij nader indien een functie wil gaan aanroepen in een andere functie die daar al boven staat. Wanneer je even vantevoren alles declareert is het voor jezelf makkelijker na te zoeken hoe een functie werkt, en bovendien bespaar je jezelf dus puzzelwerk. Natuurlijk is het ook voldoende om goed op de volgorde van je functies te letten, maar in de praktijk vind ik het niet fijn werken.

Als je niet van puzzelen houdt kun je in dat geval natuurlijk altijd de declaratie even aanmaken.

[drm]

OlafvdSpek:
Als je niet van puzzelen houdt kun je in dat geval natuurlijk altijd de declaratie even aanmaken.

Ik zie niet in waarom je het jezelf lastiger zou maken dan nodig. Als je gewoon de declaraties altijd bovenaan zet heb je er nooit last van, en 't is een kleine moeite.