warning: implicit declaration of function `strlen'
warning: implicit declaration of function `strlen'
Ja, vad menas med det?
Denna kod genererar varningen:
#include <avr/interrupt.h>
#include <avr/io.h>
#include <stdlib.h>
...
unsigned char string0[] = "Hej";
unsigned int g;
g = strlen(string0);
...
Kör med AVR Studio/GCC
Denna kod genererar varningen:
#include <avr/interrupt.h>
#include <avr/io.h>
#include <stdlib.h>
...
unsigned char string0[] = "Hej";
unsigned int g;
g = strlen(string0);
...
Kör med AVR Studio/GCC
Jag är inte helt hundra, men jag tror det fungerar såhär.
När du kompilerar en .C fil (till en objekt fil) som refererar till en funktion nån annan stans ifrån (t.ex. strlen(), den koden finns ej i din .c fil utan annorstädes) så skapas bara en referens. Ingen kontroll sker att funktionen verkligen finns ännu.
När du skriver strlen() och kompierar så antar kompilatorn att i nån annan objektfil finns själva koden till strlen(). För att man skall uppmärksammas på ev skrivfel så får du varningar om funktionen inte är deklarerad tidigare i t.ex. en .h fil. Dessa .h filer innehåller oftast ingen kod utan endast funktionsheadern som talar om vilka argument funktionen skall ta och lämna. Headern fungerar som en försäkring till kompilatorn att kodsnutten verkligen finns nån annan stans. Varningen är alltså till för att uppmärksamma dig på att du eventuellt gjort ett stavfel.
Nästa steg är länkningen, då skall kompilatorn pussla ihop de förkompilerade standardbiblioteken med din objektfil (objektfiler om du har flera .c filer som kopilerats var för sig). Då försöker den hitta strlen() och här får du fatalt felmeddelande om du verkligen stavat fel, dvs refererat till en funktion som inte finns nånstans i nån av objektfilerna. Eftersom strlen() finns i standardbiblioteket lyckas länkningen ändå och allt är frid och fröjd.
Dock bör man inte strunta i filerna eftersom de kan innehålla konstantdefinitioner och typdefinitioner som du kan behöva. Det är ju även kanonbra att få varningar om man stavat fel vilket iaf jag gör varannan rad minst
När du kompilerar en .C fil (till en objekt fil) som refererar till en funktion nån annan stans ifrån (t.ex. strlen(), den koden finns ej i din .c fil utan annorstädes) så skapas bara en referens. Ingen kontroll sker att funktionen verkligen finns ännu.
När du skriver strlen() och kompierar så antar kompilatorn att i nån annan objektfil finns själva koden till strlen(). För att man skall uppmärksammas på ev skrivfel så får du varningar om funktionen inte är deklarerad tidigare i t.ex. en .h fil. Dessa .h filer innehåller oftast ingen kod utan endast funktionsheadern som talar om vilka argument funktionen skall ta och lämna. Headern fungerar som en försäkring till kompilatorn att kodsnutten verkligen finns nån annan stans. Varningen är alltså till för att uppmärksamma dig på att du eventuellt gjort ett stavfel.
Nästa steg är länkningen, då skall kompilatorn pussla ihop de förkompilerade standardbiblioteken med din objektfil (objektfiler om du har flera .c filer som kopilerats var för sig). Då försöker den hitta strlen() och här får du fatalt felmeddelande om du verkligen stavat fel, dvs refererat till en funktion som inte finns nånstans i nån av objektfilerna. Eftersom strlen() finns i standardbiblioteket lyckas länkningen ändå och allt är frid och fröjd.
Dock bör man inte strunta i filerna eftersom de kan innehålla konstantdefinitioner och typdefinitioner som du kan behöva. Det är ju även kanonbra att få varningar om man stavat fel vilket iaf jag gör varannan rad minst
Jag är inte så förtjust i C's sätt att lösa det här på. Om du t.ex. har två funktioner i helt olika C filer som råkar få samma namn (t.ex. init() ) så kommer de att krocka med varandra vid länkningen, i värsta fall utan felmeddelande tror jag. Därför brukar "hemliga" namn få en underscore i början, t.ex. _KROCKA_INTE_MED_MIG. Superhemliga definitioner får två __VILL_VERKLIGEN_INTE_KROCKA. Det hela blir ganska ohanterligt vid större projekt. Verkligt irriterande att namn krockar mellan olika filer.
Följden blir att man hittar på onödigt långa namn för att undvika krock. Namnen blir ofta även sämre eftersom man inte vågar använda namn som kanske är upptagna.
Följden blir att man hittar på onödigt långa namn för att undvika krock. Namnen blir ofta även sämre eftersom man inte vågar använda namn som kanske är upptagna.
Jag har ett antal "init":
Initialize_LCD(...);
Initialize_Hardware();
Initialize_Variables();
Initialize_RTC();
Initialize_EEPROM();
osv....
Om du bara hinner till "init" har du problem, speciellt om det inte finns kommentarer som heter duga.
Det säger ju absolut inget om vad som initialiseras där och grejen med en funktion är ju just att man kan ge vettiga namn.
Om du använder en init till att sparka hela skiten igång kan den t.ex. heta "Initialize_Project();"
Initialize_LCD(...);
Initialize_Hardware();
Initialize_Variables();
Initialize_RTC();
Initialize_EEPROM();
osv....
Om du bara hinner till "init" har du problem, speciellt om det inte finns kommentarer som heter duga.
Det säger ju absolut inget om vad som initialiseras där och grejen med en funktion är ju just att man kan ge vettiga namn.
Om du använder en init till att sparka hela skiten igång kan den t.ex. heta "Initialize_Project();"
Att ha en bra modell/standard för namnsättning på variabler, funktioner
eller vad det nu må vara, är väl knappast något unikt för C !!??
Jag är van vid VMS, och där heter t.ex generella systemanrop SYS$....,
strängfunktioner STR$.... o.s.v. En väldigt stringent och 100% genomförd
standard. Dessa namn (och "LIB'arna" i sig) är de samma helt oavsett
vilket språk man har valt (Fortran, C, Cobol, Pascal, Assembler o.s.v).
Det är precis samma "call-interface" oberoende på språk. Alla språk
kan anropa subrutiner/funktioner skrivna i vilket annat språk som helst,
utan att man behöver veta vilket språk det var. Antagligen den "snyggaste"
utvecklingsmiljö som finns...
eller vad det nu må vara, är väl knappast något unikt för C !!??
Jag är van vid VMS, och där heter t.ex generella systemanrop SYS$....,
strängfunktioner STR$.... o.s.v. En väldigt stringent och 100% genomförd
standard. Dessa namn (och "LIB'arna" i sig) är de samma helt oavsett
vilket språk man har valt (Fortran, C, Cobol, Pascal, Assembler o.s.v).
Det är precis samma "call-interface" oberoende på språk. Alla språk
kan anropa subrutiner/funktioner skrivna i vilket annat språk som helst,
utan att man behöver veta vilket språk det var. Antagligen den "snyggaste"
utvecklingsmiljö som finns...
Jag är ju lite tveksam till att det verkligen behövs. Om du har 2 st "Init_LCD" i ett projekt (bara för att ta ett dumt exempel) verkar du ha problem med att bestämma dig för var du gör vad.
Sen kan det vara en idé att kolla på C++, där kan man "skydda" rutiner och värden vid att göra dom privata t.ex.
Jag har programmerat under en hel del år (20 år +) och faktisk aldrig haft såna namn-krockar, jag försöker alltid att ha vettiga namn på mina rutiner och jag kör enbart på engelska, inget svengelska med "roliga" namn.
Jag hade faktisk ett namnkrock för ett antal år sedan men det berodde på att default i en C++ kompiler var ställd till att bara ta de första 8 tecken i variabel- och rutin-namn, en snabb koll hittade felet och jag ställde upp den till 16 tecken, det räckte fint.
Så det säger mig att du inte har strukturerat upp ditt program nog eller att du inte kan beskriva vilken funktion du håller på att programmera. Jag säger inte att detta är sanningen, bara att jag uppfattar det så.
Sen kan det vara en idé att kolla på C++, där kan man "skydda" rutiner och värden vid att göra dom privata t.ex.
Jag har programmerat under en hel del år (20 år +) och faktisk aldrig haft såna namn-krockar, jag försöker alltid att ha vettiga namn på mina rutiner och jag kör enbart på engelska, inget svengelska med "roliga" namn.
Jag hade faktisk ett namnkrock för ett antal år sedan men det berodde på att default i en C++ kompiler var ställd till att bara ta de första 8 tecken i variabel- och rutin-namn, en snabb koll hittade felet och jag ställde upp den till 16 tecken, det räckte fint.
Så det säger mig att du inte har strukturerat upp ditt program nog eller att du inte kan beskriva vilken funktion du håller på att programmera. Jag säger inte att detta är sanningen, bara att jag uppfattar det så.
pagge> Vad är VMS...
Det korrekta namnet i dag är OpenVMS och det är ett operativsystem.
Alla kallar det dock VMS...
Ursprungligen utvecklat av Digital Equipment Corp (DEC), sedan uppköpt
av Compaq och idag ägt av HP (sedan de köpte upp Compaq).
V 1.0 släpptes på marknaden 1977.
Hemsida : http://h71000.www7.hp.com/
Några dokument för den intresserade :
http://h71028.www7.hp.com/ERC/downloads/5982-9831EN.pdf
"OpenVMS brochure"
http://h71028.www7.hp.com/ERC/downloads/5982-9832EN.pdf
"OpenVMS version 8.3 data sheet"
http://h71028.www7.hp.com/ERC/downloads/c00617357.pdf
Beskriver hur VMS erbjuder "high availability (HA) and disaster tolerance (DT)"
med t.ex klustring och volume shadowning i standard OS.
http://h71028.www7.hp.com/enterprise/do ... 050317.pdf
Beskriver en benchmark körd med programvara från svenska OMX Technology för börshandel.
(OMX kör ju även Stockholmsbörsen vilken till största delen körs på VMS).
Testerna skalade till 1 miljon transaktioner per *sekund* !
När du handlar IKEA prylar på webben, sköts all databashantering av
VMS system.
Sen har du banker, många börser, flygledningssystem, supportsystem för sjukhus o.s.v.
Många svenska industriföretag och banker har kritiska system på VMS.
Full klustring med "single system image" (d.v.s enbart *en* systemdisk)
upp till 850 km. Utan något annat än standard OS. Och med upp till
96 noder. "VMS cluster" har funnits över 20 år.
De banker som inte hade några driftavbrott vid 9/11 var de som hade
klustrade VMS system mellan WTC och andra datorhallar i New York området.
Den senaste helautomatiska tunnelbanelinjen i Paris (Metro Linge 14)
styrs av VMS system p.g.a de höga säkerhetskraven.
Slutligen, Wikipedia artikeln om VMS :
http://en.wikipedia.org/wiki/OpenVMS
Har du några andra frågor, just shoot !
Det korrekta namnet i dag är OpenVMS och det är ett operativsystem.
Alla kallar det dock VMS...
Ursprungligen utvecklat av Digital Equipment Corp (DEC), sedan uppköpt
av Compaq och idag ägt av HP (sedan de köpte upp Compaq).
V 1.0 släpptes på marknaden 1977.
Hemsida : http://h71000.www7.hp.com/
Några dokument för den intresserade :
http://h71028.www7.hp.com/ERC/downloads/5982-9831EN.pdf
"OpenVMS brochure"
http://h71028.www7.hp.com/ERC/downloads/5982-9832EN.pdf
"OpenVMS version 8.3 data sheet"
http://h71028.www7.hp.com/ERC/downloads/c00617357.pdf
Beskriver hur VMS erbjuder "high availability (HA) and disaster tolerance (DT)"
med t.ex klustring och volume shadowning i standard OS.
http://h71028.www7.hp.com/enterprise/do ... 050317.pdf
Beskriver en benchmark körd med programvara från svenska OMX Technology för börshandel.
(OMX kör ju även Stockholmsbörsen vilken till största delen körs på VMS).
Testerna skalade till 1 miljon transaktioner per *sekund* !
När du handlar IKEA prylar på webben, sköts all databashantering av
VMS system.
Sen har du banker, många börser, flygledningssystem, supportsystem för sjukhus o.s.v.
Många svenska industriföretag och banker har kritiska system på VMS.
Full klustring med "single system image" (d.v.s enbart *en* systemdisk)
upp till 850 km. Utan något annat än standard OS. Och med upp till
96 noder. "VMS cluster" har funnits över 20 år.
De banker som inte hade några driftavbrott vid 9/11 var de som hade
klustrade VMS system mellan WTC och andra datorhallar i New York området.
Den senaste helautomatiska tunnelbanelinjen i Paris (Metro Linge 14)
styrs av VMS system p.g.a de höga säkerhetskraven.
Slutligen, Wikipedia artikeln om VMS :
http://en.wikipedia.org/wiki/OpenVMS
Har du några andra frågor, just shoot !
