Czyste C czy C++?

Hej, mam takie pytanko:

1. Czy lepiej uczyć się samego C bez plusów?

2. . czy mogę korzystać z tutoriali dla C i kompilatora C++
   (i ewentualnie wtrynić gdzieś kod C++ jak mi będzie potrzebny)

3. Czy czyste C jest w 100% zgodne z C++ (tzn. czy kod C będzie zawsze działał w kompilatorze C++, bo wiem że odwrotnie to raczej nie)

Ponieważ na przykład:
To jest Hello World w C++

#include <iostream>

int main() {
    std::cout << "Hello World!";
    return 0;
}

std, cin... cout... te komendy brzmią trochę jakby ktoś wymiotował.

A to kod w C (kompiluje mi się bez problemu w DevCPP)
No jakoś tak printf() brzmi trochę wiarygodniej do wyświetlania tekstu niż cout. Choć mogłoby być lepiej. Wystarczyło by po prostu print(). Po co pchać to "f" na koniec?

#include <stdio.h>
int main() {
   // printf() displays the string inside quotation
   printf("Hello, World!");
   return 0;
}

SiedemBoleści napisał(a):

Hej, mam takie pytanko:
Czy lepiej uczyć się samego C bez plusów.

Odpowiedź na to pytanie brzmi zależy do czego chcesz tego używać.

SiedemBoleści napisał(a):

czy mogę korzystać z tutoriali dla C i kompilatora C++
(i ewentualnie wtrynić gdzieś kod C++ jak mi będzie potrzebny)

Dlaczego chcesz ucząc się języka X korzystać z tutków do języka Y?

SiedemBoleści napisał(a):

Czy czyste C jest w 100% zgodne z C++ (tzn. czy kod C będzie zawsze działał w kompilatorze C++, bo wiem że odwrotnie to raczej nie)

Nie, są konstukcje w języku C, które nie są poprawnym kodem w C++

SiedemBoleści napisał(a):

std, cin... cout... te komendy brzmią trochę jakby ktoś wymiotował.
...
No jakoś tak printf brzmi trochę wiarygodniej do wyświetlania tekstu niż cout. Choć mogłoby być lepiej. Wystarczyło by po prostu print. Po co pchać to f na koniec?

To nie są żadne komendy ;) Komendy masz w CMD/Bash itp :] To są elementy języka. A czepianie się nazewnictwa typu cin/cout/printf świadczy o braku znajomości ich pochodzenia.
cin -> character input
cout -> character output
printf -> print format

Jak przeszkadzają Ci skrótowe nazwy funkcji obiektów zainteresuj się Java/C# ;)
Po prostu języki te powstawały w czasach kiedy oszczędzało się na wszystkim. Począwszy od szybszego pisania, poprzez szybsze czytanie, skonczywszy na tym, że kiedyś nie było monitorów 8k i na ekranie mieściło się relatywnie niewiele znaków. Co więcej wczesne implementacje C miały ograniczenie polegające na tym, że tylko pierwszych 8 znaków identyfikatora miało znaczenie. Więc skracało się wszystko co się dało. A przez wszechobecną kompatybilność wsteczną w IT trzeba się z tym męczyć po dzień dzisiejszy.

Mr.YaHooo napisał(a):

Odpowiedź na to pytanie brzmi zależy do czego chcesz tego używać.
Dlaczego chcesz ucząc się języka X korzystać z tutków do języka Y?

Wystarczyło by samo C, ale w dalszej perspektywie zależy mi na bibliotece FLTK która jest tylko dla C++, a jak podaje ciocia Wiki:

C++ – język programowania ogólnego przeznaczenia. Język został zaprojektowany przez Bjarne Stroustrupa jako rozszerzenie języka C o obiektowe mechanizmy abstrakcji danych i silną statyczną kontrolę typów. Zachowanie zgodności z językiem C na poziomie kodu źródłowego pozostaje jednym z podstawowych celów projektowych kolejnych standardów języka.

Mr.YaHooo napisał(a):

cin -> character input
cout -> character output
printf -> print format

Po prostu trochę mało logiczne. Gdybym to ja nazwyał te elementy nazwałbym po prostu input (lub krócej inp ), output (lub out) ... czy print

Czy czyste C jest w 100% zgodne z C++ (tzn. czy kod C będzie zawsze działał w kompilatorze C++, bo wiem że odwrotnie to raczej nie)

Na pewno nie w 100%, choć w większości przypadków kod C będzie poprawny jako C++, w pozostałych będzie wymagać pewnych modyfikacji, np:.

1. W C++ jest więcej słów kluczowych może się zdarzyć, że jakaś zmienna, stała jest nazwana słowem, które w C nie jest kluczowe, a w C++ jest kluczowe.
2. Trochę inne nagłówki z biblioteki standardowej, w C jest #include <string.h>, a w C++ jest #include <cstring>.
3. Inne znaczenie słowa kluczowego auto.
4. Inkrementacja typu enum, o czym ja sam niedawno się dowiedziałem: https://4programmers.net/Forum/C_i_C++/371249-incrementacja_enum_w_zrodle_programu_vttest?p=1943218#id1943218

Po prostu trochę mało logiczne. Gdybym to ja nazwyał te elementy nazwałbym po prostu input (lub krócej inp ), output (lub out) ... czy print

Jak się uprzesz, to możesz sobie zmienić nazwę standardowych funkcji poprzez definiowanie np.

#define inp cin
#define out cout
#define print(str) printf(str)

Można też zrobić własne funkcje, o ile wymyślona przez Ciebie nazwa nie będzie z niczym kolidować. Czy to warto, to musisz zdecydować sam. Moim zdaniem lepiej przyzwyczaić się do istniejących nazw niezależnie od tego, dlaczego akurat takie zostały wymyślone.

Co do printf, zaleca się, żeby pierwszy parametr był zawsze literałem, a jakiekolwiek zmienne do wypisania były w kolejnych parametrach.

Podstawowe pytanie brzmi, po co Ci to? Oba języki są przestarzałe (jest Rust, znacznie lepszy) i mają dość niszowe zastosowanie, zwłaszcza C. Jeśli chcesz trochę liznąć tylko programowania systemowego to C powinien wystarczyć. Jeśli chcesz napisać coś bardziej złożonego to z C już może być ciężko, bo to prymitywny język (choć dzięki temu prosty i przewidywalny). Z drugiej strony C++ to straszny brzydal pełen dziwnych rozwiązań.

Zgodność między innymi raczej nic ci nie da. Nawet jeśli C ci się skompiluje w C++ to będzie to zły kod w C++. To inne języki i inaczej się w nich programuje. Ta zgodność to tylko ze względu na ułatwienie łączenia ich ze sobą (Rust nota bene, też dobrze się łączy z C/C++).

Proponuję pozbyć się myślenia „czyste C”.
C i C++ to osobne języki (mające wiele wspólnego, to prawda). Nie ma „czystego C”, jest C i jest C++.

@SiedemBoleści:

Broniacy C przeciwko C++ to postawa początkujących. jeszcze nie dotknąłeś Undefined Behavior czyli po ludzku ukrytych błędów itd. Przejechanych buforów, złych typów w sscanf, błędu +1, niezamkniętych zasobów, null pointerów

andrzejlisek napisał(a):

Jak się uprzesz, to możesz sobie zmienić nazwę standardowych funkcji poprzez definiowanie np.

#define inp cin
#define out cout
#define print(str) printf(str)

Można też zrobić własne funkcje, o ile wymyślona przez Ciebie nazwa nie będzie z niczym kolidować. Czy to warto, to musisz zdecydować sam. Moim zdaniem lepiej przyzwyczaić się do istniejących nazw niezależnie od tego, dlaczego akurat takie zostały wymyślone.

Dość przerażająca perspektywa. Realnie takie makra widziałem spod palców pascalowców, basicowców, excelowców "nie chcĘ ale bendem programistom C/C++"

elwis napisał(a):

Podstawowe pytanie brzmi, po co Ci to? Oba języki są przestarzałe

Dokładnie. Zgadzam się z całym postem.

Chyba chodzi o "najlepsze" bo jedyne znane środowisko FLTK

SiedemBoleści napisał(a):

std, cin... cout... te komendy brzmią trochę jakby ktoś wymiotował.

W C/C++ wszystko ma zapach wymiotów, ewentualnie sraczki

A serio: typowa łatwość oceny kogoś, kto nie znalazł czasu / tzw "predyspozycji" by się naprawdę zaangażować i nauczyć, zamiast tego rozpisuje sie na forach "co by programować", tudzież znajduje błędy w kompilatorach
W geometrii nie ma drogi specjalnej dla królów

SiedemBoleści napisał(a):

4. Czy czyste C jest w 100% zgodne z C++ (tzn. czy kod C będzie zawsze działał w kompilatorze C++, bo wiem że odwrotnie to raczej nie)

NIE. Przykład ostatni widoczny na forum: https://4programmers.net/Forum/C_i_C++/371249-incrementacja_enum_w_zrodle_programu_vttest?p=1943218#id1943218
Większość kodu C skompiluje się jako C++, poza drobnymi wyjątkami jak w przykładzie powyżej. W praktyce rzadko się zdarza.

Na dodatek wiele kompilatorów C++ jest wyrozumiała i traktuje kod C, który jest niezgodny ze standardem C++ jako rozszerzenie.
Przykładem jest Variadic Length Arrays (VLA).
gcc i clang ma przełącznik -pedantic, który wyłączy rozszerzenia. Dla MSVC do tego jest /permissive-.

To czy w języku printowanie jest przez strumienie std-io czy printf(), to na prawdę nie ma takiego znaczenia.

Główną różnicą którą widzę, jest to że w C++ można łatwo i bezpiecznie używać polimorfizmu, i dzięki temu osiągnąć Dependency Inversion i Open/Close. W C z tego co wiem, czegoś takiego się nie da.

@SiedemBoleści C jest bardzo dobrym językiem na początek, ponieważ właściwie wszystkie powstałe po nim nowoczesne języki programowania wysokiego poziomu są na nim oparte i dążą różnymi drogami do rozwiązania pewnych problemów języka C. Zresztą to działa również wstecz - C jest podsumowaniem poprzedniej epoki HLL-i zbierając najlepsze elementy różnych jej przedstawicieli. Zatem praktyczny wniosek jest taki, że jeżeli zaczniesz od nauczenia się C (i zdobycia doświadczenia poprzez pisanie własnych programów ćwiczeniowych) to później przechodząc do nowszych języków, a więc m. in. C++ i Javy, ich nauka przyjdzie ci znacznie łatwiej i co najważniejsze naprawdę zrozumiesz jakie przemyślenia stoją za ich konstrukcją. Sam tego doświadczyłem z Javą, która najpierw wydawała mi się bardzo zagmatwana i dziwna, ale gdy po paru latach teoretycznej i praktycznej nauki C wracam czasami do Javy, nie jest już ona dla mnie tym czym była na początku - teraz wszystko (w Javie) zaczyna mieć sens i być wielce naturalnym rozszerzeniem C.

Czy lepiej uczyć się C czy C++ to zależy od tak wielu rzeczy, które nie są tu wymienione, że ciężko Ci na to pytanie odpowiedzieć. Ale jeżli planujesz uczyć się obu jednocześnie planując pisać sobie raz w jednym raz w drugim w tym samym projekcie to od Ci mogę z całą pewnością napisać, że to nie jest dobry pomysł. Poniżej odpowiedzi na bardziej konkretne pytania.

czy mogę korzystać z tutoriali dla C i kompilatora C++

Kompilatory dla C++ zwyczajowo mają wsparcie dla różnych wersji C, tylko przekaż odpowiednią flagę, którego używasz bo obecnie C i C++ to dwa różne języki.

(i ewentualnie wtrynić gdzieś kod C++ jak mi będzie potrzebny)

Nie. Chyba, że będziesz pisał w C++ w stylu C-like, ale wtedy nie będziesz miał dostępu do niektórych technik dostępnych tylko w C.

Czy czyste C jest w 100% zgodne z C++

Czyste C czyli co konkretnie? ANSI C jest chyba w 100% kompatybilne na poziomie źródłowym z C++ jeśli nie używasz rozszerzeń kompilatora tylko dla C, ale począwszy od bardzo popularnego C99 ta kompatybilność się kończy.

Hejka

"Czy czyste C jest w 100% zgodne z C++ ("
Nie jest. Są rzeczy które w C są dozwolone a w C++ to UB.

Z tego co zrozumiałem potrzebujesz C++ więc ucz się C++. Tu nie ma wielkiej filozofii.

Pozdrawiam.

Dyskusja C vs. C++ nie ma większego sensu, dopóki OP nie określi się, jakie programy i na jakie systemy chce tworzyć. Język i kompilator to tylko narzędzia. Moje zdanie jest takie, że najpierw trzeba zdecydować, co się chce zaprogramować, dowiedzieć się, w czym można to coś zaprogramować, a na końcu wybrać język i kompilator.

Ja programuje w C od 11 lat i żałuje że się urodziłem. Naucz się Javy albo Pythona ale na wszelki wypadek zrób kurs na wózek widłowy.

Pal licho tą składnię,ale nie mówcie mi że C/C++ to takie blee skoro większość programów jest w tym napisanych i działają.

A Java czy Python? Chyba programista to powinien także spojrzeć z punktu widzienia użytkownika.
Pythona znam, ale jako użytkownikowi mi się bardzo nie podoba jak ściągam program i wymaga dogrywania jakiejś Javy czy czegoś.

No, a tak poza tym: dlaczego w szkołach (oprócz Pythona, którego ja mam) uczy się przeważnie C++, a nie właśnie C?
Czy nie lepiej byłoby uczyć właśnie C.
Bo właśnie wszystko sprowadza się do tego "Hello World"
Ta wersja w C++ to działa na uczniów chyba bardziej odstraszająco, a nauczyciele nie tłumaczą wcale co to cout/cin oznacza (o ile nikt nie spyta)

andrzejlisek napisał(a):

Dyskusja C vs. C++ nie ma większego sensu, dopóki OP nie określi się, jakie programy i na jakie systemy chce tworzyć.

Interesują mnie zwykłe programy użytkowe działające portable (ewentualnie jakieś proste gry 3D, bez użycia silników, ale to na razie zbyt skomplikowane)
Oczywiście na systemy Windows (od XP, bo w rodzinie pełno starych gratów więc jest gdzie testować, poprzez 7 do 10), ewentualnie Linux ale niestety tego systemu zbytnio nie znam.

Ja obecnie preferuję czyste C, ale na początek chyba bym proponował jednak C++, ze względu na istnienie standardowych kontenerów jak listy, struktury drzewiaste (std::set, std::map itp.), czy automatyczne alokowane string-i. Zakładam że na początku najważniejsze jest szybkie uzyskiwanie działanie programu, nawet jeżeli jest zrobiony bałaganiarsko i trudno w utrzymaniu. Programy w C jest trochę trudniej zacząć, bo wymuszają rozwiązywanie problemów w sposób możliwie jak najprostszy a na najprostsze rozwiązanie często wcale nie jest tak łatwo wpaść - ale ze względu na ten wymuszony dłuższy czas na początku na dobranie rozwiązań prostszych, są łatwiejsze w utrzymaniu.

Jestem wielkim zwolennikiem czystego C i używam gdy tylko mogę, a mogę bardzo często, jednak myślę że lepiej nabrać wprawę w programowaniu ogólnie, a dopiero później nakładać na siebie dodatkowe ograniczenia, jakie nakłada robienie w czystym C. Nie zawsze mogę używać czystego C, choćby z powodu wspomnianego już w wątku FLTK, którego sam też preferuję ponad inne biblioteki GUI, ale i FLTK nie jest dużym problemem, bo przecież w implementacji programu można mieć wiele plików czystego C, tylko linkowanych z plikami C++ zawierającymi bezpośrednie odwołania do FLTK.

Co do tej "przestarzałości" języków i tego, że inne języki uniemożliwiają popełnienie jakichś tam kategorii błędów możliwych do popełnienia w C: wg mojego doświadczenia, główne błędy jakie mam w programach, to brak jakiegoś porównania, czy porównanie z nie tą wartością co trzeba - błędy nijak mające się do użytego języka programowania i nie dające się wykryć automatycznie, bo żaden automat nie ma skąd się domyśleć że to błąd a nie celowe działanie. Błędy typowe dla C są zwykle dużo prostsze do znalezienia, wiele z nich nawet bez własnej inwencji, a jedynie poprzez uruchomienie odpowiedniego narzędzia.

Problemem C jest to, że nie jest modny, więc gdybym nie mógł osobiście decydować o tym, w jakim języku pracę wykonam, jest duża szansa że byłby mi narzucony jakiś inny język a moje doświadczenie programisty uznane za mniej warte niż kogoś, kto programuje w czymś bardziej modnym. Gdybym nie był w dużym stopniu pasjonatem, to C bym porzucił.

IMO za bardzo przejmujesz się nieistotnymi szczegółami.
Nie ważne na jaki język programowania się zdecydujesz, ważne żebyś zaczął.
Po nauczeniu się podstaw pierwszego języka programowania, nauczenie się podstaw kolejnego wymaga znacznie mniej czasu.
Według jednych C i C++ są trudne z powodu wskaźników, według innych pomagają one lepiej zrozumieć jak działa sprzęt.
Według innych python jest bardziej przyjazny dla początkujących.

IMO ten wybór ma znaczenie, jeśli masz zamiar nauczyć się tylko jednego języka, wtedy to zdeterminuje przy czym będziesz pracował w przyszłości.

Podstawy Pythona to już raczej znam, więc chyba zacznę trochę od tego C++ (ewentualnie będę sprawdzał czy przykłady z kursu dla C się uruchomią czy nie)

SiedemBoleści napisał(a):

Wystarczyło by samo C, ale w dalszej perspektywie zależy mi na bibliotece FLTK która jest tylko dla C++,

A ja zapytam przewrotnie dlaczego chcesz tą bibliotekę?

SiedemBoleści napisał(a):

Po prostu trochę mało logiczne. Gdybym to ja nazwyał te elementy nazwałbym po prostu input (lub krócej inp ), output (lub out) ... czy print

Samo input jest mało precyzyjne. Skąd mam wiedzieć, jakie to wyjście? Znakowe, graficzne czy jeszcze jakieś inne? Samo print też sugeruje funkcję w stylu int/void print (char* buffer) Nie ma tu nic o tym, że printuje formatowany tekst.

Azarien napisał(a):

Proponuję pozbyć się myślenia „czyste C”.
C i C++ to osobne języki (mające wiele wspólnego, to prawda). Nie ma „czystego C”, jest C i jest C++.

Dokładnie, ja bym powiedział jeszcze bardziej dosadnie. Trzeba walczyć z myśleniem "C" oraz "C z klasami" za jaki to część ludzi uważa C++. Jest to osobny język coraz bardziej oddalający się z każdym nowym standardem od swojego pierwowzoru.

SiedemBoleści napisał(a):

Pal licho tą składnię,ale nie mówcie mi że C/C++ to takie blee skoro większość programów jest w tym napisanych i działają.

Ale co z tego, że działają? Skoro sam czas potrzebny na wytworzenie takiego samego oprogramowania (robiącego realną rzecz większą niż Hello World) jest zazwyczaj dłuższy niż w językach typu Java/C#. Co więcej w językach C/C++ mamy do czynienia np. z problemami typu UB które mogą dać o sobie znać dopiero za jakiś czas i spowodować wywalenie się w najmniej oczekiwanym momencie. Po prostu są to mniej bezpieczne języki potencjalnie wprowadzające kolejne, czasami trudne do znalezienia, błędy.

SiedemBoleści napisał(a):

No, a tak poza tym: dlaczego w szkołach (oprócz Pythona, którego ja mam) uczy się przeważnie C++, a nie właśnie C?
Czy nie lepiej byłoby uczyć właśnie C.
Bo właśnie wszystko sprowadza się do tego "Hello World"
Ta wersja w C++ to działa na uczniów chyba bardziej odstraszająco, a nauczyciele nie tłumaczą wcale co to cout/cin oznacza (o ile nikt nie spyta)

Zaczynając od tych języków można się zrazić do programowania w ogóle, bo walczysz z zakamarkami języka, a nie clue problemu czyli np. algorytmem. Moim zdaniem samo programowanie warto zacząć od bezpieczniejszych języków takich w których przyjemniej się koduje i potrafią chronić przed standardowymi błędami. Chociaż jak @MarekR22 wspomniał pomaga zbliżyć się do sprzętu i zrozumieć jak on działa, możesz pobawić się pamięcią. Jednak jest to broń obosieczna, łatwo wtedy o błąd i wywalenie całego programu.

Jak chcesz się nauczyć C, to się naucz C — nie ma potrzeby szukać wymówki do nauki…

Jeśli chodzi jednak o przenośność oprogramowania, to języki kompilowane, więc w szczególności i C, są ze swej natury mało przenośne. Już nawet nie chodzi tylko o konieczność przekompilowania całości, co o różnice architektoniczne zmieniające sposób działania programu — w przypadku C chociażby takie rzeczy, jak inna długość inta, inny zakres randa; a na wyższym poziomie, chociażby inna obsługa wielowątkowości.

Mr.YaHooo napisał(a):

A ja zapytam przewrotnie dlaczego chcesz tą bibliotekę? [FLTK]
Bo:

• można zrobić w niej GUI
• będzie zdaje się jeden kod dla Windowsa i Linux (czy się mylę?) Linuxa niestety nie znam za bardzo, ale gdybym chciał mieć jakąś firmę musiałbym poznać żeby móc ciąć koszty o licencję Windowsa
• wkurza mnie gdy ściągam pierwszy lepszy program i wszędzie pliki typu Qt5..cośtam..dll więc na pewno nie będę tego Qt używał

SiedemBoleści napisał(a):

• można zrobić w niej GUI

Jak kupę innych bibliotek które są bardziej rozpowszechnione.

SiedemBoleści napisał(a):

• będzie zdaje się jeden kod dla Windowsa i Linux (czy się mylę?) Linuxa niestety nie znam za bardzo, ale gdybym chciał mieć jakąś firmę musiałbym poznać żeby móc ciąć koszty o licencję Windowsa

Koszt windows'a jest niestety jak już napisano kroplą w morzu. Co więcej masz jakiś sensowny pakiet programów do obsługi firmy pod Linux?

SiedemBoleści napisał(a):

• wkurza mnie gdy ściągam pierwszy lepszy program i wszędzie pliki typu Qt5..cośtam..dll więc na pewno nie będę tego Qt używał

Dlaczego to ma wkurzać? Przecież tam i tak się nie zagląda. Odpalasz instalator, wykonuje całą robotę i już. Brzmi to trochę ideologicznie. Nie będę używał bo nie. Nie ma znaczenia czy cąły program jest w jednym pliku exe czy ma jeszcze jakieś dodatkowe biblioteki.

Mr.YaHooo napisał(a):

Dlaczego to ma wkurzać? Przecież tam i tak się nie zagląda. Odpalasz instalator, wykonuje całą robotę i już. Brzmi to trochę ideologicznie. Nie będę używał bo nie. Nie ma znaczenia czy cąły program jest w jednym pliku exe czy ma jeszcze jakieś dodatkowe biblioteki.

Ja zaglądam. Instalator przeważnie wypakowuje 7-zipem jak się da, skanuje na Virutotal wszystkie exe, a poza tym przeważnie trzymam w katalogu programu dokumenty, i przenoszę razem z całym programem między komputerami żeby od nowa nie instalować. i nie konfigurować wszystkiego.

SiedemBoleści napisał(a):

Ja zaglądam. Instalator przeważnie wypakowuje 7-zipem jak się da, skanuje na Virutotal wszystkie exe,

Nie za duża ostrożność? Generalne uważam, że program pobrany z oficjalnej strony producenta powinien być ok.

SiedemBoleści napisał(a):

a poza tym przeważnie trzymam w katalogu programu dokumenty, i przenoszę razem z całym programem między komputerami żeby od nowa nie instalować. i nie konfigurować wszystkiego.

A to już w ogóle słabe rozwiązanie. Dobrą praktyką jest oddzielanie danych/plików użytkownika/configów od plików wykonywalnych. Tak samo jak w programowaniu oddzielasz logikę od GUI. A co do przenoszenia programów bez instalacji, to dużo programów zapisuje sobie różne dane/ustawienia w rejestrach systemowych. Poprawnie napisane aplikacje nie będą zapisywały np. configi w katalogu programu, ale w specjalnie przeznaczonym do tego celu katalogu ProgramData czy w folderze użytkownika. Od tego przecież są dedykowane rozwiązania jak PortableApps. Sam dokonałem portabilizacji kilku programów za pomocą tej platformy na własny użytek. Soft zapisuje dane w rejestrach czy katalogu ProgramData Jest to relatywnie łatwe i eleganckie rozwiązanie.

Możesz wszystko, natomiast czy warto?

Jak jesteś początkującym to nauka C lub C++ na pewno nie zaszkodzi, ale na pewno nie przybliży do pracy. Chyba, że chcesz robić w tych językach.