[bartoneczek]

Powiedzcie mi, jak to jest z bibliotekami do C++? Domyślam się że są wieloplatformowe (jak np. podstawowa iostream), i jednoplatformowe (jak np obsługa socketów: WinSock dla Windowsa i socket dla Linuksa). Jeśli nie, to wyprowadźcie mnie z błędu. :)

Ale bardziej zastanawia mnie czy biblioteki są też zależne od architektury. Np. czy wspomniana biblioteka "sys/socket" będzie działała na linuksie niezależnie od architektury (czy to linuks na x86 czy na ARM)?

Poza tym, skąd wiedzieć czy konkretna biblioteka została napisana pod dany system, a przedewszystkim skąd wie to kompilator? Może trochę zagmatwałem ale mam nadzieję że zrozumieliście moje rozterki. :D

#cpp #programowanie

[piotrfelix]

@bartoneczek: dlatego #tylkojava

[E.....y]

@bartoneczek: Generalnie pytasz jak z przenośnością kodu.

[sylwke3100]

@piotrfelix: Sockety np są chyba w Qt, GTK chyba

[k.....r]

@bartoneczek: Wszystkie standardowe dzialaja wszedzie, a co do innych: musisz sprawdzic w dokumentacji.

[k.....r]

@bartoneczek: A skad kompilator wie: kompilator sprobuje skompilowac, jak sie nie uda, to sie wyrabie i to wszystko. Moze po prostu nie byc jakiejs innej biblioteki. Mozesz sterowac kompilacja dla poszczegolnych platform przez #ifdefy preprocesora.

[KrzaQ2]

@bartoneczek: Kompilator wie ƶe biblioteka jest, jeśli ją widzi ;) Akurat podstawowe unixowe sockety są praktycznie przenoszalne bez zmian między *nixami i windowsem.

[bartoneczek]

@EfektywnieEfektowny: tak. Pytam, dlatego że chcę napisać prosty program do komunikacji przez TCP na ArchLinux na ARM, komunikujący się z powiedzmy programem na Windowsa. Typowy serwer-klient. I nie wiem czy C++ to C++ i mam pisać tu i tu tak samo, a jedyna różnica w parametrach kompilacji, czy jednak do obu programów muszę podejść inaczej.

[deekox]

@bartoneczek: sys/socket.h nie należy do bibliotek c++. Jak będziesz się trzymał wytycznych to prawdopodobnie stworzysz przenośny kod. Sam standard C++ w wielu miejscach specjalnie nie robi żadnych założeń np. co do wielkości typów i ich reprezentacji. W socket masz hton/ntoh + getaddrifno/getnameinfo po to by kod był przenośny.

[bartoneczek]

@kuhar: tak myślałem.

@KrzaQ2: no to fajnie, o tyle łatwiej. :)

[KrzaQ2]

tak. Pytam, dlatego że chcę napisać prosty program do komunikacji przez TCP na ArchLinux na ARM, komunikujący się z powiedzmy programem na Windowsa.

@bartoneczek: Jeden będzie serwerem, drugi klientem, więc raczej nie moƶesz podchodzić tak samo. Pamiętaj, aby uƶywać typów o stałej długości (np.

[bartoneczek]

@deekox: rozumiem że w przypadku socket.g, architektura nie robi żadnej różnicy?

A w przypadku innych bibliotek? Bo akurat wszyscy się skupili na OS. :)

[deekox]

@KrzaQ2: @bartoneczek: lepiej niech sobie daruje przekazywanie danych w reprezentacji binarnej. Wielkość może być ok ale endianess może namieszać. Przesyłać najlepiej jako string

[KrzaQ2]

@deekox: W sumie racja.

[bartoneczek]

@deekox: endianess? Prawdemówiąc planowałem klecić ramkę z kilku bitów i wysyłać właśnie w reprezentacji binarnej.

[KrzaQ2]

@bartoneczek: https://en.wikipedia.org/wiki/Endianness

[k.....r]

@deekox: AVR i x86 sa littleendian.

[KrzaQ2]

@bartoneczek: w sumie jak będziesz uƶywał

ntohs

i

htons

to wszystko powinno być ok. Ale łatwiej stringami. Jedyne czego musisz się naprawdę wystrzegać to przesyłanie całych structów

[deekox]

@bartoneczek: x86 zapisuje liczbę w pamięci 0xaabbccdd tak: dd cc bb aa, inne systemy mogą tak: aa bb cc dd. Ogólnie staraj się unikać "sztuczek bo u mnie działą" i trzymaj jak najbliżej standardu (C++).

[bartoneczek]

@KrzaQ2: @deekox: dzięki Panowie za wyjaśnienia i cenne wskazówki. :)

[A.....k]

@kuhar: Generalnie rdzeń ARM jest bigendian i littleendian. Dopiero konkretna kość z konkretnymi peryferiami wymusza użycie jednego z nich.