Program okienkowy w C

Witam. Chciałbym napisać swój pierwszy program okienkowy. Program zostanie napisany w języku C . Chciałbym się doradzić co wykorzystać i czym się zainteresować żeby taki program okienkowy stworzyć. Do pisania programów używam Visuala. Będę wdzięczny za wszelkiego typu wskazówki oraz pomoc.

Dlaczego chcesz pierwszy w życiu program okienkowy pisać w C? To będzie bardzo nieprzyjemne doświadczenie.

W C to chyba najlepiej wziąć GTK+ ale nie mam większego doświadczenia w tej kwestii. Może jest coś lepszego od GTK dla C ale tutaj się nie orientuję. No i jest jeszcze WinAPI.

Nie jest rzecz jasna ani proste ani szczególnie przyjemne: https://developer.gnome.org/gtk3/stable/ch01s04.html#id-1.2.3.12.5

Jesteś pewien, że chcesz własnie język C? Może chodzi Ci o C++? Wtedy mógłbyś wykorzystać albo Qt, albo WinAPI (w najgorszym przypadku...).
W obu przypadkach da się znaleźć mnóstwo przykładów i tutoriali, a także dokładną dokumentację. Zarówno Qt jak i WinAPI

Jeżeli rzeczywiście chodzi o C++ to Qt jest chyba najlepszym rozwiązaniem.

Chodzi o czyste C. Mam projekt do napisania na studia, a teraz właśnie przerabiamy C, więc jest to wymóg.

W takim razie współczujemy, bo zostaje Ci albo WinAPI albo GTK+. Oba tak samo "przyjemne". Ktoś kto zlecił w dzisiejszych czasach sklejanie projektu GUI w czystym C jest chyba nienormalny.

Ech, kolejna ofiara durnych wymagań na studiach.

WinAPI w rękę i dajesz.

Tu się mogę mylić, ale sam bym tak zrobił: poszukaj jakichś bardzo starych tutoriali (wczesne lata 90), kiedy C+WinAPI było sensownym wyborem. Potem tylko podrasuj ten kod do Win32, dzięki podejściu Microsoftu do kompatybilności powinno pyknąć.

http://www.smorgasbordet.com/pellesc/

@4ever4: a że tak nieśmiało zapytam, jeśli mogę oczywiście: co ma robić ten program wedle założeń projektu? Pytam, bo w przypadku tak niskopoziomowego podejścia do GUI zapewne będzie czekała Cię większa lub mniejsza walka z obsługą formatek w języku C.

grzesiek51114 napisał(a):

W takim razie współczujemy, bo zostaje Ci albo WinAPI albo GTK+. Oba tak samo "przyjemne". Ktoś kto zlecił w dzisiejszych czasach sklejanie projektu GUI w czystym C jest chyba nienormalny.

Akurat mam kolegę-programmera, który właśnie GTK+ chwali, a Qt mu nie podchodzi nijak.
Więc myślę, że warto zajrzeć do GTK+

Wcale nie twierdzę, że GTK+ jest złe. Po prostu myślę, że jest relatywnie mniej wygodne dla większości programistów względem chociażby takiego Qt czy WinFormsów.
Poza tym czy ten kolega aby nie pisze w GTK+ używając jakiegoś wrappera dla C++? :)

Może to brak odpowiedniego IDE do tego GTK+ był problemem?
Widzę że obecnie to Anjuta (IDE) i Glade (designer), ale nie wiem na ile to wygodne.

Zapewne środowiskiem docelowym będzie MS Windows. Zerknij więc tu: http://www.winprog.org/tutorial/start.html
Łatwo nie będzie.

grzesiek51114 napisał(a):

W takim razie współczujemy, bo zostaje Ci albo WinAPI albo GTK+. Oba tak samo "przyjemne". Ktoś kto zlecił w dzisiejszych czasach sklejanie projektu GUI w czystym C jest chyba nienormalny.

WinAPI daje radę. Tylko trzeba sensownie kod pisać. Większość tutoriali i przykładów to jest rzeczywiście nieczytelny kod.

Sam trochę rzeźbiłem w czystym WinAPI dawno temu i jedyne co mi przeszkadzało, to ogrom instrukcji do napisania – po prostu dużo trzeba pisać, nawet dla prostych operacji. Nie przeszkadza to pisać ładnego i czytelnego kodu – kwestia treningu i doświadczenia.

Co i tak nie zmienia faktu, że jest dużo trudniej i ciągle otwarta dokumentacja to konieczność.

Moja lista od najgorszego do najlepszego
WinAPI
Dlugo dlugo nic
GTK+
Gtkmm
QT

GTK+ nie jest takie zle, ale na windowa sie nie nadaje

kq napisał(a):

Tu się mogę mylić, ale sam bym tak zrobił: poszukaj jakichś bardzo starych tutoriali (wczesne lata 90), kiedy C+WinAPI było sensownym wyborem. Potem tylko podrasuj ten kod do Win32, dzięki podejściu Microsoftu do kompatybilności powinno pyknąć.

Ja bym jeszcze doprecyzował żeby poszukał klasyki, czyli Petzold http://www.charlespetzold.com/pw5/ Dla mnie bardzo fajnie napisana i w miarę szybko można to ogarnąć.

GTK+ będzie pewnie najlepszym rozwiązaniem. Przenośne, w miarę łatwe. Poza tym polecam przerzucić się z Visuala na GCC i wypróbować standard C99/C11. ANSI C to mordęga (nowe standardy są znacznie przyjemniejsze), a MS nie specjalnie lubi C i nowe standardy tego języka. W C99 da się pisać nowoczesny fajny kod. Mój language of choice do wielu zastosowań.

nowe standardy są znacznie przyjemniejsze

@elwis: podaj jakiś ciekawy (ale niedługi) przykład na te różnice, może z wyjątkiem VLA, chociaż tutaj nawet nie wiem czy to weszło w C99, ale chyba tak. :-)

grzesiek51114 napisał(a):

@elwis: podaj jakiś ciekawy (ale niedługi) przykład na te różnice, może z wyjątkiem VLA, chociaż tutaj nawet nie wiem czy to weszło w C99. :-)

Tak, VLA wchodzi w C99. Poza tym od C99 można umieszczać zmienne lokalne gdziekolwiek (nie tylko na początku bloku), są literały dla struktur, np:

typedef struct{
    int x, y;
} Point;

// ...

Point c = { .x =10, .y = 20 };
find ((Point) { .x = 20, .y = 1 });

Mamy nagłówek<stdint.h>z typami o stałym rozmiarze w bitach i typyfast, które wybierają najszybszą opcję dla danej platformy. Jest <stdbool.h>z typem *bool*. Jest modyfikatorrestricted, który pozwala na optymalizacje dla działań na niepokrywających się tablicach (do niedawna Fortran był chyba jedyny, który coś takiego dawał). Modyfikator _NoReturn` i jeszcze sporo pomniejszych ficzerów.

Hmm... z tym umieszczaniem zmiennych to w sumie też nawet nie wiedziałem, że wprowadzili dopiero w C99. Używałem hulaszczo i się tym nie przejmowałem, bo miałem w C dość dużą przerwę. Pamiętam, że jeszcze można wewnątrz for'a zrobić zmienną, a też trzeba było zawsze robić to na zewnątrz.

Swoją drogą zdaje mi się, że VLA odkłada dane na stosie i chyba nie można z nim przeholowywać w alokacjach tak jak ze zwykłym malloc'iem. Nie testowałem tego jakoś specjalnie ale śmierdzi mi przepełnieniem stosu w przypadkach, które malloc może spokojnie zaalokować. Będąc podnieconym zwolnieniem z robienia free można strzelić sobie w stopę przez stack overflow hehe. :)

Wiesz, ja mówię o standardach, poszczególne ficzery oczywiście występowały i występują w różnych kompilatorach domyślnie, tak więc jeśli nie ustawiałeś ANSI C explicite, duża część tych rzeczy by przeszła pewnie bez zająknięcia na niektórych kompilatorach.
Jeśli chodzi o VLA to właściwie tak samo jak ze zwykłym stosem, można przeholować. Ewentualnie VLA wprowadza pewną losowość do takich zachowań. Niemniej jednak mądrze dysponując stosem to super ficzer. Nie jest tylko szybszy od malloca (jedna instrukcja:) ) ale też automatycznie zwalnia zmienna. Jak dla mnie malloc () to już jest właściwie bad smell w C99. Czasem trzeba, ale lepiej nie. Często nie trzeba.

grzesiek51114 napisał(a):

Swoją drogą zdaje mi się, że VLA odkłada dane na stosie

Szczegół implementacyjny.

Ale generalnie tak. Nie można przeholować. To raczej do małych tablic, w przypadku których malloc stanowi istotny narzut.
VLA to po prostu zniesiony niepotrzebny wymóg, że tablica na stosie musi mieć rozmiar znany w czasie kompilacji.