Polskie Forum Użytkowników Debiana

dzięki za pomoc, jutro skocze do księgarni i zobaczę co tam jest ciekawego. Po zakupie jakieś lektury "na czasie" zacznę od początku tymczasem trzeba spać

Programistą (zwłaszcza C++) nie jestem, ale:

jasiekmarc pisze:#include<iostream>

a nie Kod:
#include<iostream.h>

To drugie to jakieś takie borlandowe rozwiązanie.

Pierwsze to składnia typowa dla C++, drugie dla C (niekoniecznie wynalazek Borlanda).

jasiekmarc pisze:W edytorze (vim, gvim, kate, whatever) tworzysz plik cpp, a potem w konsoli włazisz do jego folderu i piszesz Kod:
make nazwa_pliku_bez_rozszerzenia

Make już sam dobierze niezłe parametry kompilatora (-o nazwa_pliku_bez_rozszerzenia) i skompiluje odgadnąwszy po rozszerzeniu, który kompilator ma dobrać.

Hę? ¯eby używać make, trzeba najpierw stworzyć plik Makefile. Bez tego to tak średnio zadziała.

Przykładowy kod:

Kod: Zaznacz cały

#include <iostream>

int main(){
        std::cout <<"Hello world!\n"]
Sposób kompilacji:
[code]g++ -o test test.cpp
./test
Hello world!

Tyle wiem i tym mogę się podzielić. Koniec OT :->

A które wydanie Symfonii kolega kupił?

Szanowny lessmian'ie 2
Primo, W przypadku plików nagłówkowych rodem z STL-a (jak iostream) nie można mówić o składni C, gdyż są one narzędziem dostępnym jedynie w C++. Mam jednak wrażenie, że kompilator Borlanda (którego nigdy wszak nie używałem i znam tylko z książek) za poprawny uważa zapis

Kod: Zaznacz cały

#include<iostream.h>

podczas, gdy gcc (czy tam g++) tego nie zaakceptuje.
Secundo, mam świadomość, że make jest potężnym narzędziem, które dzięki stworzeniu porządnego pliku Makefile pozwala wygodnie kompilować całe projekty. Nadaje się on jednak do kompilowania prostych jednoplikowych programów w wielu językach bez zastanawiania się nad rozszerzeniami, argumentami dla kompilatora (choć nigdy nie nakaże kompilatorowi optymalizacji ani nie pozwoli używać gdb - w takich przypadkach już wygodniej kompilować bezpośrednio) i bez tworzenia plików Makefile. Po prostu pełna automatyka. Jest to niewątpliwie nieco strzelanie z armaty do wróbla, ale jak akurat dysponujemy niezłą, szybkostrzelną armatą z darmowymi pociskami, to po co przeładowywać flintę za każdym razem?

Jeśli piszesz w C++ pod Linuksem to kod programu i sposób kompilacji powinien wyglądać dokładnie tak jak napisał jak napisał lessmian2 . Ewentualnie możesz wpisać kod programu w ten sposób:

Kod: Zaznacz cały

#include <iostream>
using namespace std;
int main()
{
   cout << "Witamy na pokladzie";
}

A ja polecę Ci kurs dostępny w internecie: "Od zera do gier kodera" (znajdziesz go bez problemu w google).

Kolego jasiekmarc,

nie unoś się tak, gdyż moim celem nie było wytykanie czyichś błędów (nie uważam się za osobę kompetentną w tym temacie), lecz podzielenie się moimi uwagami. Jak napisałem na samym początku, nie jestem programistą, więc mogę nie wiedzieć wszystkiego, lub czasem wręcz się mylić. Co do make, przyznaję, nie wiedziałem że tak można - po prostu nigdy nie było mi to potrzebne.

Co do składni include, nie miałem na myśli konkretnie iostream, a ogólnie zapis nazwy pliku nagłówkowego, który jednak różni się między C a C++ (upraszczając: z '.h' i bez).

lessmian2 pisze:jasiekmarc napisał/a:
#include<iostream>

a nie Kod:
#include<iostream.h>

To drugie to jakieś takie borlandowe rozwiązanie.

Pierwsze to składnia typowa dla C++, drugie dla C (niekoniecznie wynalazek Borlanda).

jasiekmarc pisze:Mam jednak wrażenie, że kompilator Borlanda (którego nigdy wszak nie używałem i znam tylko z książek) za poprawny uważa zapis
Kod:
#include<iostream.h>
podczas, gdy gcc (czy tam g++) tego nie zaakceptuje.

Tu nie chodzi o kompilator, tylko o standard języka.
Wersja <iostream.h> to starszy standard, obecnie odradzany.
Wersja <iostream> to standard ISO z 2003 roku i należy programować według zasad tam zawartych.

Jeśli już ktoś chce się uczyć / polecamy mu Symfonię, to trzeba pamiętać, że ma to być wydanie z napisem ISO C++ na okładce. Uwaga praktyczna: ogólnodostępna na warezach wersja książki NIE jest zgodna z nowym standardem.
Oprócz sposobu włączania nagłówków, zmian jest wiele, a te na które najszybciej się natkniemy to różne operatory rzutowania: już nie (int *)zmienna, ale static_cast<int *>zmienna. Samych operatorów też jest więcej: static_cast<>, dynamic_cast<>, const_cast<>, reinterpret_cast<>. To tylko kilka różnic.

Przez odpowiednie parametry wywołania można gcc narzucić, której wersji standardu ma się trzymać.

Nie unoszę się absolutnie. Po prostu chcę zaznaczyć, że użycie make do kompilacji nie jest błędem, a, moim skromnym zdaniem, wręcz udogodnieniem. Robię tak zawsze i działa. W ten sposób, na przykład, pierwsza część wypowiedzi pitera, w której to czytamy:

sposób kompilacji powinien wyglądać dokładnie tak jak napisał jak napisał lessmian2

nie podoba mi się w tym sensie, że nazywa niektóre rozwiązania jedynymi słusznymi. W Co do kwestii nazywania include z .h i bez borlandowym albo c-style - jest to tylko kwestia kosmetyki i nomenklatury, nie zaś merytoryczna. Fakt faktem, że skądś w Symfonii się ta deklaracja wzięła i śmiem podejrzewać (na podstawie pewnych retrospekcji z książek) że jest to maniera borlandowa (albo nawet visualowa).

Edycja: W związku z fachową wypowiedzią AdeBe część o borlandzie itd. się zdezaktualizowała. Choć takie chamskie rzutowanie w starym stylu ciągle działa i nie sypie warningami, a jednak ,,include'' z .h nie kompilowało.

jasiekmarc napisał:

W ten sposób, na przykład, pierwsza część wypowiedzi pitera, w której to czytamy:
Cytat:
sposób kompilacji powinien wyglądać dokładnie tak jak napisał jak napisał lessmian2
nie podoba mi się w tym sensie, że nazywa niektóre rozwiązania jedynymi słusznymi.

No tak. Faktycznie tak to zabrzmiało, Już poprawiam:

Jeśli piszesz w C++ pod Linuksem to kod programu i sposób kompilacji może wyglądać m.in tak jak napisał lessmian2. Ewentualnie możesz wpisać kod programu w ten sposób:

AdeBe ma racje. Przeszukałem inne fora i okazuje się ze mam po prostu stara książke, nie zgodną z obecnymi standardami. Zatem muszę znaleźć nowe wydanie symfonii "Symfonia C++ Standard" wydanie od 2006 roku, wtedy moje problemy powinny być unicestwione

tymczasem poczytam sobie wydane, które już mam by ogólnie dowiedzieć się jak wygląda C.

serdecznie dziękuję wszystkim za pomoc!

Polskie Forum Użytkowników Debiana

Perl czy C++