Dyskusja:C++

Sprawy porządkowe

Jak na razie C++ jest robione strasznie na dziko. Myślę, że lepiej będzie, jeśli ustalimy parę rzeczy

Układ

Nawigacja po poszczególnych częściach jest niewygodna. Proponuję na górze każdej dodać link:

< C++

oraz na dole po kresce

---

< C++

To oczywiście absolutne minimum, jeśli ktoś chce, może robić u dołu nawigacją następny-poprzedni.

Dodałem do Wikibooks Szablon:ProstaNawigacja. Mam nadzieję, że nikt mnie nie zlinczuje za samowolkę. Szablon jest ogólnego zastosowania, może być wykorzystany nawet w książce kucharskiej. Przykład zastosowania: Programowanie:C plus plus:Przeładowanie operatorów. Przy okazji napiszcie, co sądzicie o szablonie, bo zastanawiam się, czy nie dodać go do listy szablonów standardowych. --Derbeth 18:26, 4 kwi 2005 (UTC)

Kod

Jest straszny nieporządek z kodem źródłowym. Różne są wcięcia, różne są konwencje pisania "wąsów" itp. Proponuję:

1. Pogrubiać słowa kluczowe: for, if, int, return itp. tak, jak to jest w angielskim Wikibooks
2. Ustalić teraz głębokość wcięcia. Nie powinno być tak, że od razu wcinamy o 10 znaków, bo kod wyjdzie za prawy brzeg strony. Proponuję 3 spacje od lewej i 5 w każdym zagnieżdżeniu.
3. Stawianie "wąsów". Są generalnie trzy notacje:

  if( warunek ) {
       instrukcja;
  }

  if( warunek )
  {
      instrukcja;
  }

  if( warunek )
      {
      instrukcja;
      }

Musimy teraz ustalić jedną i trzymać się jej konsekwentnie.

--Derbeth 10:14, 29 sty 2005 (UTC)

ja bym wybrał drugu wariant... btw - przydało by się jakieś słowo wstępne dla absolutnego laika, objaśniające w jakich edytorach pisać, co można za pomocą c++ zrobić, etc. Marshaü 20:28, 29 sty 2005 (UTC)

Ja też wolę drugi wariant, to już razem dwa głosy. Popieram koncepcję wprowadzenia dla laika, ale trzeba się zastanowić, jak to zrobić, żeby się nie dublować z hasłem C, bo tam mogą chcieć coś podobnego napisać. W każdym razie ja bym widział to tak, że piszemy rozdział "Narzędzia", gdzie wymieniamy: kompilatory, ich cechy, różnice i dostępność, IDE oraz dobre edytory z podświetlaniem składni, wszystko dla różnych platform (Windows, Linux, Unix, MaxOS, inne?). O, przy okazji jeszcze wypadałoby napisać, jak kompilować, bo składanie programu z kilku plików źródłowych i nagłówkowych w GCC może początkowo podłamywać. --Derbeth 22:40, 29 sty 2005 (UTC)

no cuż, zapraszam do pisania, poprawiania itd :) Pozdro --Lrds 17:12, 30 sty 2005 (UTC)

Czyli mam rozumieć, że ustalamy drugi wariant "wąsów" oraz wcięcia: pierwsze 3 spacje, każde kolejne 5 znaków? W nawigacji dwa linki: u góry i u dołu. --Derbeth 12:55, 1 lut 2005 (UTC)

myśle że pogrubiane nie powinny być słowa kluczowe tylko fragmenty kodu ważne dla danego tematu. Jeżeli podzieliłes klasy na dodatkowe rozdzialy to powinny tam tez znaleźć sie takie tematy jak dziedziczenie i funkcjie wirtualne. pozdro --Lrds 19:23, 11 lut 2005 (UTC)

Chciałby zaproponować stosowanie stosowanie nazw zmiennych z małej litery oraz unikanie zmiennych o takich samych nazwach jak nazwy typów, głównie w przykładach. A więc proponuję wektor nie Wektor oraz unikanie przykładów tego rodzaju, które można znaleźć w rozdziale "Zarządzanie pamięcią":

 Test* Test = new Test();

Osobiście proponowałby, zamiast polskich, angielskie nazwy typów, zmiennych, funkcji, itp. co wyrabia dobry i przydatny nawyk wśród programistów. --mloskot 21:35, 10 paź 2008 (UTC)

Derbeth zaproponował pogrubianie słów kluczowych. Czy nie lepiej jest opakować kod źródłowy z znacznik <syntaxhighlight lang="cpp"> i </syntaxhighlight>? Co do nazewnictwa funkcji bądź zmiennych proponuje notację węgierską oraz stosowanie tzn. CamelCase. W sumie angielskie nazwy to też nie jest zły pomysł. W końcu większość dokumentacji C++ są napisane w tym języku. --Mani3xis 13:14, 22 sty 2011 (UTC)

Wydaje mi się, że wtedy mogło nie być tagów "syntaxhighlight lang = cpp", dlatego z nich nie skorzystano. Aktualnie raczej nikt nie miałby nic przeciwko, żeby wszędzie używać tego tagu. W pewnych miejscach jest chyba pominięty, kiedy dotyczy samej prezentacji składni jakiegoś wyrazu czy wyrażenia. --Lethern (dyskusja) 16:32, 22 sty 2011 (CET)

Nowy spis treści

Mój znajomy zaproponował nowy spis treści do podręcznika C++. Jak widać na pierwszy rzut oka, jest bardziej obszerny, ale moim zdaniem logicznie bardziej uporządkowany.

1. Podstawy
1.1 "Hello world"
1.2 Włączanie bibliotek standardowych
1.3 Proste wejście/wyjście strumieniowe
 
2. Funkcje
2.1 Funkcja main
2.2 Instrukcje sterujące
2.3 Typy wbudowane, wyrażenia i operatory
2.4 Przekazywanie argumentów przez referencję
2.5 Przeładowanie nazw
2.6 Wskaźniki do funkcji [można to robić przed zwykłymi wskaźnikami]
2.7 Szablony funkcji (proste przykłady z typami wbudowanymi)
 
3. Klasy
3.1 Kontrola dostępu [z omówieniem "struct"]
3.2 Funkcje składowe i zaprzyjaźnione
3.3 Konstruktory i destruktory
3.4 Pola, listy inicjalizacyjne
3.5 Const i mutable
3.6 Operatory przypisania, konstruktory kopiujące
3.7 Operatory konwersji, konstruktory konwertujące [z omówieniem
konsekwencji dla przeładowania funkcji]
3.8 Dziedziczenie
3.8.1 Wywoływanie konstruktorów
3.8.2 Funkcje wirtualne
3.8.3 Klasy abstrakcyjne
3.8.4 Dziedziczenie wielokrotne
3.8.5 Dziedziczenie wirtualne
3.9 Przeładowanie operatorów
 
4. Wskaźniki
4.1 Proste wskaźniki - porównanie z referencjami
4.2 Wskaźnik "this"
4.3 Wskaźniki do wskaźników - przykłady zastosowań
4.4 Wskaźniki do pól składowych
4.5 Wskaźniki do funkcji [przypomnienie, rozszerzenie]
4.6 Wskaźniki do funkcji składowych
 
5. Przestrzenie nazw
5.1 Zasady przeglądania przestrzeni nazw
 
6. Szablony
6.1 Szablony funkcji - przypomnienie
6.2 Szablony klas
6.3* "Metaprogramowanie" przy użyciu szablonów
6.4 Metody panowania nad "puchnięciem" kodu
 
7. Biblioteka standardowa
(7.x ...)
 
8. Sytuacje wyjątkowe
(8.x ...)
 
9. Zaawansowane mechanizmy niskopoziomowe:
9.1 Unie
9.2 Pola bitowe
9.3 Modyfikator volatile, register
9.4 Preprocesor

Taki spis treści na pewno będzie wymagał od nas większej ilości pracy, bo jest bardziej obszerny, ale jest też bardziej kompletny i moim zdaniem dobrze prowadzi uczestnika po zawiłościach C++. Będzie też wymagał przestawienia istniejących rozdziałów. Co sądzicie o tym pomyśle? Czekam na uwagi, modyfikacje kontrpropozycje. Chyba, że chcecie zostać przy starym spisie treści. --Derbeth 07:28, 5 maj 2005 (UTC)

Mi osobiście bardziej odpowiada ten zaproponowany powyżej, jest bardziej przejrzysty; co prawda powracam dopiero na Wikibooks po długiej nieobecności i nie zdążyłem dokładniej się rozejrzeć w tym co aktualnie jest ;-) CzarnyZajaczek 21:53, 17 wrz 2005 (UTC)

A może by tak dodać coś dla posiadaczy Windows? Jakieś wprowadzenie do WinApi?

Co do WinApi - zaraz ktoś powie, że przydała by się biblioteka Qt i z podręcznika o języku C++ zrobi nam się przewodnik po okiennictwie stosowanym ;-). O WinApi można spokojnie utworzyć osobny podręcznik, analogicznie jak np. do Cocoa. --Kj 12:44, 29 gru 2006 (CET)

Połączenie podręczników C i C++

Zapraszam do Baru. --Derbeth 15:55, 3 paź 2005 (UTC)

Spis treści po połączeniu

Po przeniesieniu części rozdziałów do podręcznika C konieczne staje się skonstruowanie nowego spisu treści. Oto moja wstępna propozycja, proszę, dodajcie własne lub piszcie uwagi. --Derbeth ^talk 22:20, 1 gru 2005 (UTC)

• O podręczniku
  • Wstęp - przenieść historię C++ z obecnego spisu treści
  • O podręczniku - autorzy, licencja, źródła itp.
• Podstawy języka
  • Przestrzenie nazw - co to jest, uwaga o przestrzeni std i nowych plikach nagłówkowych, wprowadzenie cin i cout bez szczegółów o obiektach, ewentualnie dodatkowo klasa string
  • System typów - uwagi o ściślejszej zgodności typów, nowy sposób rzutowania (odradzić stary)
  • Deklarowanie zmiennych - o możliwości deklarowania zmiennych gdziekolwiek, nawet w nagłówku for
  • Referencje - porównanie ze wskaźnikami, przekazywanie argumentów do funkcji
  • Przeciążanie funkcji - plus jak nie można przeciążać (typ zwracany, zbyt podobne argumenty itp.)
  • Funkcje inline - krótko
  • Zarządzanie pamięcią - operatory new i delete (krótko - bez przeładowania)
• Podstawy programowania obiektowego
  • Czym jest obiekt - o obiektach i klasach, jak deklarujemy klasę, atrybuty i metody
  • Kontrola dostępu - dostęp publiczny, chroniony i prywatny, porównanie domyślnego dostępu class ze struct, funkcje i klasy zaprzyjaźnione
  • Konstruktory i desktuktory
  • Dziedziczenie - z uwzględnieniem publicznego, prywatnego i chronionego
  • Składniki statyczne
• Zaawansowane programowanie obiektowe
  • Funkcje wirtualne - z podkreśleniem, po co jest polimorfizm, dynamic_cast<>
  • Programowanie orientowane obiektowo - co i jak
  • Obiekty stałe - jak tworzyć, możliwość optymalizacji funkcji stałych, błędy powodowane przez funkcje stałe, mutable
  • Przeciążanie operatorów - przykład klasy z kompletnym przeciążeniem operatorów (przypisanie, porównanie, << z cout itp.)
  • Konwersje obiektów - przeładowanie operatorów konwersji, konstruktor jako środek konwersji, używanie explicit
  • Klasy i typy zagnieżdżone
  • Dziedziczenie wielokrotne - plus dziedziczenie wirtualne
• Zaawansowane konstrukcje językowe
  • Obsługa wyjątków - napisać o funkcji unexpected() i terminate()
  • Szablony funkcji
  • Szablony klas
  • Wskaźniki do elementów składowych
• Dodatek A - biblioteka STL
  • filozofia
  • string - krótko jak używać
  • vector
  • set
  • map
  • iteratory
  • algorytmy - na przykładzie find() i copy()
  • inne klasy - krótko
• Dodatek B
  • Różnice między C a C++
• Dodatek C
  • Przykłady
• Zasoby
  • link do dobrej dokumentacji STL-a
• Wersja drukowana (a la en:Python/Print version

Komentarze

Moja osobista opinia - mnie się podoba. Nie ma udziwnień, a styl spisu treści jest zwięzły i treściwy. Jestem za. -Kj 19:20, 13 gru 2005 (UTC)

Może byśmy już wstawili ten spis treści? --Piotr K. 14:54, 26 gru 2005 (UTC)

Ja bym proponował odrazu zacząć od programowania obiektowego tzn. przedstawić na czym ono polega, opisać podstawy jak napisać własną klasę i stworzyć własny obiekt (bez dziedziczenia itp.) Następnie kiedy osoba zrozumię tę koncepcję w krótko opisać o rzeczach zaczerpniętych z C i pociągnąć jakoś dalej. W ten sposób nie będzie wymuszone zapoznanie się z językiem C. Moja propozycja: --Piotr K. 09:36, 23 gru 2005 (UTC)

• Podstawy języka
  • Programowanie obiektowe - na czym polega -- ogólna charakterystyka, kilka przykładów
  • Przestrzenie nazw
  • Zmienne i obiekty -- razem z systemem typów, kilka klas
  • -- referencje i wskaźniki zostawić na później
• Podstawy programowania obiektowego
• ...
• Elementy języka
  • Referencje
  • Wskaźniki -- odwołanie do C
  • Funkcje -- jako zewnętrzne „metody”, krótko o inline, też odwołanie do C

...

• Optymalizacja -- rozdział o sposobach optymalizacji kodu

Ja natomiast jestem przeciwny takiemu sposobowi pisania podręcznika. Ideą połączenia było, aby nic w obu podręcznikach nie pisać dwa razy, bo to marnowanie wysiłków. Moja koncepcja obu podręczników jest taka, że podręcznik C++ jest logicznym przedłużeniem podręcznika C i nie można zacząć czytać podręcznika C++ nie skończywszy lektury podręcznika C. Twoja propozycja to tak naprawdę ominięcie tylko jednego rozdziału z mojej propozycji (o podstawach języka), i to nie w całości. Nie podoba mi się styl pisania, w którym co chwila podaje się link do innego podręcznika (jak u ciebie we Wskaźnikach) - taki rozdział w podręczniku C++ nie jest już potrzebny, bo wskaźniki są w podręczniku C. Podręcznik powinno się czytać jak książkę, strona po stronie, a nie skakać do tyłu, do przodu, do innego podręcznika.

Moja koncepcja głównie polega na tym, żeby nie wymuszać od czytelnika znajomości języka C, dlatego moim zdaniem powinno tam się znaleźć krótki opis struktur zaczerpniętych z C. Wiele osób, co zaczyna się uczyć C++, nie znało wcześniej C. Pisząc o odwołaniu do C we wskaźnikach miałem na myśli pokrótkie omówienie, czym są, na podstawie referencji. W końcu chyba łatwiej wytłumaczyć referencje niż wskaźniki.

No to tu się nie zgodzimy, bo dla mnie jeśli ktoś nie zna C to nie ma czego szukać w C++. Dla mnie podręcznik C++ ma być podręcznikiem do tego języka a nie podręcznikiem programowania obiektowego. Jeśli ktoś zaczyna programować, obiekty nie są mu potrzebne; C++ całkiem dobrze nadaje się do programowania czysto strukturalnego. A co do zanudzania - no cóż, albo uczymy języka, albo robimy pogawędkę. --Derbeth ^talk 15:59, 23 gru 2005 (UTC)

No dobra odnośnie tego programownia obiektowego nie mam do końca racji, ale nadal uważam, że aby poznać C++ nie trzeba znać C. Porównaj sobie np. char*, z wygodą klasy string. Jeśli ktoś ma zaczynać od zera, to chyba łatwiej mu będzie operować na tym drugich. Przy takiej koncpecji proponowałbym nazwać książkę „C++ dla programistów C”. --Piotr K. 16:31, 23 gru 2005 (UTC)

Od char* nie odejdziesz, bo mnóstwo bibliotek dla kompatybilności z C używa tylko char*. Poza tym, czasami nie da się uciec od biblioteki standardowej (operacje na plikach itp.). I co wtedy? Według mnie nie można być dobrym programistą C++ bez znajomości C, w końcu C to podwaliny języka, nie da się od tego uciec. --Derbeth ^talk 18:28, 23 gru 2005 (UTC)

Co z tego? Chyba łatwiej komuś zacząć od stringów niż od czarów. Może od razu by komuś próbować na sam początek tłumaczyć np. czym są drzewa czerwono-czarne, bo można dojść do wniosku, że na pewno mu się przydadzą, bo szybko działają, a i tak w końcu będzie musiał ich zacząć używać. Uważam, że nie może być tak, że najpierw wyskakujemy komuś z char *, strcmp, strcpy, uwagami typu, aby nie przekroczyć pamięć itp. O wiele łatwiej mu będzie zacząć od czegoś normalniejszego, bardziej intuicyjnego w użyciu np. string, map. Jeśli ta książka ma powstać i ma być skierowana głównie dla wymiataczy języka C, to uważam, że powinna zmienić nazwę, bo być może ktoś będzie w przyszłości chciał napisać książkę do C++ dla początkujących (nie C-owców). Jeśli książka do C++ jest napisana we właściwy sposób tzn. nie wyskakuje od razu z C, to jest o wiele łatwiejsza do przyswojenia, niż nawet sama książka do C. --Piotr K. 19:28, 23 gru 2005 (UTC)

Rozumiem, że chcesz użytkownika jak najszybciej wprowadzić w programowanie obiektowe, żeby "nie zepsuć" go programowaniem strukturalnym? Osobiście jestem bardzo sceptyczny wobec takiego kursu. U ciebie jest takie skakanie tam i z powrotem - najpierw coś o obiektach, potem trochę o podstawach, potem więcej o języku itp. Moim zdaniem nie będzie dobrym programistą ktoś, kto nie zna strukturalnych podstaw języka, nie zna tych wszystkich paskudnych sztuczek i pułapek znajdujących się u podstaw. Jak dla mnie to, czy ktoś przeczyta o obiektach rozdział wcześniej czy później nie ma znaczenia a podręcznik, który idzie po kolei przynajmniej przedstawi czytelnikowi uporządkowaną wiedzę a nie jeden wielki mętlik.

Osobiście nie wyobrażam sobie książki o C++, nie mówiącej o programowaniu obiektowym. W końcu C++ to język głównie do tego przystosowany (nie wyobrażam sobie omówienie dziedziczenia i tym podobnych spraw bez programowania obiektowego). Dlatego moja propozycja mówi, aby na początku omówić programowanie obiektowe. Nie chodziło mi głównie o wyłożenie spraw technicznych języka, lecz o przedstawienie w prosty sposób samej idei na różnych przykładach. Stanowiłoby to coś w rodzaju wstępu. Te przesunięcie wskaźników i referencji nie koniecznie musi być moim najlepszym pomysłem, być może pasuje w lepszym miejscu. Ale chciałbym, aby ta książka nie przynudzała już na samym początku tak bardzo sprawami technicznymi, ale żeby były stopniowo wplątane w treść książki.

Programowanie obiektowe to ważna rzecz, ale moim zdaniem nie można wziąć zupełnie zielonego człowieka i zacząć tłumaczyć mu, co to są obiekty, dziedziczenie itp. bo nic nie zrozumie. Jak mu się powie: napisz to a program napisze ci tamto, to chyba bardziej przemówi to do niego. Poza tym chcesz pisać na początku o obiektach, ale bez dziedziczenia itp. - to bez sensu, obiekty bez dziedziczenia to po prostu trochę inna nazwa dla programowania strukturalnego. Jeśli chciałbys z kolei na samym początku omówić obiekty jeszcze z dziedziczeniem to kto by przetrwał taki wstęp? Człowiek czyta cały rozdział, buja gdzieś na wyżynach abstrakcji nie rozumiejąc nic a nic a nie dowiedział się jeszcze, jak dwie liczby dodać. --Derbeth ^talk 09:51, 23 gru 2005 (UTC)

Wyżej napisałem, że nie chodzi o przedstawienie obiektów, dziedziczenie, tylko idei. (Mam nadzieję, że przez tę książke się nie pokłócimy ;) --Piotr K. 11:55, 23 gru 2005 (UTC)

Prawda jest taka, że nie można zacząć uczyć C++ od rzeczy trudnych tj. klasy czy nawet struktury. Pierw trzeba opisać podstawy, zaczynając od obiektów typów wbudowanych, podstawowych instrukcji np. operatorów czy pętli. Znając te pojęcia uczestnik tego kursu może dopiero przystąpić do tworzenia mniej lub bardziej złożonych funkcji, później szablonów funkcji. Znając pojęcie przeciążenia/przeładowania nazw funkcji, potrafiąc biegle posługiwać się wskaźnikami, znając podstawy obsługi wyjątków, uczestnik kursu może zacząć od tworzenia prostych obiektów. Najpierw niech będą one czymś w rodzaju struktur z języka C. Pojęcie funkcji składowej radziłbym wprowadzić nieco później. Gdy już pojęcia te zostaną wprowadzone, zostanie przedstawiony mechanizm konstruktorów i destruktorów, jak również przeładowania operatorów, tworzenia konwersji można przystąpić do tłumaczenia szablonów obiektów. Dziedziczenie i Polimorfizm należałoby wprowadzić na samym końcu kursu, ponieważ są to zagadnienia dość cięzkie. Sam z początku miałem z nimi duże trudności i nie ukruwam, że choć jest to najpiękniejszy mechanizm w języku C++, to przy zbyt wczesnym jego tłumaczeniu uczestnik kursu może pezpowrotnie opuścić jego poznawanie. --Zbyszek P. 09:11, 26 maja 2006 (UTC)

Zgadzam się. Wrzucanie początkującego programisty, który być może nie programował nigdy wcześniej w tego typu językach, na głęboką wodę jest bez sensu. Odnośnie odwołania się do konstrukcji z języka C - podręcznik o C++ jest merytoryczną kontynuacją podręcznika o C. C++ jest niejako obiektową "nadbudówką" do C. Pragnę też zauważyć, że w podręczniku o C nie ma żadnych informacji, które nie odnosiły by się także do C++ lub nie mogłyby być w nim używane (jeśli takie istnieją, to zostało to odpowiednio zaznaczone). Moim zdaniem forma podręcznika o C++ jest prawidłowa. Kj 08:03, 26 maj 2006 (UTC)

Ale zauważcie, ile osób używa wyjątków i szablonów a ile osób używa klas? Szablony i wyjątki to tylko dodatki, prawdziwy C++ to klasy i tylko klasy. Powinniśmy w pierwszej kolejności uczyć rzeczy istotnych, podstaw języka a nie zupełnie rzeczy nieistotnych, choćby nawet prostszych (a tu mam wątpliwości, bo czytelnik mógł znając np. Pascala zetknąć się z obiektami a nie zrozumie łatwo szablonów i wyjątków). Jak dla mnie można być programistą C++ nie znając szablonów i wyjątków, natomiast człowiek nieznający klas w ogóle nie ma pojęcia o C++. --Derbeth ^talk 08:08, 26 maj 2006 (UTC)

Ja mam za to przeciwne zdanie. Kurs C zawiera wszystkie potrzebne podstawy języka (uzupełnione w rozdziale pierwszym). W języku C++ chodzi o programowanie obiektowe - to jest sens stworzenia tego języka. Po co w nieskończonośc pisać o składni? Dla tych, którzy nie znają programowania obiektowego jest C. Jeśli ktoś chce się uczyć C++, to musi się nauczyć o klasach i nie ma tu dyskusji.

Szablony to bardzo trudna koncepcja i moim zdaniem powinna być wprowadzona jak najpóźniej. Natomiast wyjątki to po prostu taka wisienka w torcie, rzecz o o wiele mniejszej wadze, jako szczegół w sumie mało istotny powinny być też wprowadzone późno. --Derbeth ^talk 07:57, 26 maj 2006 (UTC)

Przykład + Ćwiczenie

Co sądzicie o tym, aby ustalić, że KAŻDY rozdział musi się kończyć przykładem i ćwiczeniem (zanim oceni się pracę nad rozdziałem na 100%)? Nie wiem czy dodanie Przykładów i Ćwiczeń tylko i wyłącznie jako osobnych rozdziałów (Dodatek B) nie mija się z celem - użytkownik powinien sie móc z nimi zapoznać podczas uczenia się konkretnego elementu języka C++, a nie "wyławiać" te elementy z przykładów z dodatku do tego podręcznika. Nie neguję tego, że przykłady i ćwiczenia "ogólne" mogą być przydatne. Myślę, że mogą one uczyć "ładnego" i poprawnego pisania kodów z wykorzystaniem większej ilości elementów języka.

(oczywiście KAŻDY nie oznacza rozdziałów, w których jest to nierealizowalne, jak np. rozdział O podręczniku) --uniq 13:30, 26 sty 2006 (UTC)

Zgodzę się. A co myślicie, żeby zamiast do rozdziału, do każdej części przygotowywać ćwiczenia? --Piotr K. 14:23, 24 sty 2006 (UTC)

Powinniśmy się zastanowić do czego ma służyć ten podręcznik. Czy ma w nim być dużo ćwiczeń i zadań do wykonania przez czytelnika, czy ma to być raczej sucha teoria. Musimy znaleźć jakieś optimum. Kwestia ćwiczeń do tej pory w ogóle nie była rozpatrywana. Ja w każdym razie mam zamiar dopisać ćwiczenia do rozdziałów nad którymi pracuję ... jak tylko znajdę na to czas. --uniq 13:30, 26 sty 2006 (UTC)

Ja uważam, że ćwiczenia są jak najbardziej potrzebne. W czym one Wam przeszkadzają? Czytelnik niezainteresowany ich po prostu nie wykona! A gdzieś chyba wcześniej jest napisane, że to jest KURS, a nie wykład akademicki. Najlepiej pod koniec jakiegoś rozdziału dopisać kilka(naście) różnych ćwiczeń, które w najbardziej obrazowy sposób przedstawiają dane zagadnienie. A jeszcze lepiej, żeby na osobnej stronie (chodzi o to, żeby czytelnik od razu nie zobaczył gotowego rozwiązania, tylko się trochę nad nim pomęczył) było omówienie i rozwiązanie. Kochani! Czemu się tak boicie przybytku? Od niego głowa nie boli! A wiki-projekty dążą do doskonałości, a nie do fuszerki. Mariush 21:28, 12 lip 2006 (UTC)

Nawigacja

Proponuję, żebyśmy ustalili sposób nawigacji po podręczniku. Ja bym najchętniej widział Szablon:ProstaNawigacja, ponieważ jest już w podręczniku C i nie kłuje w oczy jak Szablon:Prognav (którego kolory bardzo mi się nie podobają). --Derbeth ^talk 12:25, 11 lut 2006 (UTC)

Edycja/Dodawanie podstron ,a kwestia druku

Zastanawiam się ,czy konieczne jest aby na wydrukowanym dokumencie pojawiły się takie elementy jak Szablon:niekompletne,Szablon:TODO,Szablon:merge itp.Nie neguję potrzeby ich wstawiania ,lecz było by lepiej obramować ich uchwyty tagiem <noinclude>...</noinclude> dzięki czemu nie pojawią się na wydruku ,a i tak będą pełniły swoje role. --Felix 10:01, 12 lut 2006 (UTC)

Dodawanie noinclude jest zupełnie niepotrzebne, bo wszystkie szablony porządkowe mają (powinny mieć) klasę CSS noprint, która powoduje, że nie widać ich na wydruku. W sumie fatygujesz się niepotrzebnie z wstawianiem tego noprint po rozdziałach i lepiej, żebyś tego nie kontynuował, bo zaciemnia to kod. --Derbeth ^talk 10:46, 12 lut 2006 (UTC)

Podręcznik na innej wiki

http://pl.cpp.wikia.com/ Jest już tworzony taki podręcznik. Czy chcemy go wykorzystać, czy możemy się porozumieć z tamtymi autorami? Czy może jest to nieetyczne (chociaż licencja na kopiuj/wklej pozwala)? --Rofrol 09:44, 19 cze 2006 (UTC)

Jestem przeciwny kopiowaniu. Wolałbym, żeby podręczniki na Wikibooks były tworzone niż skąś przekopiowywane. --Piotr K. ^@ 11:55, 19 cze 2006 (UTC)

Możemy bez pytania się kogokolwiek kopiować co nam się podoba, wpisując źródło w opisie zmian - tamto wiki jest na GFDL. Z tym, że ich podręcznik jest raczej ubogi i nie do końca pasuje koncepcyjnie do naszego (mamy osobno kurs C i osobno C++). Ale jeśli jest tam coś dobrze napisanego, czego my nie mamy - można kopiować. --Derbeth ^talk 19:44, 19 cze 2006 (UTC)

A nie lepiej skorzystać z innych wersji językowych wikibooks? np. http://en.wikibooks.org/wiki/Wikibooks:Programming_languages_bookshelf#C_.E2.80.93_Fortran Przetłumaczenie tego na Polski, oczywiście dostosowanie do już istniejących założeń formatowania, formy, itp., zajmie dużo mniej czasu.

Błędy w rozdziale System typów

Deklaracja vs. definicja!

Słowa deklaracja i definicja są używane zamiennie. Znaczą one jednak co innego. I tak na przykład: int liczba = 7; nie jest deklaracją, a definicją! Ponadto każda deklaracja zmiennej bez słowa extern jest definicją. Jest to dobrze opisane tutaj Thinking in C++ Ania 13:31, 30 sty 2007 (CET)

Niestety muszę się z Tobą zgodzić. W wielu przypadkach te dwa słowa są nawet nie mylone, a po prostu mieszane, jakby nie było między nimi różnicy. Najlepiej chyba będzie stworzyć na początku całego artykułu słownik, podstronę wyjaśniającą co jest czym. Można by przy tej okazji szczegółowo wyjaśnić nie tylko tę niejednoznaczność.

77.253.116.1 (dyskusja) 16:04, 4 gru 2010 (CET)

Programowanie orientowane obiektowo?

Czy w rozdz. 3 sekcji 2 nie mogłoby być: Programowanie zorientowane obiektowo? To "orientowanie" na obiekty brzmi nienaturalnie i osobiście przyznam się, że nigdy nie spotkałem się z tym w lit. fachowej (np. Podstawy języka C++, Lippman S.B., Lajoie J.).

Symfonia C++. Programowanie w języku C++ orientowane obiektowo. Tomy 1,2. Tu nie chodzi o "zorientowanie" (czyli nakierowanie, skoncentrowanie się), tylko o orientację (decydowanie) na podstawie obiektów, a nie zadanych z góry warunków, o tym, co program ma robić; o wykorzystanie polimorfizmu. --Derbeth ^talk 00:22, 8 lut 2007 (CET)

Zgodnie ze słownikiem języka polskiego na stronie PWN:

• orientować

1. «informować o czymś lub pomagać w zrozumieniu czegoś»,
2. «nadawać czemuś kierunek, wyznaczać zakres lub linię postępowania»,
3. «ułatwiać rozeznanie się w terenie»,
4. «ustawiać w stosunku do czegoś»;

• zorientować

1. «pomóc komuś zrozumieć coś»,
2. «nadać czemuś jakiś kierunek»,
3. «ustawić coś w odpowiednim położeniu».

Natomiast zgodnie z Małym słownikiem języka polskiego (PWN, Warszawa 1969):

• orientować

1. «poinformować kogo o czym, pomóc w zrozumieniu czego; ułatwić rozeznanie w czym»;

• zorientować

1. «poinformować kogo o czym, pomóc w zrozumieniu czego; ułatwić rozeznanie w czym»,
2. «nadać czemu odpowiednie położenie; właściwie co ustawić, skierować».

Zatem internetowy słownik nie wykazuje różnic w znaczeniu obu słów, natomiast zgodnie ze słownikiem papierowym termin "orientowane obiektowo" raczej nie odnosi się do paradygmatu programowania stosowanego w języku C++. Również, IMO, słowo orientowany brzmi tragicznie i wygląda na na siłe przetłumaczone z języka angielskiego tak, żeby akronim OOP jako tako pasował (no bo w końcu orientowane obiektowo programowanie). Na marginesie można jeszcze dodać, że również wujek Google wydaje się preferować termin zorientowane obiektowo. -- mina86 (talk) 12:50, 8 lut 2007 (CET)

"Przeciążanie funkcji" też brzmi tragicznie, a jakoś się przyjęło. Wg mnie lepsze jest "orientowane" bo "zorientowane" wprowadza niejednoznaczność (ma dużo szersze znaczenie). Chodzi o to, by ktoś nie pomyślał, że w OOP chodzi o to, że programowanie jest zorientowane na obiekty (programowanie zorientowane na obiekty to właściwie definicja Object-Based Programming, czyli czegoś zupełnie innego niż OOP). Przy użyciu "orientowania" nie ma możliwości takiej pomyłki. Odbijając piłeczkę: spotkał się ktoś z terminem "programowanie orientowane obiektowo" w literaturze fachowej? Google nie jest żadnym wyznacznikiem poprawności językowej. --Derbeth ^talk 13:30, 8 lut 2007 (CET)

---

No właśnie problem w tym, że jeden słownik podaje prawie identyczne znaczenie obu terminów, a drugi wskazuje, takie znaczenia, że jedynie zorientowane pasuje. Osobiście muszę się przyznać, że za grosz nie rozumiem tego co mówisz, bo nie dostrzegam dużej różnicy znaczeniowej obu terminów przez co nie wiem czemu termin zorientowane miałoby wprowadzać jakąś niejednoznaczność, której rzekomo termin orientowane nie wprowadza.

OOP jest nakierunkowane (zorientowane) na tworzenie obiektów, które posiadają jakieś swoje cechy i można na nich wykonywać różne akcje. Jeśli chodzi o OBP to osobiście przyjąłbym analogię z języka angielskiego i określenie programowanie bazujące na obiektach.

Należy jeszcze zauważyć, iż terminy programowanie zorientowane obiektowo, programowanie orientowane obiektowo, protramowanie zorientowane na obiekty oraz (nie poruszane dotychczas) programowanie orientowane na obiekty znaczą dokładnie to samo, a mianowicie nic. Wynika to z tego prostego faktu, że nie wiadomo co to jest obiekt - w OBP obiekt jest czymś zypełnie innym niż w OOP. W tym pierwszym to tylko śmiesznie nazwana struktura ze śmiesznymi funkcjami, w tym drugim to byt znacznie bardziej skomplikowany, który, mimo że nazywa się tak samo, może wyglądać i działać zupełnie inaczej.

Z tego powodu równie dobrze można OOP nazwać programowanie bazujące na obiektach (tutaj obiektami są byty, w których występuje dziedziczenei i polimorfizm), a OBP - programowanie orientowane obiektowo (tutaj obiektami są śmiesznie nazwane struktury ze śmiesznymi funkcjami). A ponieważ tak właśnie jest i mamy spory wybór (w przypadku przeciążania funkcji raczej nie było innych opcji), to po pierwsze lepiej pozostać przy analogii do określeń angielskich (nie ma tutaj kłopotu z dziwnym niepotrzebnym słowotwórstwem tylko zwykłe tłumaczenie terminów), a po drugie lepiej wybrać to co ładniej brzmi.

A jeżeli chodzi o Google, to chyba wyraźnie napisałem, że na marginesie można dodać. :) -- mina86 (talk) 19:24, 8 lut 2007 (CET)

Widzę, że puszczasz tu wodze swojej fantazji; z tym, że podręcznik piszemy nie na podstawie tego, co tobie się wydaje, ale na podstawie tego, co jest ogólnie przyjęte, co można znaleźć w literaturze fachowej. Co to znaczy, że "obiekt nic nie znaczy"? Obiekt można dość dobrze zdefiniować jako byt abstrakcyjny (znośna definicja jest na Wikipedii), do tego język programowania narzuca ci konkretną definicję. Stwierdzenie, że w OBP i OOP używa się czego innego nazywając to obiektem jest zupełnie bezpodstawne, zarówno na poziomie abstrakcji jak i konkretu. Po prostu w obu podejściach inaczej korzysta się z obiektów. Niby czemu obiekt, z którego korzystam jak z pojemnika na funkcje, przestaje być obiektem? To tak, jakby auto, którym nie jeżdżę, stawało się radiem.

Przeczytaj sobie [1] - są tam głosy Boocha i Stroustrupa, czyli niewątpliwych autorytetów, którzy rozróżniają OBP i OOP. Zobacz sobie, co mówi Stroustrup: OOP polega na tym, że informacja o typie jest przechowywana w każdym egzemplarzu obiektu. Tak więc "oriented" oznacza nie to, że interesują nas obiekty, tylko to, że to obiekty są podstawą "orientacji", sterowania systemem - bo to w nich jest zachowanie, a nie na sztywno w kodzie. Polecam zaznajomienie się z terminem w:programowanie sterowanie zdarzeniami. Tu jest "programowanie sterowane obiektami", czyli "programowanie orientowane po obiektach".

A w ogóle gdzie widzisz słowotwórstwo, skoro i "orientowany" oraz "zorientowany" są dawno znanymi słowami polskimi?! To w przytoczonym przez ciebie "przeciążaniu" wybór właśnie jest, bo tłumaczenie "overload" na "przeciężenie" jest prymitywną, dosłowną kalką; tłumaczeniem litera po literze nie patrząc na to, że wynik znaczy zupełnie coś innego (czy którykolwiek matematyk albo fizyk przeciążył kiedyś oznaczenie? No nie). Opcja jest - jest to "przeładowanie", które też jest spotykane w literaturze i jest bardziej zrozumiałe (nikt z nas nigdy raczej niczego nie przeciążył, natomiast jak najbardziej można przeładować np. broń i "przeładowanie operatora" jest metaforą, która ma jakieś podstawy w życiu codziennym). Nie spieram się tu o to, bo to fatalne moim zdaniem tłumaczenie zastało się w terminologii i nie ma sensu robić rewolucji, bo Wikibooks nie jest miejscem na kreowanie nowych wzorców językowych.

Moim zdaniem w ogóle nie masz podstaw teoretycznych i produkujesz jakieś swoje przemyślenia na podstawie twojej wiedzy praktycznej - i dlatego nie dziwi mnie, gdy nie rozumiesz problemu z wieloznacznością "zorientowania" czy też przytaczasz "przeciążenie" jako "jedynie słuszny" termin. To, co chcesz tu uskuteczniać, to original research, czyli pisanie podręcznika według swojego widzimisię, tego, co moim zdaniem jest lepsze. Ja podpieram się konkretnymi źródłami pisanymi - ty do tej pory nie podałeś żadnego. --Derbeth ^talk 20:45, 8 lut 2007 (CET)

Zgadzam się z Derbethem, używać powinniśmy fachowej terminologii a książki Pana Grembosza w tej dziediznie uchodzą za fachowe. Próby zamiany używanej powszechnie terminologii na bełkotliwe tłumaczenia ze względu na brak oczytania w dziedzinie uważałbym za bezpodstwne. Szczególnie że bazowanie tylko na słowniku języka polskiego jest bezpodstawne w przypadku terminologii nauk scisłych, gdzie definicja danego słowa jest całkiem odmienna od jej ekwiwalentu językowego. Na tym polega właśnie "język naukowy". Ponadto należy pamiętać, że nawet w słowniku pojęć danej dziedziny naukowej nie jest podane pełne znaczenie danego słowa - i wg słownika słowa mogą wydawać się pokrewne, natomiast w praktyce być zupełnie różne. To podstawowa różnica między Wikisłownikiem, Wikipedią a Wikibooks - bowiem na Wikibooks nie tworzymy zbioru definicji pojęć, ale podręczniki które w sposób dydaktyczny a zarazem fachowy wykazywać będą właśnie te różnice. MonteChristof DMC 21:24, 8 lut 2007 (CET)

Widzę, że puszczasz tu wodze swojej fantazji; -- tzn. w którym miejscu?

Co to znaczy, że "obiekt nic nie znaczy"? -- znaczy dokładnie to co napisałem, że obiekt to słowo, które dla OOP znaczy coś innego niż dla OBP. W języku C też są obiekty, ale jakoś nikt nie klasyfikuje tego języka jako obiect oriented ani jako object based.

Obiekt można dość dobrze zdefiniować jako byt abstrakcyjny (znośna definicja jest na Wikipedii), -- oczywiście, że można, ale dla konkretnego języka definicja może być conajmniej niepełna lub wręcz niepoprawna (np. w języku C obiekt nie posiada cechy zachowania).

do tego język programowania narzuca ci konkretną definicję. -- właśnie potwierdziłeś to co mówiłem od samego początku, że definicja obiektu zależy od języka.

Stwierdzenie, że w OBP i OOP używa się czego innego nazywając to obiektem jest zupełnie bezpodstawne, -- oczywiście, że ma to podstawy i to bardzo solidne.

zarówno na poziomie abstrakcji jak i konkretu. -- a fakt, że w OBP nie ma dziedziczenia to tylko taki mały pikuś bez znaczenia, prawda?

Po prostu w obu podejściach inaczej korzysta się z obiektów. -- nie, w obu podejściach korzysta się z czegoś odrobinę innego.

Niby czemu obiekt, z którego korzystam jak z pojemnika na funkcje, przestaje być obiektem? To tak, jakby auto, którym nie jeżdżę, stawało się radiem. -- auto, którym nie jeździsz staje się autem, którym nie jeżdzisz. Auto, którym nie możesz jeździć staje się śmiesznie wyglądającym wozem potrzebującym zaprzęgu koni.

Zobacz sobie, co mówi Stroustrup: OOP polega na tym, że informacja o typie jest przechowywana w każdym egzemplarzu obiektu. -- jak zwał tak zwał, rozchodzi się o polimorfizm.

Tak więc "oriented" oznacza nie to, że interesują nas obiekty, tylko to, że to obiekty są podstawą "orientacji", -- a może podstawą zorientowania?

A w ogóle gdzie widzisz słowotwórstwo, skoro i "orientowany" oraz "zorientowany" są dawno znanymi słowami polskimi?! -- nie widzę, przeczytaj jeszcze raz co napisałem.

Moim zdaniem w ogóle nie masz podstaw teoretycznych i produkujesz jakieś swoje przemyślenia na podstawie twojej wiedzy praktycznej - i dlatego nie dziwi mnie, gdy nie rozumiesz problemu z wieloznacznością "zorientowania" -- czy tak jest czy nie jest, nie ma żadnego znaczenia. Podaje argumenty, które Ty możesz kontrować. Argument ma zawsze taką samą moc niezależnie czy wypowie go geniusz czy głupiec. To ludzie myślą, że jak głupiec coś powie to to musi być głupie, a jak mędrzec coś powie to to musi być mądre - w istocie może być dokładnie na odwrót, tak więc nie sprowadzaj dyskusji na moją osobę.

czy też przytaczasz "przeciążenie" jako "jedynie słuszny" termin. -- faktycznie, trochę źle się wyraziłem. Chodziło mi o to, że wszystkie inne terminy też kiepsko oddają sens operacji przeciążania funkcji. Przeładowywanie też ma się nijak do funkcji (równie dobrze mogę powiedzieć, że przeciążenie funkcji to metafora) - żaden matematyk ani fizyk nie przeładował przecież oznaczenia.

Ja podpieram się konkretnymi źródłami pisanymi - ty do tej pory nie podałeś żadnego. -- osoba, która rozpoczęła wątek podała za przykład Podstawy języka C++, Lippman S.B., Lajoie J. Do tego dochodzi jeszcze Język C++ Bjarne Stroustrupa, oraz Thinking in C++ i Thinking in Java Bruce'a Eckela (np. strona 40 tego ostatniego: W tym rozdziale przedstawię podstawowe idee programowania zorientowanego obiektowo (OOP)). Również na wydziale MiNI PW jest przedmiot Programowanie zorientowane obiektowo, a na EiTI PW wykładowca od Programowania obiektowego zawsze używał zwrotu zorientowane. -- mina86 (talk) 16:16, 9 lut 2007 (CET)

I jeszcze jedna: Projektowanie zorientowane obiektowo. Wzorce projektowe. -- mina86 (talk) 16:47, 9 lut 2007 (CET)

A na UJ jest "programowanie obiektowo orientowane". Dalej uważam, że nie rozumiesz OBP i OOP. OBP nie polega na tym, że nie ma możliwości dziedziczenia, tak samo jak w programowaniu strukturalnym nie chodzi o to tylko, że nie ma obiektów. OBP różni od OOP nie to, czym jest język, ale jak się z niego korzysta. W obu podejściach korzysta się z dokładnie tych samych obiektów; możesz napisać dwa programy w tym samym języku, które korzystają z tych samych klas, ale jeden będzie OBP a drugi w OOP.

Wracając do meritum. Może faktycznie lepiej będzie wybrać to, co jest aktualnie "na topie". Jeśli nowsze książki wolą "zorientowanie", to niech i tak będzie. Chyba warto poświęcić poprawnośc na rzecz zrozumiałości. --Derbeth ^talk 17:21, 9 lut 2007 (CET)

Oczywiście, że w języku (z)orientowanym obiektowo można pisać programy bazujące na obiektach (OBP), jednak cokolwiek trudno będzie (a przynajmniej nie obejdzie się bez ręczenj implementacji dziedziczenia lub innego mechanizmu, który pozwoli na stworzenie polimorfizmu) pisać programy (z)orientowane obiektowo w językach bazujących na obiektach.

I nadal nie widzę czemu zorientowane miałoby być mniej zrozumiane niż orientowane. Jeżeli ktoś nie rozumie co to OOP i OBP to niezależnie od tego jak te terminy przetłumaczymy i tak tego nie zrozumie, zwłaszcza, że nadal nie sądzę, aby pomidzy tymi terminami była jakaś istotna różnica w znaczeniu.

Na koniec mogę jeszcze dodać, że zawsze można korzystać z terminu programowanie obiektowe dla OOP oraz programowanie bazujące na obiektach dla OBP. -- mina86 (talk) 17:38, 9 lut 2007 (CET)

Tu po raz kolejny puszczasz wodze fantazji. Takich uproszczeń nie powinno się uskuteczniać.

Dlaczego "zorientowany" miałoby być bardziej zrozumiałe? Bo wygląda na to, że tendencja wśród tłumaczy jest taka, by używać raczej pierwszego terminu. To niedobrze, ale skoru już tak jest, to lepiej ujednolicić słownictwo, by ktoś, kto do nas przychodzi, nie był zdziwiony dziwną terminologią. --Derbeth ^talk 18:40, 9 lut 2007 (CET)

A Ty znowu z tą fantazją - zupełnie nie wiem skąd Ci się to wzieło... Termin programowanie obiektowe jest bardzo często używany. W języku C++ oraz TIC++ nawet on dominuje. A jeśli chodzi o zorientowany, to na odwrót - nie wiem czemu uważasz, czemu jest to słówko (wg Ciebie) gorsze od orientowane. Ale już mniejsza z tym. -- mina86 (talk) 21:59, 9 lut 2007 (CET)

Ja spotkałem się z terminem "programowanie zorientowane obiektowo", dla mnie "orientowane" też trochę dziwnie brzmi. Google też pokazuje, który termin jest bardziej znany. --Piotr ^@ 12:59, 10 lut 2007 (CET)

Widzę, że z mojego pytania wynikła jakaś mała wojenka. Po przeczytaniu dyskusji podtrzymuję swoje wątpliwości co do nienaturalnego brzmienia "programowania orientowanego obiektowo". Nie chcę forsować zmiany tego określenia na "programowanie zorientowane obiektowo" natomiast mam inną propozycję. Może za wspominaną przeze mnie książką użyć terminu programowanie obiektowe? Wydaje się to dosyć naturalne i logiczne a przede wszystkim jest neutralne w świetle tej małej wojenki jaka się tutaj toczy :) . Proponuję też przetłumaczyć OBP jako programowanie w stylu obiektowym. Niepokoi mnie natomiast dyskusja na temat przeciążania funkcji. Przeładowywanie to jakiś nonsens. Przeładować można ciężarówkę z węglem albo karabin (jak ktoś napisał) jednak w informatyce od dawna używa się słowa przeciążyć w odniesieniu do ang. terminu function overload. Co do tendencji wśród tłumaczy to zapatrywał bym się raczej na tych z powszechnie znanych i cenionych wydawnictw informatyczno-naukowych w Polsce jak np. WNT czy Helion. Webprog 16:06, 14 lut 2007 (CET)

WNT przestało być dla mnie szanowane po tym, jak zaczęło stosować termin "wzorzec" w znaczeniu "szablon". Jak dla mnie jest to idiotyzm i dziwi mnie, że tak poważne wydawnictwo zaczęło promować niepoprawne i wymyślone przez siebie słownictwo. Jeśli WNT jest w stanie popełnić "wzorce", to jest w stanie popełnić wszystko i w tej chwili nie ufam im za grosz.

Co do przeładowania/przeciążenia: "przeładowania" też się dość często używa. Dla mnie "przeciążenie" jest tworem sztucznym (nie jest używane w języku polskim w kontekście zbliżonym do informatycznego, nie mamy metafor, idiomów z jego użyciem), stworzonym na skutek nieumiejętności tłumaczenia (dosłowne tłumaczenie idiomu, jakim jest niewątpliwie "function overload") i jedynym argumentem, który za nim przejawia, jest to, że pojawia się częściej. Jak już pisałem, nie zamierzam forsować użycia w podręczniku "przeładowania", bo uważam, że nie powinniśmy zmieniać radykalnie słownictwa.

Tłumaczenie OOP na "programowanie obiektowe" a OBP na "programowanie w stylu obiektowym" to original research (a przynamniej to drugie jest), czyli produkowanie własnej terminologii bez oparcia w źródłach. Original research jest zakazane na Wikibooks, ponieważ mamy być wiarygodnym źródłem wiedzy. Ale tak w ogóle to możemy nie pisać o OBP i OOP. Rozdział "Programowanie orientowane obiektowo" może równie dobrze wylecieć; o tym, jak pisać programy sterowane obiektami można napisać od biedy w rozdziale o funkcjach wirtualnych. --Derbeth ^talk 19:53, 14 lut 2007 (CET)

Przeładować można samochód, czyli np. wyładować z niego dotychczasową zawartość i załądować nową; przeładować można również magazynek, tzn. wyjąć z pistoletu magazynek pusty i włożyć pełny. Przeciążyć można np. samochód, tzn. załadować na niego towar ważący więcej niźli samochód jest w stanie przewieźć. I teraz, czemu operacja tworzenia funkcji o takich samych nazwach, ale rozróżnianych po liście parametrów jest bliższe słowu "przeładować" niż "przeciążać"? Osobiście skojarzenie do przeciążania mam (tzn. na jedną nazwę funkcji ładujemy wiele konkretnych funkcji, czyli więcej niż normalnie identyfikator może "udźwignąć"), natomiast do przeładowanai nie.

Podobnie nie wiem czemu wzorzec jest taki jakiś bardzo super-hiper naganny, choć przyznaję, że (obecnie) lepiej stosować słowo szablon.

Jeśli chodzi już o te (z)orientowanie, to proponuję stosować "programowanie obietkowe", bo jest to termin ogólnie przyjęty w literaturze i już tutaj koledze Derbethowi dwuznaczność słowa zorientowany nie będzie przeszkadzać. :)-- mina86 (talk) 21:28, 14 lut 2007 (CET)

"Template" nie można przetłumaczyć na "wzorzec" z bardzo prostego powodu, a mianowicie takiego, że żaden słownik angielski nie daje podstawy takiego tłumaczenia. Wzorzec to pattern, template to szablon i tu nie ma żadnego pola manewru, to nie jest poezja, żeby z jednego słowa zrobić 10 a z psa kota. Tłumacz _nie ma prawa_ przetłumaczyć "template" na "wzorzec", choćby czuł się mądrzejszy od Stroustrupa i całego komitetu standaryzacyjnego C++ razem wziętego i wyjaśnia, że szablon jest z papieru a wzorzec jest abstrakcyjny. Jak ktoś jest taki mądry to niech najpierw przekona tych panów. Dodatkowymi czynnikami są: głębokie zakorzenienie tłumaczenia "template" na "szablon" w polskiej terminologii informatycznej od Worda po podręczniki C++ oraz "design patterns", co do których zgodnie (jak na razie) przyjęło się tłumaczenie "wzorce projektowe", tak więc "wzorce" panów z WNT wprowadziłyby niezłe zamieszanie gdyby zaczęto ich używać. Ja nie mam wątpliwości, template-wzorzec to przestępstwo językowe i Wydawnictwo Naukowo-Techniczne zapisało się czarnymi zgłoskami w historii polskiej literatury informatycznej. --Derbeth ^talk 21:43, 14 lut 2007 (CET)

Cieszę się, że pomimo różnicy zdań powoli wykluwa się jakaś wspólna idea. Jeśli już podjęto temat kompetencji wydawnictw to zaryzykuję stwierdzenie iż WNT wydało bardzo wiele pozycji o ogromnych walorach merytorycznych. Przyznam szczerze, że wolę książki tego wydawnictwa, w których znajdują się rzetelne informacje a nie wypociny Pana Kowalskiego z wyższej szkoły marketingu i informatyki, który w książce pt. "język C++" pisze o języku C w Borland C++ dla DOSa i jak to było 20 lat temu. WNT było i jest źródłem dobrych i aktualnych książek. Co do szablonów to czy przypadkiem nie chodziło o tłumaczenie wzorców projektowych z ang. design patterns a nie ze słowa templates? Mam książkę pt. Nowoczesne projektowanie w C++ WNT i tam używa się właściwie słów szablony i wzorce. Oczywiście każdy może mieć swoje zdanie i ulubione wydawnictwo. Czy przy Wikipedii działa jakaś rada języka polskiego? A może dałoby się zasięgnąć rady u jakiś językoznawców w takich spornych sprawach jak ta?

Język Polski dopiero się rozwija w dziedzinie informatyki a Wikipedia razem z nami przyczynia się do tego rozwoju. Prawdopodobnie wiele prac już powstało i powstanie w oparciu o to co MY tu umieściliśmy. Zatem może warto zadbać o poprawność języka nie koniecznie podążając za nie zawsze dobrymi przykładami. Webprog 22:15, 14 lut 2007 (CET)

Unicode

Myślę, że należałoby dodać do podstawowych typów wchar_t oraz napisać w dziale String o istnieniu klasy wstring, która to działa na wchar_t. Może warto byłoby dodać w ogóle nowy rozdział o korzystaniu z Unicode? Coraz częściej się z niego korzysta, więc myślę, że warto byłoby użyczyć mu rozdziału, bo na sieci nie jest o tym wiele. Mogę napisać ten rozdział jeśli nie będzie sprzeciwów. --Mythov

Żadnych sprzeciwów nie będzie :) Dopisz wchar_t do C++/System typów#Zmienne liczbowe, możesz też zacząć rozdział np. pod tytułem C++/Korzystanie z Unicode.

W ogóle podręcznik C++ jest w złym stanie i napisany według mnie kiepsko. Jeśli masz ochotę, możesz poprawiać w nim co chcesz, usuwać rzeczy źle napisane, bylebyś tylko nie zmieniał konstrukcji spisu treści i nie powielał rzeczy z podręcznika do C. --Derbeth ^talk 15:09, 9 sie 2007 (CEST)

proponowane zmiany

Jeśli nie będzie sprzeciwów połączę rozdziały "System typów" i "Zmienne" w jeden rozdział o nazwie np. "Zmienne" oraz "Kontrola dostępu" wrzucę do "Czym jest obiekt".<br\ > Nie rozumiem też przeznaczenia rozdziału "Klasy i typy zagnieżdżone". Typy zagnieżdżone to po prostu np. klasa w której jest zadeklarowany obiekt innej klasy? Na necie z kolei znalazłem, że typy zagnieżdżone doszły w C#. Co ma znaczyć opis tego rozdziału "Tworzenie klas i typów zagnieżdżonych", przecież opis tworzenia klas jest w rozdziale "Czym jest obiekt"?<br\ > Nie rozumiem także rozdziału "Wskaźniki do elementów składowych - Wykorzystnie wskaźników do elementów składowych klas". Co konkretnie powinno się tam znaleźć?<br\ > Poza tym rozdział "Dziedziczenie wielokrotne" wrzuciłbym do "Dziedziczenie", bo ten o dziedziczeniu wielokrotnym ma zbyt zawężoną tematykę, żeby robić oddzielny rozdział. --Mythov 20:17, 10 sie 2007 (CEST)

Co do zmiennych - ok, ale weź pod uwagę, że rozdziały te mają w zasadzie wyliczać nowości w stosunku do C; ewentualnie może pojawić się parę tabelek/kilka zdań przypomnienia, ale nie ma co wyjaśniać, co to jest int i jak zrobić tablicę znaków. Kontrola dostępu chyba faktycznie jest trochę sztucznie rozdzielona, więc też ok. Klasy i typy zagnieżdżone to coś takiego:

class Zewnętrzna {
  private:
  class Wewnętrzna { // klasa zagnieżdżona
    int a;
  };

  public:
  typedef Wewnętrzna* WewWsk; // typ zagnieżdżony
};
Zewnętrzna::WewWsk b;

Jest to niewiele nowego ponad to, co jest wspomniane w przestrzeniach nazw i kontroli dostępu; może faktycznie lepiej wrzucić to pod rozdział "co to klasa" - ale czy to dobrze, jeśli początkujący czytelnik zostanie zarzucony od razu tyloma szczegółami?

Dziedziczenie wielokrotne musi absolutnie być później, bo jest to rzecz trudna i pełna pułapek. Nie ma co moim zdaniem od razu straszyć tym czytelnika. --Derbeth ^talk 20:37, 10 sie 2007 (CEST)

Skoro tak uważasz, nie dotykam dziedziczenia wielokrotnego i typów zagnieżdżonych. Niedługo się zabiorę za przerabianie reszty. --Mythov 20:45, 10 sie 2007 (CEST)

link leży: "404 Not Found"

http://www.i-lo.tarnow.pl/edu/inf/utils/rozinf/index.html - ten link leży(rzecz jasna w tej chwili) Materiały koła informatycznego I Liceum Ogólnokształcące w Tarnowie mgr Jerzy Wałaszek - C++, SDL, drzewa ( licencja GNU FDL )

Pojęcia nie mam gdzie to zgłosić, więc tu piszę.

ps. http://edu.i-lo.tarnow.pl/index.php - to gdzieś tu chyba?

Nowe zmiany

Wprowadziłem drobną zmianę zamiany nazwy: [2] oraz połączyłem ze sobą moduły O podręczniku z Jak czytać ten podręcznik. Dodalem też konwencje do modułu Dla autorów, aby możliwie uspójnić styl kodu (zaproponować konwencje lub otworzyć możliwość dyskusji nad zmianami tych które są) --Lethern (dyskusja) 05:53, 1 lis 2011 (CET)

Nie wiem czy się to nada

Ale jakiś czas temu zacząłem pisać coś o QT4. Ponieważ o referencjach jak o wskaźniku "this" w tej książce jest mało więc klepnąłem dwa rozdziały w celu uzupełnienia informacji. Jak ktoś z autorów tej książki uzna, że to co mi wyszło jest ok to mogę przekopiować tu. dam linki.

https://pl.wikibooks.org/wiki/Programowanie_C%2B%2B_Qt4_w_systemie_Gnu-Linux/Referencje_w_C%2B%2B https://pl.wikibooks.org/wiki/Programowanie_C%2B%2B_Qt4_w_systemie_Gnu-Linux/Wska%C5%BAnik_%27%27%27this%27%27%27

Nowy C++

Cześć, przejrzałem pobieżnie ten podręcznik i widzę, że w ogóle nie są ruszone tematy bardziej zaawansowane i ogólnie nowsze (z C++11):

• auto/decltype
• lambdy
• r-referencje
• tzw. smartpointery
• metaprogramowanie (SFINAE, specjalizacje i częściowe specjalizacje szablonów)
• wątki
• wyrażenia regularne

W jakich rozdziałach można te rzeczy opisać? Czy ten podręcznik jest w ogóle jeszcze rozwijany?

Wojciech mula (dyskusja) 17:58, 11 paź 2014 (CEST)

• Na booksach jest naprawdę mały ruch, po za kilkoma osobami które rozwijają podręczniki z dziedziny fizyki (jedna programistyczną nie ma tu nikogo i wszystko się starzeje. Marzenie by książki nadążały za zmianami nie wyszło - i choć najwięcej jest książek informatycznych to bardziej aktualne informacje i tak znajdziemy prędzej w dokumentacji.

jeśli chcesz przejąć podręcznik, najłatwiej napisać o C++11 po prostu dodając kolejny rozdział, podobnie jest w książce HTML pozdro Kompowiec2 (dyskusja) 22:05, 11 paź 2014 (CEST)