W dniu 2017-08-11 o 14:53, M.M. pisze:
> On Friday, August 11, 2017 at 2:03:15 PM UTC+2, slawek wrote:
>> On Fri, 11 Aug 2017 02:34:20 -0700 (PDT), Maciej Sobczak
>> <s...@g...com> wrote:
>>> wraz z biblioteką Qt daje przenośność i możliwo?=
>>> ?ci". I tu ma rację, niezależnie od wad tego języka. Pokry=
>>> cie platform (przenośność) i niszy rynkowych (możliwo=
>>> ści) w C++ jest znacznie lepsze, niż w innych językach i dla=
>>
>> Narzędzia dla C i C++ są powszechnie dostępne, ale programy w nich
>> napisane nie są w 100% przenośne.
>>
>> Między innymi nie jest ustalone czym jest int.
>>
>> W dodatku Komitern ustala kolejne wersje, które są implementowane jak
>> komu się chce. Na przykład w C powinien być typ bool, a bywa że go
>> nie ma.
>>
>> Pod tym względem Java jest nieco lepsza.
>
> Pod względem przenośności i w ogóle pod względem wygody programowania?
> W moim odczuciu jest o niebo lepsza. Wiadomo, nie chodzi strikte o
> język, tylko też o narzędzia. Bo co stoi na przeszkodzie, aby
> napisać kompilatory do C++ na różne platformy w których int
> ma zawsze 32bity? Chyba poza wydajnością nie ma żadnych przeszkód?


Żeby mieć 32 bity w int używamy odpowiedniego typu (int32_t), a nie
inta. Jeśli nie mam takich wymagań , używamy inta.

To chyba proste właśnie takie rzeczy definiuje standard, tylko trzeba
umiejętnie z nich korzystać. I o ile skompiluje program napisany w C czy
C++ pod różnymi dziwnymi platformami, to z powodu braku jvm-a na nie
raczej nie uda mi się uruchomić programów javowych, więc przenośność
zawsze znajdzie bariery niezależnie od tego jak bedziemy chcieli ją uzyskać.


--
http://kaczus.ppa.pl

do góry

On Fri, 11 Aug 2017 05:34:22 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> W Javie jest "community", któro sądzi, że ustala "kolejn?=
> ? wersję" a korporacje i tak implementują jak zechcą i jes=
> zcze destabilizują społeczność sprawami w sądzie o=
> te implementacje. W czym ta sytuacja jest lepsza?
> Bo nie zrozumiałem.


Jakie korporacje??? Jaka społeczność???

Jest tylko jedno Oracle. I co tam się objawi jest niepodważalne.

Społeczność może co najwyżej focha strzelić.

Ale za to gdy jest nowa wersja Javy, to masz ją natychmiast. Kilka
sekund i załatwione. Zwykle taka nowa Java ma coś więcej... a nie
mniej. Nie musisz płacić za nowy kompilator, albo czekać pięć lat aż
ktoś to zaimplementuje.

do góry

W dniu piątek, 11 sierpnia 2017 15:17:11 UTC+2 użytkownik slawek napisał:
> Ciekawe, bo w K&R nic o tym nie ma.
Standard C99 gdzie to wprowadzono został wydany 18 lat temu,
a autorzy kompilatorów bohatersko starają się go przez przypadek
nie zaimplementować w całości. O rzeszy programistów, którzy
popierają to twierdząc, że jedyne koszerne C to C90 nie wspomnę.
Ci sami programiści z miłą chęcią używają np. tablic o wielkości
nie znanej przed kompilacją, których to w C90 nie ma, ale przez
przypadek większość kompilatorów je obsługuje.

Pozdrawiam,
--
Karol Piotrowski

do góry

On Fri, 11 Aug 2017 11:55:26 -0700 (PDT), k...@g...com wrote:
> Standard C99 gdzie to wprowadzono [...]

Jakbym nie wiedział.

Tyle że program napisany w 1975 raczej nie będzie z nim zgodny. Nawet
taki z 1995 (program, biblioteka) nie skompiluje się bezstresowo. Nie
tylko rozmiar int (bywa że 16 bitów, bywa 64), ale np. wskaźniki far
i takie tam.

Czyli masz program w C i nie masz pewności co do tego czy kompilować
jako c89, c99 czy c11. Ok, prawdopodobnie się uda. Ale pewności nie
ma. Np. procedury numeryczne używające stałych matematycznych. Nawet
dość niedawno musiałem żonglować opcją std w GCC. O (domyślnie) nie
działającym printf w MSVC chyba też wiesz.

Ciekawostką jest że Turbo C nie obsługuje przecinka, tj. nie da się
napisać x = ( a = 1, b = 2); itp. Czyli znowu problemy z
przenośnością i z implementacją standardu.

do góry

On Fri, 11 Aug 2017 11:55:26 -0700 (PDT), k...@g...com wrote:
> Ci sami programiści z miłą chęcią używaj?=
> ? np. tablic o wielkości
> nie znanej przed kompilacją, których to w C90 nie ma, ale przez
> przypadek większość kompilatorów je obsługuje.

Akurat MSVC miał awersję do VLA. Tyle że od zawsze, czyli jeszcze
przed C89, bez trudu da się zrobić tablice dynamiczne bez VLA. Tylko
trzeba umieć programować w C.

do góry

Po pierwsze zgadzam się, że sytuacja kompatybilności kodu w C jest
tragiczna i w żadnym wypadku nie miałem zamiaru grać adwokata
diabła:)

W dniu piątek, 11 sierpnia 2017 22:03:12 UTC+2 użytkownik slawek napisał:
> Tyle że program napisany w 1975 raczej nie będzie z nim zgodny. Nawet
> taki z 1995 (program, biblioteka) nie skompiluje się bezstresowo. Nie
> tylko rozmiar int (bywa że 16 bitów, bywa 64), ale np. wskaźniki far
> i takie tam.
Kwestia rozmiaru inta została zaprotezowana przez stdint.h i te piękności
typu uint8_t czy uint_least64_t, podejrzewam, że komitet uznał to za
lepsze rozwiązanie niż przyjęcie jakiegoś jedynego słusznego rozmiaru.
Jak wyszło tak wyszło, legacy kod który korzysta wprost z jakiejś
konkretnej wielkości inta się sam nie zmodyfikował.

> Ciekawostką jest że Turbo C nie obsługuje przecinka, tj. nie da się
> napisać x = ( a = 1, b = 2); itp. Czyli znowu problemy z
> przenośnością i z implementacją standardu.
DOSowe kompilatory były tragiczne pod tym względem - wspomniane przez
Ciebie bliskie i dalekie wskaźniki i bardzo średnia implementacja
standardu. Dziękuję za ciekawostkę, bo nie widziałem Turbo C od
"dość" dawna:)

>Nawet dość niedawno musiałem żonglować opcją std w GCC. O
>(domyślnie) nie działającym printf w MSVC chyba też wiesz.
Dość niedawno musiałem żonglować opcją std przy portowaniu
pewnej małej biblioteki pythonowej na OS X, bo okazało się,
że kawałek kodu w C był traktowany przez clanga jako literalne
C90 i odmawiał kompilacji czegoś w stylu
void f(int n) { int array[n]; ........ }

slawek:
>Akurat MSVC miał awersję do VLA. Tyle że od zawsze, czyli jeszcze
>przed C89, bez trudu da się zrobić tablice dynamiczne bez VLA. Tylko
>trzeba umieć programować w C.
Pewnie, że się da, ale jeżeli mam do wyboru użyć wbudowanej funkcji
języka albo wymyślać koło na nowo, to użyję wbudowanej funkcji języka
pod warunkiem, że 1) robi to, czego potrzebuję, 2) na tyle szybko,
na ile potrzebuję.

do góry

On Fri, 11 Aug 2017 13:43:15 -0700 (PDT), k...@g...com wrote:
> nie widziałem Turbo C od
> "dość" dawna:)

1. Turbo C zciągasz z http://bdn.borland.com/museum

2. DOSBOX

3. I można...

do góry

On Fri, 11 Aug 2017 13:43:15 -0700 (PDT), k...@g...com wrote:
> Pewnie, że się da, ale jeżeli mam do wyboru użyć w=
> budowanej funkcji
> języka albo wymyślać koło na nowo, to użyję w=

Jest powszechnie nierozumienie co do C.

Są języki, w których jeżeli producent kompilatora/interpretera nie
zrobił np. funkcji sinc, to choć można samemu ją sobie dopisać, nie
będzie ona tak sprawnie działać jak gdyby była "intrisic".

W C jest inaczej: jeżeli czegoś nie ma (np. funkcji sinc,
dynamicznych tablic), to można to sobie dopisać BEZ STRATY
WYDAJNOŚCI.

Konkretnie np.:

double* vector_double(size_t n) { return calloc(n,sizeof (double)) ; }

Aby nie wynajdywać koła na nowo po prostu używa się bibliotek.

do góry

W dniu czwartek, 10 sierpnia 2017 22:45:51 UTC+2 użytkownik slawek napisał:

> Język C jest dla
> mięczaków zbyt głupich aby opanować Cobol.

A to ciekawe, bo myślałem, że Cobol jest tłumaczony do C. Więc na logikę powinien być
od niego prostszy i chyba dlatego powstał...

do góry

W dniu czwartek, 10 sierpnia 2017 22:33:15 UTC+2 użytkownik AK napisał:
> > I wybieram C++ jako główny język gdyż wraz z biblioteką Qt daje przenośność i
możliwości.
>
> Hehe Ale sie usmialem:),
> C++ to najgorszy jezyk jaki poznalem.
> Mowie to znajac produkcyjnie j.prog. kilkanasie.
> Nie zmienia faktu (ze C++ to syf) moje ponad 30-etnie w nim stricte prtodukcyjne
> doswiadczenie i bycie prekursorem tego jezyka w czasach gdy w Polsce dominowal
Clipper.

Dobra! To może ugryźmy ten temat na poważnie. Bo skoro znasz (dobrze?!?) języków
programowania kilkanaście, to może jesteś geniuszem i może mógłbyś oświecić ciemne
masy klepaczy co jest nie tak z C++. Bo chyba nie to, że trzeba deklarować typ
zmiennej?!? I pilnować zwalniania wskaźników?!?

do góry