Język C / C++ / C# / Java - pytania, problemy...

[ziptofaf 2]

(...)

Dnia 30.09.2010 o 15:29, Olamagato napisał:

7. Po co w ogóle zintegrowano w obiektach strumieniowych formatowanie?

Na co, nawiasem mówiąc, początkujący programista raczej nie zwróci uwagi. Reszty argumentów nie obalę.

/.../

Dnia 30.09.2010 o 15:29, Olamagato napisał:

Jak do tego dołożyć niesamowicie nieczytelną składnię szablonów (templates) z osobno
wrzuconą koncepcją definiowalnych operatorów, to przebrnięcie przez to przez początkującego
jest naprawdę trudnym zadaniem.

Mając do wyboru szablony kontra preprocesor, chyba stawiałbym na szablony. Dla przykładu, najbardziej typowe zagadnienie - mamy obiekt, który chcemy, by był definiowany danymi dowolnego typu.
W przypadku szablonów zasadniczo szczególnie trudne to nie jest, kwestia jednej dodatkowej linii kodu:
template <typename T> i później pozostaje tylko już w samej klasie trzymać się naszej literki T.
Makrodefinicje z kolei...teoretycznie kod nie będzie dłuższy. Za to pojawią się problemy ze sprawdzeniem takiego kodu, bo polecenia preprocesora nie są zbyt dokładnie sprawdzane i w najgorszym wypadku będziemy musieli bawić się komendami G++ -E -P, żeby zobaczyć jaki kod źródłowy tak naprawdę otrzymuje kompilator.

Dnia 30.09.2010 o 15:29, Olamagato napisał:

Oprócz tego nie zostały rozwiązane podstawowe problemy jakie miał język C. Nie zostały
jasno zdefiniowane rozmiary prostych typów danych przez co nagłówki biblioteczne - o
ile w C były ciężkie do przebrnięcia, to w C++ po dołożeniu obiektów stały się prawdziwie
nieczytelnym koszmarem.

Masz na myśli http://www.cplusplus.com/reference/clibrary/climits/ ? Ja tu widzę dość dokładnie podane maksymalne rozmiary (choć faktem jest, że zmieniłyby się gdyby programować w 64-bitach).

Dnia 30.09.2010 o 15:29, Olamagato napisał:

Ilość niespójnych informacji jakie musi wchłonąć osoba ucząca się C++ jest ogromna. Nieporównywalna
w ogóle do niewielkiej skali wyjątków w składni czy semantyce C, Javy czy C#.

Przypomnę jedno - możesz normalnie uczyć się C i "podbierać" niektóre rozwiązania z C++.

Dnia 30.09.2010 o 15:29, Olamagato napisał:

Dlatego jeżeli uczyć się od języka jako pierwszego lub pierwszego obiektowego, to C++
jest najgorszym możliwym wyborem z mnóstwa języków jakie są do dyspozycji.

A to akurat fakt (choć nie do końca, na pewno lepiej uczyć się C++ niż Pascala, przynajmniej ten pierwszy jest wciąż powszechnie wykorzystywany). Ja osobiście naukę zaczynałem od Visual Basica (same podstawy) przez Pythona, na C++ na razie skończywszy, Javę dopiero zaczynam poznawać.

Dnia 30.09.2010 o 15:29, Olamagato napisał:

C++ jest kompletnie zbędny.

I tak, i nie. C++ stanowił pomost dla programistów C. I to dobry pomost, bo jednak ten język jest jego ewolucją. Dziedziczy wszystkie zalety (i wady) C, dorzucając obiektowość. Co doprowadziło do stworzenia olbrzymiej ilości bibliotek, nieporównywalnych z innymi językami (choćby takie Qt które co prawda ma już wersję Javovą, ale to C++ był pierwszy).

Dnia 30.09.2010 o 15:29, Olamagato napisał:

To po co w ogóle programować w C++? Język C oferuje w części nieobiektowej dokładnie
to samo?

A może na odwrót - po co programować w C, skoro przynajmniej niektóre zagadnienia łatwiej rozwiązać w C++ (choćby graficzny interfejs łatwiej zrobić na obiektach niż w inny sposób)? Z całą pewnością nie ma obecnie sensu zostawać w tyle jeśli chodzi o paradygmaty programowania, więc najrozsądniejszym wyjściem jest od razu uczenie się języków obiektowych. Jasne, C++ nie jest najlepszym wyborem (sam osobiście skłaniałbym się obecnie ku Javie, są choćby tablice szarpane i pełnoprawna wielordzeniowość, a nie jej namiastka), ale jednocześnie lepszym niż C.

Dnia 30.09.2010 o 15:29, Olamagato napisał:

Wskaźniki są obecne we wszystkich programach jakie istnieją. W C mają sens bo jest to
język niskopoziomowy, W Javie i C# są one po prostu referencjami, natomiast w C++ - tu
się zgodzę - nie mają absolutnie żadnego sensu.

(...)

Tutaj pozostaje mi tylko pokiwać głową.

Dnia 30.09.2010 o 15:29, Olamagato napisał:

A czym niby jest vector jak nie tablicą dynamiczną? W C nie było innej możliwości tworzenia
tablic, natomiast w C++ nie usunięto tej możliwości.

Vector to "obudowana" tablica dynamiczna - możesz bezproblemowo zmieniać jego rozmiar, sam też "wie" ile zajmuje miejsca w pamięci. Więc to akurat zaleta dla C++ której C nie posiada. Jasne że sam możesz zrobić sobie coś podobnego w C, ale jak w C++ wręcz ci to wpychają, to aż głupio nie skorzystać.

Dnia 30.09.2010 o 15:29, Olamagato napisał:

Hmm, ale jakim cudem nadzbiór języka funkcyjnego i obiektowego miałby być prostszy od
jego funkcyjnego podzbioru?

Przede wszystkim - poprawiony kompilator. Nie bez powodu zaleca się by nawet programy pisane w czystym C były kompilowane przez kompilator C++. Poza tym STL i mapy (o których użytkownicy C chyba mogą tylko pomarzyć).

Dnia 30.09.2010 o 15:29, Olamagato napisał:

Moim zdaniem jeżeli uczyć się od zera, to głównie C dla złapania składni i potem od razu
Java/C#. Sens uczenia się obecnie C++ jest moim zdaniem żaden. Chyba, żeby jako studium
tego jak nie należy projektować języka programowania. :)

Prędzej - od razu Java. Nauka najnowszych standardów jest z całą pewnością rozsądniejsza niż przestarzałych. Z tego samego powodu dla mnie C++ wydaje się rozsądniejszym wyborem od C.

Dnia 30.09.2010 o 15:29, Olamagato napisał:

ps. Nie weź czasem tego długaśnego posta jako atak na siebie.

Ja go traktuję jako kreatywną dyskusję z której mogę się sporo dowiedzieć ;)


@ Volvox
Nie aż tak początkujący ;)

[Olamagato 3]

Dnia 30.09.2010 o 15:43, Volvox napisał:

On jest początkujący w programowaniu - z całą pewnością nie zrozumiał ani słowa z tego
co napisałeś :)

Hehe. A tyle się naprodukowałem. :D

[Olamagato 3]

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

Makrodefinicje z kolei...teoretycznie kod nie będzie dłuższy. Za to pojawią się problemy
ze sprawdzeniem takiego kodu, bo polecenia preprocesora nie są zbyt dokładnie sprawdzane
i w najgorszym wypadku będziemy musieli bawić się komendami G++ -E -P, żeby zobaczyć
jaki kod źródłowy tak naprawdę otrzymuje kompilator.

No właśnie. Skoro są szablony, to cała koncepcja preprocesora staje się zupełnie zbędna. Niestety nie można z niego zrezygnować ponieważ całe środowisko kompilacji i łączenia programu w C++ opiera się na komendzie #include preprocesora. Wywalenie go wymuszałoby stworzenie kompletnie nowego środowiska łączenia poszczególnych fragmentów kodu źródłowego w jedną aplikację.

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

Masz na myśli http://www.cplusplus.com/reference/clibrary/climits/ ? Ja tu widzę dość
dokładnie podane maksymalne rozmiary

Niestety rozmiary te mimo iż wydają się statyczne, to w rzeczywistości są dynamiczne. Na dodatek nie mają kompletnie nic wspólnego z kompilatorem, który akurat kompiluje bieżący kod. Mówiąc krótko jeżeli kompilator ma w swoim generatorze kodu zapisane, że typ long ma 128 bitów, a w climits.h największą liczbą long jest 2^64-1, to na dzień dobry dostajemy niemal pewność awarii każdego programu, który skorzysta z tego typu. Pogwałcona jest podstawowa zasada projektowania mówiąca o tym, że jedna rzecz musi być zapisana tylko w jednym miejscu.
W prawidłowo zaprojektowanym języku dane które zapisane są w climits.h powinny pochodzić z predefiniowanych publicznych stałych kompilatora, nie z nagłówka.

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

Przypomnę jedno - możesz normalnie uczyć się C i "podbierać" niektóre rozwiązania z C++.

Tylko jakie? Co wg Ciebie istnieje tylko w C++, a mogłoby być wzorem projektowania lub wzorem użycia obiektowego? Bo jak się tak trochę zastanowiłem, to odrzuciłem wszystkich możliwych kandydatów jacy przyszli mi do głowy. Szablony - nie ponieważ mają fatalnie nieczytelną składnię, a koncepcja porównywania interfejsu w momencie konkretyzacji obiektu w przypadku gdyby nie następowała w czasie kompilacji jest niesamowicie nieefektywna obliczeniowo. Natomiast w czasie kompilacji musielibyśmy odrzucić te obiekty, których interfejs poprawnie powstałby w wyniku złączenia dwóch lub więcej klas. Oba przypadki dają sporo kwasu. :)

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

A to akurat fakt (choć nie do końca, na pewno lepiej uczyć się C++ niż Pascala, przynajmniej
ten pierwszy jest wciąż powszechnie wykorzystywany).

A tak. Co do tego, to moim zdaniem masz rację. Chociaż z perspektywy jaką mam obecnie Pascal ma wciąż sporo zalet. Na przykład z powodu długiego zapisu bloków (begin/end zamiast {/}) skłania ku eliminowaniu zbędnych zagnieżdżeń bloków; typy porządkowe z Pascala są moim zdaniem wciąż wzorcowym rozwiązaniem i znacznie górują nad enum z C++; Zasada definiowania wszystkiego co możliwe przed jakimkolwiek użyciem uczy systematyczności i konsekwencji, a także jest znakomitym rozwiązaniem problemu jednoprzebiegowej kompilacji (oczywiście za wyjątkiem przypadku rekurencji). Mimo to oszczędna składnia C ma moim zdaniem sporo więcej zalet niż składnia Pascala. Chociaż w przypadku porównania obiektowej części Delphi oraz C++ postawiłbym na równowagę.

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

I tak, i nie. C++ stanowił pomost dla programistów C. I to dobry pomost, bo jednak ten
język jest jego ewolucją.

Zgadza się. Jako pomost spisuje się doskonale. Dlatego też tyle kodu powstało w C++. Niestety jest to pomost dobry dla doświadczonych już programistów. Dla nowicjuszy C++ jest bardzo niestrawny. To bardzo ciężki język nie skłaniający w żaden sposób nowych programistów do poprawnego kodowania. Te poprawne nawyki trzeba więc wynieść z czego innego niż C++. A to oznacza, że C++ sam się eliminuje z kandydowania do uczenia się go jako pierwszego.

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

Dziedziczy wszystkie zalety (i wady) C, dorzucając obiektowość.

Dziedziczy część zalet C, które niestety w C++ zamieniają się w wady. Na przykład preprocesor, traktowanie braku ustawionych bitów typu stałoprzecinkowego jako fałszywą wartość logiczną, wykorzystanie wszystkich znaków operatorów w swojej składni itp.
Moim zdaniem jedną z niewielu zalet jaką C++ dodawał była koncepcja konstruktora konwertującego jeden typ na inny w zapisie "konstruktor_typu_A(wartość_typu_B)" w przeciwieństwie do słabego rzutowania z C w postaci "(typ_A) wartość_typu_B". Zostało to i tak jednak zarzucone gdy Stroustrup wprowadził osobne i nieprzyjemne składniowo operatory rzutowania static_cast<>, dynamic_cast<> i reinterpret_cast<>. Zauważ, że w dołożonej co C części C++ strasznie nadużywa się nawiasów kątowych czyli znaków mniejszości i większość (<>). Nie poprawia to wcale czytelności, a wręcz w wyrażeniach logicznych z porównaniami powoduje całkowitą jej utratę.

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

A może na odwrót - po co programować w C, skoro przynajmniej niektóre zagadnienia łatwiej
rozwiązać w C++

Jest jeden dobry powód uczenia się C. Paradoksalnie tym powodem są... wskaźniki. Od wskaźników nie uda się uciec ponieważ adresowanie pośrednie to jest podstawowy paradygmat programowania komputerów. Jest podstawą również koncepcji obiektowej ponieważ tablice metod wirtualnych muszą posługiwać się adresowaniem pośrednim. Nie da się zaimplementować obiektów bez posłużenia się wskazaniami.
C uczy bardzo ostrożnego posługiwania się nimi ponieważ nie zawiera żadnych zabezpieczeń składniowych przed błędnym użyciem wskaźników. C++ nie pozwalając na pewne konstrukcje daje w tym wypadku złudne poczucie bezpieczeństwa, którego ani trochę nie poprawia. Oto prosty przykład:
int zmienna = 10;
int granica = 20;
*(1 + (char*)&zmienna) |= 1;
if(zmienna <= granica) puts("mieści się");
else puts("przekracza");
--*((int*)(sizeof granica + (char*)&granica + 1));

Większość osób zaczynających naukę od C zda sobie sprawę, że wynikiem programu będzie wypisanie napisu "przekracza" przez pierwsze 246 uruchomień tego kodu, a potem wypisywanie "mieści się" przez 2^31 - 246 kolejnych uruchomień (i tak w kółko). Oczywiście przy założeniu, że typ int zajmuje 32 bity.
Dla osób zaczynających od C++ wynik programu może być czarną magią bo nie mają zwykle dobrej okazji aby przekonać się jak potężne możliwości tkwią we wskaźnikach. Jedyne czego dowiadują się, to crashe programu wynikające z lekkomyślnego posługiwania się operatorem new lub mieszania go z malloc.

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

Vector to "obudowana" tablica dynamiczna - możesz bezproblemowo zmieniać jego rozmiar,
sam też "wie" ile zajmuje miejsca w pamięci. Więc to akurat zaleta dla C++ której C nie
posiada.

Implementacja zarówno tablic dynamicznych, hash map oraz wszelkich implementacji najróżniejszych drzew i stert w C jest tak samo proste jak w C++. Oczywiście zamknięcie tego samego kodu w pojedynczym obiekcie C++ jest składniowo dużo bardziej eleganckie, ale funkcjonalnie jest to identyczne. Tak samo jak łatwość/trudność implementacji.

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

Przede wszystkim - poprawiony kompilator. Nie bez powodu zaleca się by nawet programy
pisane w czystym C były kompilowane przez kompilator C++.

Taki był postulat przed wyjściem wersji ANSI C 99. Ale od tamtego czasu kompilator C sprawdza praktycznie to samo co C++ i wprowadza w większości identyczne ograniczenia, więc to zalecenie dzisiaj jest niepotrzebne.

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

Poza tym STL i mapy (o których użytkownicy C chyba mogą tylko pomarzyć).

Język C jest funkcyjny, co oznacza, że łatwość budowania wyrażeń jest bardzo duża. Użytkownicy języka C++ sprawili, że ta cecha języka C++ przestała być dobrze wykorzystywana. STL łącznie z szablonami niestety głównie powiększyła zaciemnienie kodu powodując oszczędzenie kilku procent tekstu programu.

Dnia 30.09.2010 o 17:55, ziptofaf napisał:

Prędzej - od razu Java. Nauka najnowszych standardów jest z całą pewnością rozsądniejsza
niż przestarzałych. Z tego samego powodu dla mnie C++ wydaje się rozsądniejszym wyborem od C.

Java, albo C# jak najbardziej przed C++. Jednak nauka C i tak okazuje się niezbędna z jednego powodu. Otóż każdy programista powinien liznąć choć trochę programowania niskopoziomowego. Oczywiście pierwszym narzucającym się wyborem jest jakiś assembler, ale język C znakomicie go zastępuje wykonując dokładnie to samo bez konieczności skupiania się na różnicach mnemoników różnych procesorów. Tym bardziej, że w C można używać wstawek asemblerowych.
Z tego właśnie powodu zmiany w C idące w kierunku C++ są bezsensowne. Brak pewnych sprawdzeń w C umożliwiał efektywne programowanie sterowników oraz kodu samomodyfikującego się (czyli również nietuzinkowych zabezpieczeń, a także wirusów). Czyli rzeczy, które są możliwe poza starym C tylko w assemblerze. Zmiany od roku 1999 (upodabniające C do nieobiektowego C++) powodują, że takiego kodu nie można napisać bez manipulowania w opcjach kompilatora i linkera.

[afl 0]

Zrozumiałęm jedno - nie ma sensu pytać kogokolwiek na forum o poradę, ponieważ ile osób tyle zdań. Ponadto, nawet nie są to porady tylko parady. Trzeba wybrać własną drogę i - niestety - uczyć się na własnych błędach.

[Jan_Czarny 0]

Dnia 07.10.2010 o 13:28, afl napisał:

Zrozumiałęm jedno - nie ma sensu pytać kogokolwiek na forum o poradę, ponieważ ile osób
tyle zdań. Ponadto, nawet nie są to porady tylko parady. Trzeba wybrać własną drogę i
- niestety - uczyć się na własnych błędach.

Pytanie tylko czy zauważysz własny błąd ?

Ja osobiście bym ci polecał , na początku po próbować wszystkiego po trochu i zabrać się za to co idzie ci łatwiej

[Vel_Grozny 0]

Dnia 07.10.2010 o 13:28, afl napisał:

Zrozumiałęm jedno - nie ma sensu pytać kogokolwiek na forum o poradę, ponieważ ile osób
tyle zdań. Ponadto, nawet nie są to porady tylko parady. Trzeba wybrać własną drogę i
- niestety - uczyć się na własnych błędach.

Ma, ma, tylko widocznie trafiłeś na drażliwy temat :) Zauważ, że dyskusja nie toczy się obecnie na temat Twoich problemów z C, a nad tym jaki język jest odpowiedni dla nowicjusza.
Skoro wybrałeś C (lub jakiś inny język) i masz jakieś problemy, to śmiało zadawaj pytania. Kwestia tego gdzie w prostym kodzie jest błąd jest prostsza, niż zawiłości projektowania języków. Także nie zrażaj się jeszcze do forum.

[tomoliop 0]

#include<iostream>
using namespace std;
int main()
{
char taba[20];
char tabb[20];
char tabt[30];
cout<<"Napisz jakis wyraz (bez polskich znakow): ";
cin>>tabt;
int i=0;
while (tabt!=''\0'')
{
cout<<tabt;
if (tabt==''a''||''e''||''i''||''o''||''u''||''y'')
{tabt=taba;
i++;}
else
{tabt=tabb;
i++;}

}
cout<<"Wszystkie samogloski w wyrazie, ktory podales: "<<endl;
for(int i=0;i<15;i++)
cout<<taba;
cout<<endl;
cout<<"Wszystkie spolgloski w wyrazie, ktory podales: "<<endl;
for(int i=0;i<15;i++)
cout<<tabb;
cout<<endl;
system("pause");
return 0;
}

Program ma zapisać do jednej tablicy samogłoski, do drugiej spółgłoski. Błędów uniemożliwiajacych kompilację nie ma, ale program nie działa poprawnie, bo dostaje jakieś dziwne znaki, zamiast tych z wyrazu, który się napisze. I nie mogę dojść co jest źle.

[o_Orange 0]

#include <iostream>
using namespace std;
int main() {
char wyraz[10];
char samog[10];
char spolg[10];
int j=0;
int x=0;
int y=0;

cout << "podaj wyraz: ";
cin >> wyraz;

while (wyraz[j]!='\0') {

if (wyraz[j]=='a'||wyraz[j]=='e'||wyraz[j]=='i'||wyraz[j]=='o'||wyraz[j]=='u'| |wyraz[j]=='y') {
samog[x] = wyraz[j];
x++;
}
else {
spolg[y] = wyraz[j];
y++;
}
j++;
}
cout << "samogloski: ";
for (j=0; j<x; j++) {
cout << samog[j] << " ";
}
cout << "\nspolgloski: ";
for (j=0; j<y; j++) {
cout << spolg[j] << " ";
}

cin.ignore();
getchar();
return 0;
}

Proszę - ten działa nawet jak długość wyrazu przekroczy rozmiar tablicy chociaż nie wiem do końca dlaczego tak się dzieje. ;)

[ziptofaf 2]

Dnia 08.10.2010 o 22:47, o_Orange napisał:

Proszę - ten działa nawet jak długość wyrazu przekroczy rozmiar tablicy chociaż nie wiem do końca dlaczego tak > się dzieje. ;)

Wbrew pozorom nie działa. Przy napisaniu naprawdę długiego wyrazu całość wyłączy się bez podania żadnego wyniku. Proponowałbym użyć stringów/wektorów (bo przyjmują dowolną ilość znaków) i do sprawdzenia czy to już koniec wyrazu używać .size()

[tomoliop 0]

Dzięki, dostosowałem twój kod do mojego i działa.

[Olamagato 3]

Takie konstrukcje jak:
if (wyraz[j]==''a''||wyraz[j]==''e''||wyraz[j]==''i''||wyraz[j]==''o''||wyraz[j]==''u''| |wyraz[j]==''y'') { instrukcja; }
zapisuje się o wiele lepiej przy pomocy instrukcji switch:
switch(wyraz[j])
{
case ''a'': case ''e'': case ''i'': case ''o'': case ''u'': case ''y'':
instrukcja;
}

[tomoliop 0]

#include<iostream>
using namespace std;
int main()
{
cout<<"Podaj wyraz: ";
char wyraz[30];
cin.getline(wyraz,30);
int z=0;
while (wyraz[z]!=''\0'')
z++;

if (z%2==0)
cout<<"Podany przez ciebie wyraz nie jest palindromem";
else
cout<<"Podany wyraz moze byc palindromem";
int i=0;
if (wyraz==wyraz[z])
cout<<"Podany wyraz moze byc palindromem";
else
cout<<"Podany przez ciebie wyraz nie jest palindromem";
cin.ignore();
getchar();
return 0;
}

Program ma sprawdzać czy podany wyraz jest palindromem (taki, który czytany jest wspak i normalnie tak samo,np. kajak, oko).
cout<<"Podany wyraz moze byc palindromem";
cout<<"Podany przez ciebie wyraz nie jest palindromem";
Te linie służą mi za sprawdzenie do którego momentu działa program i obecnie mam program z tą
if (wyraz==wyraz[z])
instrukcją. Nie wiem co po zmieniać, żeby ta instrukcja przy wpisaniu palindromu się wykonała.
Z góry dzięki za pomoc.
PS Cholerstwo mi ucina, w tej wspomnianej instrukcji ma być wyraz(nawias kwadratowy) i (nawias kwadratowy).

[Treant 0]

Dnia 25.10.2010 o 19:09, tomoliop napisał:

if (z%2==0)
cout<<"Podany przez ciebie wyraz nie jest palindromem";

Przecież istnieją palindromy o parzystej ilości liter, np.: ANNA.

Co do tego sprawdzania czy jest palindrom lepiej odczytać długość wprowadzonego wyrazu i zrobić pętlę do jego połowy (lub momentu, w którym wyraz nie może być już palindromem), która będzie porównywała pierwszy znak z ostatnim, drugi z przedostatnim, itp. Na zasadzie wyraz[ i ] == wyraz[ z-i ].

[tomoliop 0]

Dnia 25.10.2010 o 21:34, Treant napisał:

> if (z%2==0)
> cout<<"Podany przez ciebie wyraz nie jest palindromem";
Przecież istnieją palindromy o parzystej ilości liter, np.: ANNA.

Co do tego sprawdzania czy jest palindrom lepiej odczytać długość wprowadzonego wyrazu
i zrobić pętlę do jego połowy (lub momentu, w którym wyraz nie może być już palindromem),
która będzie porównywała pierwszy znak z ostatnim, drugi z przedostatnim, itp. Na zasadzie
wyraz[ i ] == wyraz[ z-i ].

Racja, dzięki za wytknięcie mi tego. Spróbuję tak zrobić.

[Infes 0]

Witam wszystkich, potrzebuje pomocy z C# a dokładniej nie wiem jak napisać programy. Liczę na szybko odpowiedz bo potrzebuje na jutro :/

Program co musiał dodać do siebie 10 liczb parzystych. Ma to być w pętli czy jakoś tak :p że zmienna daje x=0 Warunek że x&2 i że suma tych 10 liczb parzystych na koniec.

Mam nadzieję że wiecie o co chodzi i za każdy minimalną choćby chęć pomocy dziękuje :)

[tomoliop 0]

#include<iostream>
using namespace std;
int main()
{
cout<<"Podaj wyraz: ";
char wyraz[30];
cin>>wyraz;
int z=0;
while (wyraz[z]!=''\0'')
z++;
int i=0;
if (wyraz==wyraz[z])
{if (z==3)
cout<<"Podany wyraz jest palindromem.";
else if (wyraz[i+1]==wyraz[z-i])
cout<<"Podany wyraz jest palindromem.";
}
else
cout<<"Podany przez ciebie wyraz nie jest palindromem";

cin.ignore();
getchar();
return 0;
}
Kontynuacja problemu podanego powyżej. W tym zamyśle program nie działałby na wszystkie palindromy, ale na większość i to by mi od biedy wystarczyło, ale coś jest źle.

[Khaedr 0]

Ja na palindromy znam inne rozwiązanie opierające się na dwóch stringach. Pierwszy to wyraz który chcemy sprawdzić czy jest palindromem a drugi to pomocniczy. Drugiemu nadajemy wartość pierwszego (żeby miał taką samą ilość znaków) a potem w pętli przepisujemy ten pierwszy od końca do drugiego. Za pętlą porównujemy oba stringi.
Podaje kodzik:
#include <iostream>
using namespace std;

int main()
{
string wyraz, pom;
int dl;
cout << "Podaj wyraz: ";
cin >> wyraz;
pom=wyraz;
dl=wyraz.size();
for (int i=0; i<wyraz.size(); i++)
{
dl--;
pom=wyraz[dl];
}
if (wyraz==pom) cout << "Wyraz jest palindromem\n";
else cout << "Wyraz nie jest palindromem\n";
system("pause");
}

[tomoliop 0]

Dzięki, ale niestety treść zadania mówi o wykorzystaniu tablicy.

Przepraszam za kolejny problem, ale okazało się, że muszę coś poprawić i nie wychodzi...:
#include<iostream>
using namespace std;
int main()
{
cout<<"Ile chcesz podac liczb?(max. 20): ";
int l;
cin>>l;
int tab[20];
cout<<"Podaj "<<l<<" liczby: ";
int p,o;
l++;
for (int i=0;i<l;i++)
cin>>tab;
p=tab[0];
o=tab[l];
tab[0]=tab[o];
tab[l]=tab[p];
cout<<tab[0]<<endl<<tab[l]<<endl;
system("pause");
return 0;
}

Program ma zamienić element pierwszy z ostatnim. Pobiera ilość liczb, ale po wpisaniu przestaje działać. Z góry dzięki za pomoc.

[Khaedr 0]

#include<iostream>
using namespace std;
int main()
{
cout<<"Ile chcesz podac liczb?(max. 20): ";
int l;
cin>>l;
int tab[20];
cout<<"Podaj "<<l<<" liczby: ";
int p,o;
for (int i=0;i<l;i++)
cin >> tab;
p=tab[0];
o=tab[l-1];
tab[0]=o;
tab[l]=p;
cout<<tab[0]<<endl<<tab[l]<<endl;
system("pause");
return 0;
}

Poprawiłem twój program i działa (zamienia pierwszy element z ostatnim)

[ziptofaf 2]

Dnia 27.10.2010 o 19:43, tomoliop napisał:

Dzięki, ale niestety treść zadania mówi o wykorzystaniu tablicy.

String w gruncie rzeczy jest tablicą typu [char], tylko wzbogaconą o dodatkowe funkcje (np. "zna" własny rozmiar i sama się rozrasta/zmniejsza w zależności od potrzeb).

Ale na upartego możesz to rozwiązać bezpośrednio w tablicach, najlepiej 2 dynamicznych (31 miejsc na litery to nie dużo, nawet w polskim języku są dłuższe wyrazy).
int main(int argc, char *argv[])
{
int palicostam=0;
int rozmiar;
cin >> rozmiar;
char * const wyraz=new char [rozmiar];
cin >> wyraz;

char * const sprawdzacz=new char [rozmiar];

for (int a=0, b=rozmiar-1; a<=rozmiar; a++, b--)
{
sprawdzacz[a]=wyraz; // tu mialo byc b w nawiasie kwadratowym, ale to forum nie nadaje sie do wyswietlania kodu.
}

I dalej pozostało ci tylko porównanie pierwszego elementu sprawdzacza z pierwszym wyrazu, drugiego z drugim itd. Za każdym razem gdy będą się zgadzać, to palicostam++;
Jeśli palicostam==rozmiar, to dany wyraz bedzie palindro...czymśtam ;)
no i jeszcze na koniec dodaj linie:
delete [] wyraz;
delete [] sprawdzacz;
Aby usunąć tablice dynamiczne z pamięci komputera.