02.10.2024 15:28
[#31]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Rafael/ARMO, post #1
Naszly mnie jeszcze takie przemyslenia.
W kazdej prasie amigowej, gdzie byly jakiekolwiek kursy programowania, to wiekszosc byla w C.
Kompletnie nic o C++. Nawt jesli ktos potrafi cos napisac w C++ i chcialby cos zrobic w tym jezyku
to do jakiego poziomu musialby sie znizyc?
Oraz jakich kompilatorow uzywac?
Probowalem kiedys zaczac cos pod MaxomC++. Niby cos tam obslugiwal ale jak mu zapodalem
jakis prosty przyklad z internetu: jakis przyklad z jedna klasa, to wymiekl twierdzac: "niśt fersztejn".
Ostatnia aktualizacja: 02.10.2024 15:29:25 przez Phibrizzo
W kazdej prasie amigowej, gdzie byly jakiekolwiek kursy programowania, to wiekszosc byla w C.
Kompletnie nic o C++. Nawt jesli ktos potrafi cos napisac w C++ i chcialby cos zrobic w tym jezyku
to do jakiego poziomu musialby sie znizyc?
Oraz jakich kompilatorow uzywac?
Probowalem kiedys zaczac cos pod MaxomC++. Niby cos tam obslugiwal ale jak mu zapodalem
jakis prosty przyklad z internetu: jakis przyklad z jedna klasa, to wymiekl twierdzac: "niśt fersztejn".
Ostatnia aktualizacja: 02.10.2024 15:29:25 przez Phibrizzo
02.10.2024 20:20
[#32]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@sq7bti, post #30
Ważniejsza różnica jest w możliwości manipulacji wskaźnika (++, --). Czego nie zrobisz z referencją.
Ale co według Ciebie dawało by możliwość manipulacji referencją za pomocą ++,--? Jaką korzyść dawały by językowi, co takiego byśmy mieli otrzymać? Pomijam oczywiście, że te operatory ++/-- na "obiekcie" którą wskazuje referencja są przeważnie dostępne, ale to jest coś innego.
02.10.2024 20:59
[#33]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Rafael/ARMO, post #32
Chodziło mi o np. iterowaniu po listach (wektorach, tablicach) obiektów przy użyciu wskaźników. Tego nie zrobisz referencjami. Dlatego unikniesz problemów, o których pisał teh_KaiN i docent. ZTCW referencje są lepiej zabezpieczone przed niewłaściwym odwołaniem do obiektów. No, chyba że dynamicznie alokujesz pamięć, i przez pomyłkę odwołasz się do zwolnionego obszaru. Przepraszam za offtop.
03.10.2024 17:21
[#34]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@docent, post #29
Chodzi o rozróżnienie użycia zapisem. Jak masz refkę, to wiesz z góry że adres tu nie gra roli oraz tym bardziej że nie ma tam nulla. Jak wszędzie stosujesz refki gdzie się da i napotykasz w parametrach funkcji wskaźnik, to może to wskazywać (hehe) na artytmetykę wskaźnikową i nullowalność parametru.
03.10.2024 18:43
[#35]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@sq7bti, post #30
Ważniejsza różnica jest w możliwości manipulacji wskaźnika (++, --). Czego nie zrobisz z referencją.
Ale jak czesto musisz wykorzystac te mozliwosc? Wg mnie to rzadki przypadek - zazwyczaj parametr funkcji bedacy wskaznikiem np. do struct jest tylko wykorzystywany do dostepu do pol.
Tak naprawde wykonywanie operacji arytmetycznych na wskaznikach moze byc potrzebne w 2 przypadkach: gdy do funkcji jest przekazywany wskaznik do tablicy struktur albo jest przekazywany wskaznik do bloku pamieci, ktory moze zawierac rozne zserializowane struktury. W pierwszym przypadku nie trzeba wykorzystywac operacji arytmetyczych - wystarczy zwykly dostep poprzez index.
przyklad:
struct test
{
int data;
char name[20];
int Value;
};
void func (struct test* arrptr)
{
arrptr[0].Value = 10;
}
void func2 (struct test& arrref)
{
arrref.Value = 20;
}
void test(void)
{
struct test* test;
struct test test1;
struct test &test2 = test1;
func(test);
func2(test2);
} Obie funkcje robia dokladnie to samo, takze wygenerowany kod jest dokladnie taki sam,
__Z4funcP4test:
link.w a5,#0
move.l (8,a5),a0
moveq #10,d0
move.l d0,(24,a0)
nop
unlk a5
rts
__Z5func2R4test:
link.w a5,#0
move.l (8,a5),a0
moveq #20,d0
move.l d0,(24,a0)
nop
unlk a5
rts
__Z4testv:
link.w a5,#-36
lea (-36,a5),a0
move.l a0,(-4,a5)
move.l (-8,a5),-(sp)
jsr __Z4funcP4test
addq.l #4,sp
move.l (-4,a5),-(sp)
jsr __Z5func2R4test
addq.l #4,sp
nop
unlk a5
rtsReferencja gwarantuje zweryfikowanie przy kompilacji czy zostala ona zainicjowana, ale to nie oznacza, ze referencja zawsze bedzie poprawna. Np. w powyzszym przykladzie test2 jest referencja do struktury, zaalokowanej na stosie - w sytuacji gdy np. func2 przechowalaby te referencje, to proba dostepu po wyjsciu z funkcji test spowodowalaby access fault (tzw. dangling reference) tak samo jak dla pointera.
Nie neguje pewnej przydatnosci referencji do eliminacji prostych bledow w rodzaju niezainicjowanego parametru ale nie jest to swiety grall c++ :)
By uzyskac skuteczniejszy efekt jak referencja wystarczy dodac walidacje parametrow do func...
03.10.2024 19:09
[#36]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
03.10.2024 20:07
[#37]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Phibrizzo, post #15
Odniosę się od razu do tego co napisał i asman i Phibrizzo
"Literatura po Polsku dot programowania na Ami" ... jak w latach 90 tych, miało się te kilkanaście lat to był problem, żeby coś zrozumieć z pewnie słabym bądź żadnym angielskim, trzeba było siedzieć ze słownikiem albo szukać literatury w czasopismach jak choćby Magazyn Amiga. Ale teraz od co najmniej kilkunastu lat jak są dostępne translatory online, a jeszcze do tego od jakiegoś czasu ChatGPT czy też podobne, tłumaczenie z angielskiego jest bardzo proste. Ba nawet można takie AI można poprosić o wytłumaczenie zadanego kodu (często z dobrym rezultatem). Poza tym język angielski jest "must have" przy programowaniu, to jest podstawa jeśli chcemy wyjść nieco dalej niż poza "Basic" z ośmiobitowców.
Całe Amiga RKM jest po angielsku ... i o zgrozo ma przykłady w Ansi C :)
Linker, Kompilator, ... to nie jest mnogość narzędzi, to są po prostu podstawowe "narzędzia" do pracy przy kompilacji kodu. I wynikają z tego jakie są etapy kompilacji ... opracowane w latach 50-tych ubiegłego wieku.
Posiadane pełnego IDE ze wszystkim z jednej strony fajna sprawa ... z drugiej, to ograniczenie szczególnie w "środowisku" języków C/C++. Dlatego to z jakiego edytora chcemy korzystać to powinna już być indywidualna sprawa, a przy Ansi C czy C++ tak właśnie jest.
A makefiles to bardzo fajna sprawa która bardzo usprawnia tworzenie aplikacji, np. budowanie paczki.
Pisanie w jednym pliku ... hmmmm ... to jest tak jakby mieszkać i żyć w mieszkaniu z jedną "izbą", owszem tak było w przeszłości i dało się żyć, ale nie było to w większości wygodne i przy pewnej wielkości tej izby doprowadza to do chaosu. Podział na pliki, na klasy itp pozwala łatwiej tworzyć aplikację, pozwala sprawniej zadbać o separację funkcjonalności. Wyobraźcie sobie że amiga ma tylko jeden układ specjalizowany do wszystkiego, a w systemie jest tylko jedna biblioteka też do wszystkiego ... słabo.
Dziwne błędy przy kompilacji ... jak się czegoś nie rozumie, lub próbuje się patrzyć przez pryzmat błędów z Basica to tak będzie .... niezrozumiałe. Aby korzystać z C/C++ trzeba te języki nieco poznać, zaznajomić się z tekstami błędów które generują. Warto się wspomagać znowu Chatem GPT czy porostu googlem. W przypadku C/C++ na pewno ktoś już miał taki lub podobny błąd i o niego pytał choćby na stackoverflow.
"Literatura po Polsku dot programowania na Ami" ... jak w latach 90 tych, miało się te kilkanaście lat to był problem, żeby coś zrozumieć z pewnie słabym bądź żadnym angielskim, trzeba było siedzieć ze słownikiem albo szukać literatury w czasopismach jak choćby Magazyn Amiga. Ale teraz od co najmniej kilkunastu lat jak są dostępne translatory online, a jeszcze do tego od jakiegoś czasu ChatGPT czy też podobne, tłumaczenie z angielskiego jest bardzo proste. Ba nawet można takie AI można poprosić o wytłumaczenie zadanego kodu (często z dobrym rezultatem). Poza tym język angielski jest "must have" przy programowaniu, to jest podstawa jeśli chcemy wyjść nieco dalej niż poza "Basic" z ośmiobitowców.
Całe Amiga RKM jest po angielsku ... i o zgrozo ma przykłady w Ansi C :)
Linker, Kompilator, ... to nie jest mnogość narzędzi, to są po prostu podstawowe "narzędzia" do pracy przy kompilacji kodu. I wynikają z tego jakie są etapy kompilacji ... opracowane w latach 50-tych ubiegłego wieku.
Posiadane pełnego IDE ze wszystkim z jednej strony fajna sprawa ... z drugiej, to ograniczenie szczególnie w "środowisku" języków C/C++. Dlatego to z jakiego edytora chcemy korzystać to powinna już być indywidualna sprawa, a przy Ansi C czy C++ tak właśnie jest.
A makefiles to bardzo fajna sprawa która bardzo usprawnia tworzenie aplikacji, np. budowanie paczki.
Pisanie w jednym pliku ... hmmmm ... to jest tak jakby mieszkać i żyć w mieszkaniu z jedną "izbą", owszem tak było w przeszłości i dało się żyć, ale nie było to w większości wygodne i przy pewnej wielkości tej izby doprowadza to do chaosu. Podział na pliki, na klasy itp pozwala łatwiej tworzyć aplikację, pozwala sprawniej zadbać o separację funkcjonalności. Wyobraźcie sobie że amiga ma tylko jeden układ specjalizowany do wszystkiego, a w systemie jest tylko jedna biblioteka też do wszystkiego ... słabo.
Dziwne błędy przy kompilacji ... jak się czegoś nie rozumie, lub próbuje się patrzyć przez pryzmat błędów z Basica to tak będzie .... niezrozumiałe. Aby korzystać z C/C++ trzeba te języki nieco poznać, zaznajomić się z tekstami błędów które generują. Warto się wspomagać znowu Chatem GPT czy porostu googlem. W przypadku C/C++ na pewno ktoś już miał taki lub podobny błąd i o niego pytał choćby na stackoverflow.
03.10.2024 20:28
[#38]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Rafael/ARMO, post #37
"Literatura po Polsku dot programowania na Ami" ... [...]
Wszystko pieknie i ladnie tyle tylko ze wszystko co napisales jest z perspektywy "Teraz".
Ilu teraz zostalo programistow ktorzy zostali przy Amidze. Nawet jesli ktos teraz wchodzi
w to srodowisko to nie jest powiedziane ze bedzie programowal.
"Kiedys". Kiedys to wszyscy byli piekni, mlodzi i pelni zapalu. Tylko ze nie bylo tego o czym napisales
czyli dostepu do literatury. Ile z tych osob jest obecnie aktywnych?
Nawet jesli sa i programowali wczesniej, to albo robili to w asmie bo na A500 musi chodzic, albo juz w C
bo takie byly kompilatory. To tylko moje przypuszczenie ale starzy programisci dalej programuja w C
z przyzwyczajenia. Bo tak jak napisales:
Całe Amiga RKM jest po angielsku ... i o zgrozo ma przykłady w Ansi C :)
a nie w C++.
03.10.2024 20:45
[#39]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@tukinem, post #23
Moim zdaniem brak jest bibliotek dla C
Nic dziwnego, że @teh_KaiN smutno .. tyle się chłop narobił przy ACE https://github.com/AmigaPorts/ACE ...
03.10.2024 21:08
[#40]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Rafael/ARMO, post #37
Warto jeszcze zauważyć, że "w tamtych czasach" dysk twardy nie był w Amidze oczywistością, a takie zintegrowane języki dawały się jakoś używać z dyskietek. Pamiętam, że właśnie po to kupiłem dysk twardy (wtedy jeszcze było to rozszerzenie Elsat MegaRAM HD do A500 z 8 MB fastu) żeby móc programować w C. Kompilatora SAS/C 6.50 dało się z dużą dozą samozaparcia używać na dwóch stacjach dysków, ale nie polecam. A gdy już miałem dysk, zainteresowałem się kompilatorem GCC (wtedy to była wersja 2.7.2, a potem EGCS 1.1.2) i tam już było C++.
03.10.2024 21:14
[#41]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Phibrizzo, post #38
Wszystko pieknie i ladnie tyle tylko ze wszystko co napisales jest z perspektywy "Teraz".
Ilu teraz zostalo programistow ktorzy zostali przy Amidze. Nawet jesli ktos teraz wchodzi
w to srodowisko to nie jest powiedziane ze bedzie programowal.
Wątek dotyczy tych co pozostali w naszym środowisku i programują teraz mając do dyspozycji to co teraz jest, w tym emulatory, skrośną kompilację, karty turbo z "ogromną" jak na amigę ilością pamięci, tudzież MorphOS i AmigaOS4. Bo w przeszłości w latach świetności język Ansi C był bardzo popularny, a język C++ dopiero zyskiwał na większej popularności.
Oczywiście zdaje sobie sprawę z przyzwyczajeń, z zapału etc. Dlatego właśnie powstał ten wątek.
Co do tego, że Amiga RKM są przykłady w Anis C, a nie w C++. To jak wspomniałem C++ zyskiwał wtedy na większej popularności więc trudno wymagać aby z tamtej epoki były takowe (nie pamiętam czy coś było dostarczane razem z SasC).
To w sumie, ja osobiście nie widzę sensu tworzyć takich przykładów, bo po pewnym czasie pisania po prostu w C++, człowiek sam zaczyna dostrzegać jak po swojemu ogarniać programowanie pod Ami z wykorzystaniem C++. Przykłady w takim ARKM pokazują tylko jak korzystać z pewnej funkcjonalności, a to czy potem napiszemy sobie to w asm, czy C, czy E czy też C++ to już wybór programisty. Ale zaznaczam to moje zdanie.
03.10.2024 22:02
[#42]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Rafael/ARMO, post #41
Z ta popularnoscia to przypomnial mi sie przypadek tym razem z moim udzialem.
Okolo 1998 roku mialem na studiach C/C++. Nie bylo tego duzo bo ok 2 semestry tylko.
Po kilkunastu wykladach, wykladowca powiedzial:
- ... Na tym zakonczylismy C i teraz przechodzimy do C++. Kto chce moze wyjsc.
Poniewaz bylo do konca jeszcze tylko kilka wykladow to zostalem z ciekawosci.
Moj kierunek nie byl czysto informatyczny, bardziej zwiazany automatyka i elektronika.
Ostatnia aktualizacja: 03.10.2024 22:03:08 przez Phibrizzo
Okolo 1998 roku mialem na studiach C/C++. Nie bylo tego duzo bo ok 2 semestry tylko.
Po kilkunastu wykladach, wykladowca powiedzial:
- ... Na tym zakonczylismy C i teraz przechodzimy do C++. Kto chce moze wyjsc.
Poniewaz bylo do konca jeszcze tylko kilka wykladow to zostalem z ciekawosci.
Moj kierunek nie byl czysto informatyczny, bardziej zwiazany automatyka i elektronika.
Ostatnia aktualizacja: 03.10.2024 22:03:08 przez Phibrizzo
03.10.2024 23:11
[#43]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Rafael/ARMO, post #37
Ja od siebie dodam, że w latach 90 to ja na oczy nie widziałem nawet angielskiej/niemieckiej/ pozycji książkowej traktującej o programowaniu w C na Ami. Nie wiem może w złych księgarniach pytałem ;)
A jeśli chodzi o Kompilator, Linker, .. To te "podstawowe" narzędzia mają jakimś dziwnym sposobem bardzo dużo opcji, które po prawdzie człowiekowi który zaczyna przygodę z C bardzo mało mówią. A czy ktoś z Was używa Linker Scripts ?
Co do IDE to dla kogoś kto zaczyna i chce zobaczyć z czym się je taki C, to imho bardzo ważna rzecz która może zadecydować czy idzie w dany język czy nie.
Makefile to narzędzie które faktycznie usprawnia tworzenie, ale może powodować kolejne problemy, przynajmniej ja miałem w przypadku projektu w asm (asembler + makefile + wiele plików + linker).
Jeśli chodzi o pisanie w jednym pliku to ja uważam że czasem ma to sens, szczególnie gdy mówimy o optymalizacji skoków do mniejszego rozmiaru. Przestawianie funkcji tak by uzyskać krótszy skok, nie wiem czy kompilator potrafi takie rzeczy ogarnąć. Na poziomie danego moduło jestem w stanie takie coś osiągnąć właśnie przez LinkerScripts, podając linkerowi kolejność linkowanych obiektów, przynajmniej tak robiłem w projekcie asemblerowym.
A jeśli jesteśmy przy błędach, to co zrobi kompilator gdy w jednym pliku mamy
a w innym popełnimy czeski błąd.
A jeśli chodzi o Kompilator, Linker, .. To te "podstawowe" narzędzia mają jakimś dziwnym sposobem bardzo dużo opcji, które po prawdzie człowiekowi który zaczyna przygodę z C bardzo mało mówią. A czy ktoś z Was używa Linker Scripts ?
Co do IDE to dla kogoś kto zaczyna i chce zobaczyć z czym się je taki C, to imho bardzo ważna rzecz która może zadecydować czy idzie w dany język czy nie.
Makefile to narzędzie które faktycznie usprawnia tworzenie, ale może powodować kolejne problemy, przynajmniej ja miałem w przypadku projektu w asm (asembler + makefile + wiele plików + linker).
Jeśli chodzi o pisanie w jednym pliku to ja uważam że czasem ma to sens, szczególnie gdy mówimy o optymalizacji skoków do mniejszego rozmiaru. Przestawianie funkcji tak by uzyskać krótszy skok, nie wiem czy kompilator potrafi takie rzeczy ogarnąć. Na poziomie danego moduło jestem w stanie takie coś osiągnąć właśnie przez LinkerScripts, podając linkerowi kolejność linkowanych obiektów, przynajmniej tak robiłem w projekcie asemblerowym.
A jeśli jesteśmy przy błędach, to co zrobi kompilator gdy w jednym pliku mamy
UBYTE zmienna;
a w innym popełnimy czeski błąd.
extern ULONG zmienna
04.10.2024 10:16
[#44]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@asman, post #43
dlatego zawsze w dupa.c(pp) trzeba inkludować dupa.h(pp) i w dupa.h(pp) trzymać externy nawiązujące do zmiennych z dupa.c(pp) - jak się tego trzymasz, to kompilator Ci wykryje mismatch typów i walnie errorem. Na pewno GCC, bo za te amigowe wynalazki z epoki to nie ręczę.
@docent ja to wszystko wiem co mówisz. Nie mówię że to święty graal, ale używając refek tam gdzie mają one sens można nadać lepszy kontekst kodowi.
Ostatnia aktualizacja: 04.10.2024 10:16:58 przez teh_KaiN
@docent ja to wszystko wiem co mówisz. Nie mówię że to święty graal, ale używając refek tam gdzie mają one sens można nadać lepszy kontekst kodowi.
Ostatnia aktualizacja: 04.10.2024 10:16:58 przez teh_KaiN
04.10.2024 10:33
[#45]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@teh_KaiN, post #44
Bleee, externy zawsze robię w pliku źródłowym a nie nagłówkowym. Nie chce deklaracji zmiennych umieszczać plikach nagłówkowych.
Ale mogę powiedzieć, że u mnie gcc nie wywala błędu jeżeli jest niezgodność typów miedzy zmienną z jednego pliku c i externem w innym pliku. I nie wiem zbytnio dlaczego nie wywala bo parę razy miałem przez to problem.
Ale mogę powiedzieć, że u mnie gcc nie wywala błędu jeżeli jest niezgodność typów miedzy zmienną z jednego pliku c i externem w innym pliku. I nie wiem zbytnio dlaczego nie wywala bo parę razy miałem przez to problem.
04.10.2024 13:59
[#46]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@asman, post #43
A czy ktoś z Was używa Linker Scripts?W zdecydowanej większości przypadków skrypty linkera dostarczone razem z kompilatorem wystarczą. Sam nigdy nie miałem potrzeby ich modyfikowania kompilując na Amigę.
Na poziomie danego moduło jestem w stanie takie coś osiągnąć właśnie przez LinkerScripts, podając linkerowi kolejność linkowanych obiektów, przynajmniej tak robiłem w projekcie asemblerowym.Domyślnie linker linkuje w kolejności podania mu plików jako argumentów. Moim zdaniem prościej jest zmienić kolejność plików *.o w makefile, niż grzebać w skryptach.
Ostatnia aktualizacja: 04.10.2024 14:04:16 przez Krashan
04.10.2024 14:03
[#47]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
04.10.2024 14:41
[#48]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
04.10.2024 14:56
[#49]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Krashan, post #46
Jasne ja się z tym zgadzam.
Ja sobie strzeliłem w stopę tworząc makefile tak by nie dodawać ręcznie zależności do niego i wtedy wyszło że nie wiem w jakiej kolejności linker linkuje, bo dostawał zmienną $(OBJECTS) w której były wszystkie pliki typu .o. Szybko się o tym przekonałem gdy program zawisł.
Ja sobie strzeliłem w stopę tworząc makefile tak by nie dodawać ręcznie zależności do niego i wtedy wyszło że nie wiem w jakiej kolejności linker linkuje, bo dostawał zmienną $(OBJECTS) w której były wszystkie pliki typu .o. Szybko się o tym przekonałem gdy program zawisł.
04.10.2024 15:11
[#50]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@bfgmatik, post #48
"extern int dupa;" mówi tyle że "jest gdzieś zmienna dupa o typie int". Używa się tego w innych plikach niż w tych gdzie deklarujesz zmienną, żeby kompilator jej nie próbował ulokować dwa razy w pamięci, tylko Ci na słowo honoru uwierzył że w innym .c(pp) jest ona zadeklarowana i z niej korzystał.
Idąc tą logiką, możesz te externy pisać w każdym innym pliku .c(pp) by z tej zmiennej korzystać, a można to wsadzić w jeden plik .h(pp) i go inkludować gdzie trzeba. Dobrą konwencją jest zrobienie tego w pliku .h(pp) dualnym dla pliku .c(pp) gdzie deklarujesz zmienną - raz że to porządkuje, dwa że właśnie dzięki zainkludowaniu w pliku gdzie deklarowana jest zmienna masz sprawdzenie zgodności typów, bo kompilator zobaczy podczas budowania obie rzeczy naraz.
Idąc tą logiką, możesz te externy pisać w każdym innym pliku .c(pp) by z tej zmiennej korzystać, a można to wsadzić w jeden plik .h(pp) i go inkludować gdzie trzeba. Dobrą konwencją jest zrobienie tego w pliku .h(pp) dualnym dla pliku .c(pp) gdzie deklarujesz zmienną - raz że to porządkuje, dwa że właśnie dzięki zainkludowaniu w pliku gdzie deklarowana jest zmienna masz sprawdzenie zgodności typów, bo kompilator zobaczy podczas budowania obie rzeczy naraz.
04.10.2024 15:14
[#51]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@bfgmatik, post #45
Według mnie zawieranie zewnętrznych zmiennych w pliku nagłówkowym to bardzo dobra praktyka.
Co ciekawe niektóre kompilatory umożliwiają pominięcie słowa extern przy nazwie. To znaczy, że możemy wpisać w pliku nagłówkowym:
A następnie załączyć taki plik w plikach źródłowych, które z tej zmiennej korzystają.
I będzie to deklaracja zmiennej globalnej, ale linker wychwyci i zrobi jeden egzemplarz.
Według mnie to jest błędogenne ze względu na inicjalizację zmiennej, ale to jest dozwolone. Spotkałem się z takim sposobem deklaracji rok temu.
Zmienne zewnętrzne możemy też dołączać wewnątrz funkcji jako extern, co czasami się przydaje i ja korzystam. Bo zawsze taki extern można wrzucić do parametrów, w razie potrzeby.
Co ciekawe niektóre kompilatory umożliwiają pominięcie słowa extern przy nazwie. To znaczy, że możemy wpisać w pliku nagłówkowym:
int zmienna;
A następnie załączyć taki plik w plikach źródłowych, które z tej zmiennej korzystają.
I będzie to deklaracja zmiennej globalnej, ale linker wychwyci i zrobi jeden egzemplarz.
Według mnie to jest błędogenne ze względu na inicjalizację zmiennej, ale to jest dozwolone. Spotkałem się z takim sposobem deklaracji rok temu.
Zmienne zewnętrzne możemy też dołączać wewnątrz funkcji jako extern, co czasami się przydaje i ja korzystam. Bo zawsze taki extern można wrzucić do parametrów, w razie potrzeby.
04.10.2024 15:31
[#52]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
04.10.2024 15:40
[#53]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
04.10.2024 15:46
[#54]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
04.10.2024 15:58
[#55]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@bfgmatik, post #52
Wydaje się rozsądne chociaż ja jestem przyzwyczajony ze w plikach naglowkowych mam tylko stałe, definicje typów i prototypy funkcji :)
Zmienne mi tam mniej pasują jako ze są „fizycznymi” bytami umiejscowionymi w pamięci w przeciwieństwie do tych które wymieniłem.
Jasne, ja też tak robię. Akurat właśnie extern nie wiąże się z deklaracją przestrzeni na dane - to jest to samo co prototyp funkcji.
Również ja zmienne deklaruję wewnątrz pliku źródłowego.
Ostatnia aktualizacja: 04.10.2024 15:59:58 przez Hexmage960
04.10.2024 16:01
[#56]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
04.10.2024 16:23
[#57]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
04.10.2024 16:28
[#58]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
04.10.2024 16:29
[#59]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...
@Tedy, post #54
możecie polecić jakieś wygodne środowisko C++ na Amigę (nawet komercyjne) które sprawdza się w praktyce?Najwygodniejsze jest pewnie używanie crosskompilatora i VSCode jako środowiska.
Sam używam natywnego GCC na Amidze, a za środowisko robi mi amigowe CLI i edytor tekstów. Sprawdza się w praktyce, ale wygodnym bym go nie nazwał. Mi pasuje, ale czy posunąłbym się do polecania go? Chyba nie.
04.10.2024 16:35
[#60]
Re: Dlaczego dla wielu amigowych progarmistów Ansi C to czarna magia, a C++ to już dzieło szatana ...