[kanior]

Witam. Jestem laikiem. Szukałem w Google naprawdę ale wiele na ten temat po polsku nie znalazłem. Umie angielski ale nie na tyle żeby rozumieć wszystko! Bardzo proszę o wyjaśnienie... Czy trudno będzie przejść z C++ na Obj-C? Jest jakieś API dla C++ pod windows, czy pod MAC też jest? Jeżeli tak skąd je wziąć? Jak pisać aplikacje pod windows w c++ na macu? (tu można link - odp alternatywnie bo raczej sobie sam poradze) ; ) Co to jest te całe Cocoa? (czytałem po ang. i dowiedziałem się mało) Czy można tworzyć graficzny interfejs do progamów napisanych w C++ w Interface Builder? Jeżeli nie to do czego on w takim razie służy? Aplikacje na iPhona i iPada pisze się w Obj-C czy Coca Framework? Czym się to różni? Czy aby uczyć się Coca to jest "osobny język jak jQuery dla JS czy tylko jakieś rozwinięcie dodające nowe znaczniki dla Obj-C?" Z góry dziękuję. Nie podawajcie mi jakiś linków tylko sami wyjaśnijcie a lepiej zapamiętam o co w tym wszystkim chodzi. Pozdrawiam.

[adios.pl]

Czy trudno będzie przejść z C++ na Obj-C?

Z pewnością bardziej przydatna jest znajomość semantyki języka C niż C++ - ten z kolei nie pomaga w opanowywaniu składni i nazewnictwa Objective-C. Natomiast C++ daje Ci znajomość mechanizmów obiektowych. Gdybyś znał Smaltalka przejście na Objective-C było by szybkie i bezbolesne.

Jest jakieś API dla C++ pod windows, czy pod MAC też jest? Jeżeli tak skąd je wziąć?

Musisz doprecyzować pytanie - chodzi ci o IDE, wrappera czy co?

Jak pisać aplikacje pod windows w c++ na macu? (tu można link - odp alternatywnie bo raczej sobie sam poradze) ; )

Jeśli aplikacje będą konsolowe to w zasadzie nie ma żadnych problemów - ewentualna kwestia dopisania paru #IFDEFów dla preprocesora. Jeżeli chciałbyś pisać coś okienkowego to przede wszystkim QT, wxWidgets (możliwości jest oczywiście więcej).
Tak jak w aplikacjach konsolowych należy uważać przy pewnych zagwozdkach - np. w QT opisuje to dokument:
Qt 4.7: Qt for Mac OS X - Specific Issues

Co to jest te całe Cocoa? (czytałem po ang. i dowiedziałem się mało)

Jest to obiektowy interfejs programistyczny pomagający tworzyć "całościowe" aplikacje. Dostarcza on nam wielu gotowych klas, metod (zaczynających się od NS...) - są to np. elementy interfejsu Aqua - okienka, guziki, monity, ale także obsługa zdarzeń, wątków czy konkretne kontenery itp. Spróbuję taki schemat:

Jądro Darwin <-> OpenGL <-> Cocoa <-> Aqua

Czy można tworzyć graficzny interfejs do progamów napisanych w C++ w Interface Builder? Jeżeli nie to do czego on w takim razie służy?

Można przy czym wiąże się to z komplikacjami. Na takim poziomie zaawansowania nie ma sensu bawić się w pisanie handlera widoku/wrappera. Tutaj jest przykład takiej nikomu niepotrzebnej zabawy:
Loading…

Być może można też coś pokombinować z apple script.

Aplikacje na iPhona i iPada pisze się w Obj-C czy Coca Framework? Czym się to różni?

Językiem programowania jest Objective-C a frameworkiem Cocoa Touch (w odróżnieniu od Cocoa zwykłego na MacOS X).

Czy aby uczyć się Coca to jest "osobny język jak jQuery dla JS czy tylko jakieś rozwinięcie dodające nowe znaczniki dla Obj-C?"

jQuery to po prostu biblioteka JS uproszczająca nam zadanie. Cocoa to API, wraz z Objective-C pozwala nam tworzyć aplikacje niejako wymuszając wzorzec Model-View-Controller. Rozumiem, że przez znaczniki rozumiesz "dodatkowe funkcje". Jeśli tak to Cocoa daje Ci między innymi:
- Możliwość rysowania okienek, kontrolek
- obsługę grafiki, audio, video
- obsługę baz danych
- usługi internetowe
- dostęp do języków skryptowych

[Roberto]

Cocoa w stosunku do Obj-C to to samo praktycznie co jQuery w stosunku do JavaScript. Tylko jQuery to żaden osobny język, tylko po prostu framework.

[kanior]

- Możliwość rysowania okienek, kontrolek
- obsługę grafiki, audio, video
- obsługę baz danych
- usługi internetowe
- dostęp do języków skryptowych

Czyli w samym Obj.-C nie można okienkowych tworzyć? Rozumiem w takim razie ze Interface builder do Cocoa służy tak?

[metal_man]

Obj-C to jezyk taki jak C/C++/JAVA. Da sie tworzyc aplikacje okienkowe, tylko, ze piszac w jezyku Obj-C oraz wykorzystujac framework Cocoa Moze troche to zagmatwane ale mamy tutaj wiecej opowiadania niz faktycznie pracy

[kanior]

Już rozumie. Zeby pisac w Obj. Aplikacje okienkowe oraz cos na iphona/ipada to trzeba uzyc dodatkowo Cocoa?

[konole]

Tak.

[kanior]

A okienkowe aplikacje napisane w C++ mozna normalnie odpalać na komputerach MAC? To już chyba ost. pytanie.

[Roberto]

to zależy. czego użyłeś do stworzenia tych okienek (samemu przecież po ekranie nie rysujesz) Qt jest multiplatformowe i jest w C++.

[kanior]

A konsolwe bez problemów pod winzgrozą uruchomie?

[konole]

O ile nie załączasz jakichś egoztycznych bibliotek dostępnych tylko na Maca (o ile takie są, oprócz frameworka Cocoa), to tak.

[kanior]

No i o takie odpowiedzi mi Panowie chodziło. Dziękuje Wam!! Btw. "egzotyczne" ?

[konole]

Przykład - Windows i "conio.h"

[kanior]

A ty jesteś programistą?

[konole]

Tak, ale na chwilę obecną raczej PHP / MySQL + Symfony2, niż C (i Obj-C). To podczas 4-miesięcznych wakacji zamierzam podciągnąć.

[ishadow]

Obj-C, czy C/C++ to języki programowania. Zaś Cocoa to framework zapewniający wysokopoziomowe funkcje/obiekty do tworzenia interfejsu użytkownika czy komunikacji z systemem operacyjnym - taki Macowy odpowiednik WinAPI.

Obj-C na podstawowym poziomie nie różni się zbytnio od C++. Składnia jest trochę inna, ale w gruncie rzeczy mają wiele cech wspólnych Objective-C - Wikipedia, the free encyclopedia

Jednak, aby skutecznie programować w tym języku trzeba poznać jego filozofię, a jest ona trochę inna niż w C++. Główną różnicą z praktycznego punktu widzenia jest zarządzenie pamięcią. O ile C++ wymaga alokacji i zwalniania pamięci, to w obj-C obiekty mogą mieć pamięć przydzieloną tymczasowo tj. mogą zostać usunięte zaraz po tym jak metoda skończy się wykonywać (choć mogą istnieć jeszcze przez bliżej nieokreślony czas), możemy je również zatrzymać "retain" i to wielokrotnie np. kilka obiektów retainuje jedną instancję innego obiektu, który zostanie usunięty dopiero, gdy odpowiednią ilość razy wywołamy na nim "release"(raz za dużo = crash). Takie podejście jest bardzo wygodne, ale sprzyja błędom i jeśli ktoś nie do końca rozumie jak to działa raczej nie napisze stabilnej i pozbawionej wycieków pamięci aplikacji.

Kolejną kwestią jest Cocoa. Zasada jest taka, że z klas jakie oferuje korzysta się w ostateczności, bo choć wygodne, to są wolne. Przykładowo NSArray jest dobre, żeby trzymać w niej kilka obiektów, do których odwołujemy się co kilka sekund. Jeśli zaś potrzebujemy tablicę o wymiarach kilkatysięcy i to wywoływaną z każdą klatką tj. 60 razy na sekundę, to o wiele szybciej jest korzystać nawet ze zwykłej tablicy z C.

Oczywiście zawsze można pisać w obj-C++, czyli łączyć obj-C z C++, ale ja nie jestem zwolennikiem tego rozwiązania. Co prawda korzystam z tego od czasu do czasu np. korzystając z Box2D, ale jeśli nie ma takiej potrzeby, to nie warto zaśmiecać kodu.

[Scypin]

Objective-C++ jest przydatny czasami jednak klasy C++ i Objective-C++ są niezbyt kompatybilne ze sobą na dłuższą mete, więc się używa tego raczej jako konieczność. Natomiast funkcji C można używać bez ograniczeń w kodzie Objective-C (w sumie w kodzie C++ także ). Objective-C jest bardzo wygodny w użyciu, dużo daje dynamika tego tego języka, jednak poza Cocoa UIKit czy samo Foundation to nie znam żadnych innych bibliotek, dlatego zwykle interface projektuje się w Objective-C/Cocoa a silnik w C. Oczywiście jest GNUStep na Windowsa, dzięki któremu można pisać programy z użyciem Objective-C/Foundation jednak ta biblioteka pozwala jedynie na tworzenie aplikacji konsolowych.

[metal_man]

Jednak, aby skutecznie programować w tym języku trzeba poznać jego filozofię, a jest ona trochę inna niż w C++. Główną różnicą z praktycznego punktu widzenia jest zarządzenie pamięcią. O ile C++ wymaga alokacji i zwalniania pamięci, to w obj-C obiekty mogą mieć pamięć przydzieloną tymczasowo tj. mogą zostać usunięte zaraz po tym jak metoda skończy się wykonywać (choć mogą istnieć jeszcze przez bliżej nieokreślony czas), możemy je również zatrzymać "retain" i to wielokrotnie np. kilka obiektów retainuje jedną instancję innego obiektu, który zostanie usunięty dopiero, gdy odpowiednią ilość razy wywołamy na nim "release"(raz za dużo = crash). Takie podejście jest bardzo wygodne, ale sprzyja błędom i jeśli ktoś nie do końca rozumie jak to działa raczej nie napisze stabilnej i pozbawionej wycieków pamięci aplikacji.

To jeszcze ciekawe pytanie ode mnie - jest gdzis lopatologicznie to wszystko wyjasnione?

[Roberto]

w jakimkolwiek kursie o programowaniu w Obj-C, w książkach (np. Cocoa Programming for Mac OS X), w wykładach (np. w iTunes U są wykłady ze Stanforda i oczywiście jest tam o zarządzaniu pamięcią). To jest podstawa, to będzie wszędzie. A rzecz koncepcyjnie jest kosmicznie prosta, kwestia przyzwyczajenia i kontroli. Pod OS X'em nie trzeba już się tym martwić (jest garbage-collector i jeżeli nie robi się jakiejś 'mocnej' aplikacji to wystarczy), ale pod iOS'em nadal się trzeba w to bawić

[metal_man]

To musze jeszcze poszukac jakichs informacji na ten temat. Jakos opinane zarzadzanie u Hillegassa do mnie nie trafia Widocznie ja taki niekumaty.

[konole]

Sprawdź jeszcze pozycję napisaną przez: Stephen Kochan, jeśli chodzi o Objective-C

[kanior]

Dla C++ jest coś takie jak WinAPI, jaki jest odpowiednik dla MAC?

Jest jakieś API dla C++ pod windows, czy pod MAC też jest? Jeżeli tak skąd je wziąć?

O to mi własnie w powyzszym pytaniu chodziło - bo doczytałem.

[Roberto]

tak.

[kanior]

No a jaki?

[adios.pl]

OMG. Aż dziwne, że warna jeszcze nie dostałeś Masz wszystko napisane wyżej. Carbon dla C - MacOS Classic 8,9, można też w X. Cocoa dla Objective-C - MacOS X. Apple rozwija też binding Javy do Cocoa (przynajmniej jeśli chodzi o same "okienka"), są też bindingi takie jak Cocoa#, etc. Możesz też bindować przez AppleScript.