Zaloguj się, aby obserwować  
Bartuc

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

1979 postów w tym temacie

Witam,
jestem absolutnym laikiem w programowaniu - 0 wiedzy, a muszę nauczyć się języka AFL - wiem, że to język z grupy C lite (nic mi to nie mówi). Ponadto stworzył go - choc nie jestem pewien - polski programista Janeczko i napisał w nim świetny program Amibroker służący do analizy technicznej instrumentów finansowych. Czy ktoś z formumoiczów doradzi mi jak podejśc do tematu? Na stronie Amibrokera jest co prawda guide ale w języku angielskim. O ile radze sobie z angielskim potocznym (film, literatura) to nie znajac kompletnie terminologi informatycznej ciżko mi przebrnąc przez te instrukcje i nie wiem, czy nie powinienem najpierw posiąśc jakieś quantum wiedzy. Szukam najprostszej i najszybszej dorogi do nauczenia sie tego języka i licze na sensowne rady/moze pomoc w nauce programowania - oczywiscie nie za friiko.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Dnia 29.09.2010 o 16:08, afl napisał:

jestem absolutnym laikiem w programowaniu - 0 wiedzy, a muszę nauczyć się języka AFL
- wiem, że to język z grupy C lite (nic mi to nie mówi).


AFL to w sumie dziwadełko i mało kto w tym programuje, więc ciężko znaleźć jakieś materiały. Musiałbyś się popytać na bardziej specjalistycznych forach.
W czasie szukania możesz jednak poznać podstawy C (lub C++). Wszystkie języki w zasadzie mają podstawowe elementy bardzo podobne i w taki sposób chwycisz na czym w ogóle polega programowanie.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

zaczynam nauke jezyka C- pozwolicie ze bede miewal glupie pytania?
oto pierwsze z nich - czy kazdy program zaczynamy od formulki #include <stdio.h> /
i czy zamiast stdio moge wpisac sobie dowolny tekst ktory potem wyswietli sie jako naglowek? czyli np. <moj pierwszy program.h>

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Dnia 29.09.2010 o 18:52, afl napisał:

zaczynam nauke jezyka C- pozwolicie ze bede miewal glupie pytania?
oto pierwsze z nich - czy kazdy program zaczynamy od formulki #include <stdio.h>

Nie.

Dnia 29.09.2010 o 18:52, afl napisał:

i czy zamiast stdio moge wpisac sobie dowolny tekst ktory potem wyswietli sie jako naglowek?
czyli np. <moj pierwszy program.h>

Nie.

Widzę, że jeszcze nie natknąłeś się na wytłumaczenie, czym jest plik nagłówkowy. Nie wiem, czy zależy Ci na dokładnym wytłumaczeniu. Generalnie, plik nagłówkowy zawiera deklaracje funkcji, które możesz potem wywołać w swoim programie. W stdio.h znajdują się deklaracje funkcji obsługujących wyjście i wejście danych. Jeśli nie zainkludujesz stdio, to dostaniesz błąd kompilacji (kompilator nie będzie wiedział co to jest "printf"). Możesz inkludować więcej nagłówków, każdy w osobnej linijce.
Np.
#include <stdio.h>
#include <math.h>

Pozwoli Ci na korzystanie zarówno z funkcji printf (i paru innych), jak też matematycznych - tj. sin(), asin(), itp.

Jeśli zamierzasz poważnie nauczyć się C, to polecam książkę "Język ANSI C" autorstwa Kernighama i Ritchiego.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Dnia 29.09.2010 o 19:14, afl napisał:

a co by bylo gdybym nie uzyl slowa int a w nawiasie napisal void?

Generalnie
int main()
to deklaracja funkcji. Popatrzmy na jej kolejne elementy.
Pierwsze słowo kluczowe - tutaj int oznacza typ zwracanej wartości przez funkcję. W funkcji main() zazwyczaj zwracamy 0 do systemu (bo funkcja main() jest wywoływana przez system, gdy ładuje Twój program). Przyjęto konwencję, że zwrócenie 0 oznacza poprawne wykonanie programu. Cokolwiek innego sygnalizuje błędne wykonanie programu.
Następnie mamy nazwę - main. System zawsze najpierw wywoła funkcję o nazwie main.
W nawiasach natomiast mamy parametry. void oznaczałoby "nic" (pustka z angielskiego), tzn., że funkcja nie przyjmuje argumentów. Nie ma praktycznej różnicy między zostawieniem pustych nawiasów, a napisaniem wprost void.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dzieki,
załadowałem juz 30 dniowa wersje borlanada i napisałem to w nim ale nie mam pojecia co dalej z tym zrobic - jakos skompilowac zeby dzialalo

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Dnia 29.09.2010 o 20:39, afl napisał:

Dzieki,
załadowałem juz 30 dniowa wersje borlanada i napisałem to w nim ale nie mam pojecia co
dalej z tym zrobic - jakos skompilowac zeby dzialalo


Ściągnij sobie wxDev-C++, jest w pełni darmowy. A ma te same możliwości, za to kompilowanie i uruchamianie programów "tekstowych" jest bardzo proste. Wbrew nazwie możesz programować w nim w zwykłym C, a nie C++ (choć szczerze mówiąc, to lepiej w tym drugim zaczynać).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Dnia 29.09.2010 o 20:39, afl napisał:

Dzieki,
załadowałem juz 30 dniowa wersje borlanada i napisałem to w nim ale nie mam pojecia co
dalej z tym zrobic - jakos skompilowac zeby dzialalo

Nie używam Borlanda, zwłaszcza 30-dniowego, gdy Microsoft wypuszcza Visual Studio Express za darmo. Generalnie, gdzieś powinna być opcja Build, albo Compile. A potem poszukaj gdzieś opcji Run, albo Start Program.

Myślę, że wystarczy jak znajdziesz Run - Borland powinien sam skompilować program przed jego uruchomieniem.
I generalnie nie zdziw się, jeśli mignie Ci tylko czarne okienko konsoli. Po wykonaniu program się zamyka, wraz z okienkiem.

Jeśli tak się stanie, to większość kompilatorów dostarcza nagłówek conio.h

Więc dopisz w linijce pod
#include <stdio.h>
#include <conio.h>

I

getch();
przed linijką
return 0;

Wtedy program zakończy się dopiero po wciśnięciu klawisza. Ale możliwe, że nie natkniesz się na ten problem. Uprzedzam, bo wielu początkujących się o to pyta.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Dnia 29.09.2010 o 20:52, ziptofaf napisał:

Ściągnij sobie wxDev-C++, jest w pełni darmowy. A ma te same możliwości, za to kompilowanie
i uruchamianie programów "tekstowych" jest bardzo proste. Wbrew nazwie możesz programować
w nim w zwykłym C, a nie C++ (choć szczerze mówiąc, to lepiej w tym drugim zaczynać).

Bo ja wiem? Ja zaczynałem od C++, ale w sumie uważam, że lepiej byłoby zacząć od czystego C. Bo pierwszy program w C++ ma pełno "magicznego" stuffu, którego nowicjusz nie ma szans zrozumieć.

#include <iostream>
using namespace std; // ??????

int main()
{
cout << "Hello, world!" << endl; // ??????
return 0;
}

Czy ja wiem, czy zaczynanie nauki języka programowania od przestrzeni nazw i przeciążania operatorów jest sensowne? Gdy ktoś zna C, zna wskaźniki, preprocesor, itp. - w C++ może się od razu uczyć o klasach. A tak, to klepie się cout i namespace jak mantrę, nie wiedząc CO się robi. Programista musi rozumieć co robi, dlatego moim zdaniem lepiej zaczynać od prostych konceptów.

Gdybym miał komuś polecić zaczynanie nauki od języka obiektowego, byłby to raczej C# lub Java. C++ to taki miks z językiem proceduralnym i warto poznać najpierw podstawy.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Dnia 29.09.2010 o 21:02, Vel_Grozny napisał:

Bo ja wiem? Ja zaczynałem od C++, ale w sumie uważam, że lepiej byłoby zacząć od czystego
C. Bo pierwszy program w C++ ma pełno "magicznego" stuffu, którego nowicjusz nie ma szans
zrozumieć.


Na odwrót. To C ma dziwne rzeczy które ciężko ogarnąć. Takie tablice - ograniczone rozmiarami, żeby to zmieniać trzeba się bawić w zmienne wskazujące itd. A C++? Po prostu robisz wektor i nie martwisz się bzdurami.
Zresztą...nie trzeba koniecznie programować obiektowo w C++, przypomnę że jest on w miarę zgodny z C (w swoim czasie był zgodny w 100%, ale najnowsze wersje C++ i C niekoniecznie się pokrywają).

Dnia 29.09.2010 o 21:02, Vel_Grozny napisał:

#include <iostream>
using namespace std; // ??????

int main()
{
cout << "Hello, world!" << endl; // ??????
return 0;
}

Czy ja wiem, czy zaczynanie nauki języka programowania od przestrzeni nazw i przeciążania
operatorów jest sensowne?

Możesz po prostu pisać std::cout i się nie przejmować tym magicznym using namespace, to raz. Poza tym to że tego nie rozumiesz na danym etapie, nie oznacza niczego złego. A w Javie? Zaczynasz od class public, czyli pełna obiektowość od początku ;)

Dnia 29.09.2010 o 21:02, Vel_Grozny napisał:

Gdy ktoś zna C, zna wskaźniki, preprocesor, itp. - w C++ może
się od razu uczyć o klasach. A tak, to klepie się cout i namespace jak mantrę, nie wiedząc
CO się robi. Programista musi rozumieć co robi, dlatego moim zdaniem lepiej zaczynać
od prostych konceptów.


No właśnie takie wskaźniki - taka bzdura, że lepiej nie mówić. Zmienne adresowe, tablice dynamiczne itd...Nie łatwiej korzystać np. z wektorów zamiast tablic dynamicznych? O wiele łatwiej.

Dnia 29.09.2010 o 21:02, Vel_Grozny napisał:

Gdybym miał komuś polecić zaczynanie nauki od języka obiektowego, byłby to raczej C#
lub Java. C++ to taki miks z językiem proceduralnym i warto poznać najpierw podstawy.

Java i owszem. Ale C++ jest zasadniczo prostszy od C. Bo przecież nikt cię nie zmusza, żebyś od razu obiektowo programował...

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dzieki za info, Odinstalowuje Borlanda - to gigantyczna maszyna, musialbym sie tego uczyc tyle samo co samego C - znajde cos prostszego

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Dnia 29.09.2010 o 21:57, ziptofaf napisał:

Na odwrót. To C ma dziwne rzeczy które ciężko ogarnąć.

A ja zgodzę się z Vel_Groznym. C++, to do nauki totalny koszmar.
To co można powiedzieć o C++, to jego totalna nieczytelność i brak spójności języka.
Idąc od początku:
1. Klasy oraz obiekty są jednym zamkniętym tworem - jest to oczywiste. To jak wytłumaczyć konieczność podzielenia klas osobno na nagłówki oraz ciało metod? Po co #include i skoro nagłowek nie zawiera pełnego opisu klasy, to skąd program ma wiedzieć jaka jest pełna jej definicji? I co do tego ma linkowanie plików obj, d, lib oraz innych biorących udział w zbudowaniu aplikacji. Nie da się tego wytłumaczyć nie cofając się do czasów sprzed 30 lat oraz do czysto funkcyjnego C i jego mechanizmu łączenia modułów w gotowy program.
2. Po co w ogóle preprocesor w języku obiektowym? To tylko zaciemnienie kodu obiektowego i wiąże się ściśle z utrzymaniem niezdefiniowanych długości wbudowanych typów danych.
3. Przestrzeń nazw - znowu ten sam problem z przestarzałą infrastrukturą języka C i jego oprotezowaniem w C++. Musimy znowu cofnąć się do czasów gdy kompilatory rozpoznawały tylko 8-32 znaków w identyfikatorach oraz protezie w postaci osobnych kontenerów zawierających tylko identyfikatory.
4. Wywołanie programu z systemu - dlaczego miejscem startu musi być nieobiektowa funkcja main? Dlaczego nie metoda main z jakiegoś obiektu statycznego lub statyczna metoda klasy? Znowu więc cofamy się o 30 lat w tłumaczeniu dlaczego...
5. Strumienie cout i cin. Skąd się wzięły, co tak naprawdę reprezentują, dlaczego do przesłania używa się operatora << i >>? Dlaczego nie print/in/out lub jakiejś innej metody tych obiektów? A jak tak, to dlaczego trzeba pisać jakieś kolejne rzeczy typu extern "C" {}?. I kolejna cofka.
6. Dlaczego nie można dziedziczyć po cout, żeby wypisać nowe rodzaje informacje?
7. Po co w ogóle zintegrowano w obiektach strumieniowych formatowanie?

Takich pytań, które nie mają żadnego związku z nauką języka obiektowego (koncepcji obiektowej), natomiast mają mnóstwo wspólnego z przestarzałymi koncepcjami i porobionych do nich protezami w C++ jest mnóstwo. One nie pomagają w nauce, a wręcz przeciwnie - mocno przeszkadzają.

C był dobrze zaprojektowanym językiem niskiego poziomu, w którym mając odrobinę systematyczności można było pisać również dobre programy wysokiego poziomu. Jego jedyną dyskusyjną wadą był brak obsługi tablicy wielowymiarowej i użycie w tym celu słabej koncepcji tablicy tablic. Jednak sposób tworzenia programów był spójny i nowoczesny jak na czasy w których powstał.

C++ ewoluował w kierunku dorobienia koncepcji obiektów do C bez zmiany jakiejkolwiek dotychczasowej koncepcji języka C. To się nie mogło dobrze udać. Po pierwsze ze względu na wtedy już zbyt prymitywne środowisko tworzenia programów w języku C, po drugie przez zachowanie maksymalnej zgodności z językiem C. Obiekty, mimo, że były nową jakością w C++ okazały się dziwacznymi tworami w pamięci. Nie można było ich nawet spójnie używać bo ich cechy różniły się znacząco zależnie od tego czy zostały zaalokowane przez new, malloc, na stosie jako zmienne lokalne czy wręcz przez egzotyczne mechanizmy alokacji pamięci EMS czy w pamięci obrazu karty graficznej (da się). Jeszcze gorzej działało rzutowanie do klasy bazowej powodu fatalnej koncepcji fizycznego obcinania obiektu do wersji bazowej, a następnie kolejnego rzutowania do pierwotnej klasy, która dawała w efekcie niemożliwą do uniknięcia awarię aplikacji (mimo całkowitej poprawności semantycznej i składniowej).
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.
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.
Wejście-wyjście. W C koncepcja strumieni stdin, stdout i stderr była średnio wygodna, ale to co Stroustrup zrobił w C++ woła o pomstę do nieba. Nie dość, że obsługa wejścia-wyjścia jest tylko pseudoobiektowa (po strumieniach nie można dziedziczyć), to jest jeszcze bardziej skomplikowana i niespójna od wersji z C. Na dodatek pozwolenie na przeplatanie wywołań w stylu C z niby obiektowym stylem C++ spowodowało, że czytelność nagłówków XXstream dla początkującego spadła do zera. Są one po prostu totalnie nieczytelne, niezrozumiałe i brak w nich elementarnego sensu co do ich istnienia.
Kiedyś zrobiłem program intensywnie korzystający z obiektowego i/o z C++. Tego nie dało się czytać i po kilku tygodniach gdyby nie komentarze, to sam nie rozumiałbym w ząb własnego kodu. Napisałem później taką samą obsługę wyłącznie w wersji nieobiektowej. Po tygodniu myślenia wywaliłem wersję obiektową przez skasowanie kodu (czego normalnie nigdy nie robię). Wersja nieobiektowa miała wiele zalet i żadnych wad, wersja C++ same wady i żadnych zalet.

Dnia 29.09.2010 o 21:57, ziptofaf napisał:

Takie tablice - ograniczone rozmiarami, żeby to zmieniać trzeba się bawić w zmienne wskazujące itd. A C++? Po prostu robisz wektor i nie martwisz się bzdurami.

Problem w tym, że vector, a właściwie jego implementacja jest ściśle oparta na tych tablicach i wskaźnikach. To nie jest zamknięte pudełko jakim może się wydawać. Vector podobnie jak i cała obiektowość ewoluował w miarę jak w kolejnych wersjach języka C++ okazywało się, że część obiektowa jest *fatalnie zaprojektowana*. Stąd wzięło się mnóstwo problemów z kolejnością inicjacji pól obiektu, wielodziedziczeniem i zasadami inicjacji przodków i podobiektów, problemem z priorytetami zdefiniowanych operatorów itp.

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#.
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.

I tak dla wyjaśnienia - jakieś 15 lat temu byłem całkowicie oddany C oraz miałem ogromne nadzieje w związku z koncepcją C++. Zmieniło to się gdy poznałem javę oraz C#. Te języki są dzisiaj moim zdaniem wzorcem do uczenia się programowania od zera. Oraz C jako niezbędny niskopoziomowy pomost między sprzętem, a wysokopoziomowym programowaniem obiektowym. C++ jest kompletnie zbędny.

Dnia 29.09.2010 o 21:57, ziptofaf napisał:

Zresztą...nie trzeba koniecznie programować obiektowo w C++

To po co w ogóle programować w C++? Język C oferuje w części nieobiektowej dokładnie to samo?
Niestety jego ewolucja idzie ostatnio w kierunku złych zmian z języka C++ (np. brak zwijania wyrażeń statycznych).

Dnia 29.09.2010 o 21:57, ziptofaf napisał:

Możesz po prostu pisać std::cout i się nie przejmować tym magicznym using namespace, to raz.

Trzeba i tak wytłumaczyć po co jest to "std::" i dlaczego w ogóle jest to problem.

Dnia 29.09.2010 o 21:57, ziptofaf napisał:

A w Javie? Zaczynasz od class public, czyli pełna obiektowość od początku ;)

Co w tym dziwnego? Każda najmniejsza aplikacja jest dzięki temu klasą, a pierwszą rzeczą jaką się robi w statycznej main() jest utworzenie obiektu tejże klasy. Spójne, proste i sensowne.

Dnia 29.09.2010 o 21:57, ziptofaf napisał:

No właśnie takie wskaźniki - taka bzdura, że lepiej nie mówić.

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.
W tym języku powinny zniknąć lub zostać ograniczone do możliwości referencji. Paradoksalnie Stroustrup wykombinował referencję, jednak ze względu na ich właściwości są one maksymalnie nieużyteczne. Szczególnie widać to w połączeniu z fatalnym projektem klasy String w C++. Jednocześnie niespójnie z resztą języka cudzysłowy dla odmiany od zasady zachowania zgodności z C stały się referencjami do obiektów klasy String, co u początkującego powoduje totalną frustrację. Na przykład żeby przenieść stały napis do starej funkcji w C przyjmującej (char*) trzeba dodatkowo utworzyć zmienną const String &xxx = "jakiś stały napis"; oraz wywołać na jej rzecz metodę statyczną c_str(). Inaczej powstanie problem albo na etapie kompilacji, albo na etapie linkowania. Bezpośrednio nie da się użyć takiego napisu w cudzysłowiu jako argument (char *), ani wywołać na jego rzecz metody c_str() (np. wywołanie funkcja_C ("jakiś stały napis".c_str()).

Dnia 29.09.2010 o 21:57, ziptofaf napisał:

Zmienne adresowe, tablice dynamiczne itd...Nie łatwiej korzystać np. z wektorów zamiast tablic dynamicznych?

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.

Dnia 29.09.2010 o 21:57, ziptofaf napisał:

Java i owszem. Ale C++ jest zasadniczo prostszy od C. Bo przecież nikt cię nie zmusza,
żebyś od razu obiektowo programował...

Hmm, ale jakim cudem nadzbiór języka funkcyjnego i obiektowego miałby być prostszy od jego funkcyjnego podzbioru?
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. :)

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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Dnia 30.09.2010 o 15:29, Olamagato napisał:

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


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

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Utwórz konto lub zaloguj się, aby skomentować

Musisz być użytkownikiem, aby dodać komentarz

Utwórz konto

Zarejestruj nowe konto na forum. To jest łatwe!


Zarejestruj nowe konto

Zaloguj się

Masz już konto? Zaloguj się.


Zaloguj się
Zaloguj się, aby obserwować