🚀 go-pugleaf

W dniu sobota, 11 stycznia 2020 23:50:00 UTC+1 użytkownik Maciej Sobczak napisał:
> No i bombki strzelone. Tyle było wymądrzania, że Python, że Rust, że Haskell i że co tam jeszcze.
> 
> https://www.tiobe.com/tiobe-index/
> 
> Spoiler: C dostał medal za wstanie z kolan.
> 
> Tylko żeby nie było płakania, że TIOBE nie jest miarodajny. Oczywiście, że nie jest. Ale to, że język, którego miało już nie być a jest jak najbardziej, jest ciekawą informacją.
> 
> Wszystko wina embedów.

<troll mode on>
Nie rozumiem. Dlaczego nie C++? Przecież C++ ma więcej ficzerów i jest obiektywnie lepszy, i nie ma nic, co można zrobić w C, czego nie można by zrobić w C++?

No i przecież C jest już od dawna nierozwijany, a C++ złapał rytm, i co trzy lata są wprowadzane do standardu nowe ficzery. Dlaczego ktoś w ogóle chciałby korzystać z tego przestarzałego języka, skoro sięgnięcie po C++ nic go nie kosztuje? Przecież embedded to teraz głównie ARMy, i GCC dla ARMów obsługuje oczywiście C++.
</troll mode off>

> <troll mode on>
> Nie rozumiem. Dlaczego nie C++?

Ależ nie ma w tym nic z trollowania. Też nie rozumiem w sensie własnych wyborów, aczkolwiek potrafię sobie wyobrazić mechanizm, który wpycha ludzi w C. Otóż tym mechanizmem są obecnie generatory kodu produkujące wstępnie zainicjalizowany projekt na podstawie konfiguracji peryferiów. Np. (jeśli nie w szczególności) ten:

https://www.st.com/en/development-tools/stm32cubemx.html

Nie opłaca się tego robić ręcznie a z wizarda wychodzi kod w C. Pozostaje go rozwijać dalej. Inną metodą rozpoczynania projektu jest wzięcie na żywca jakiegoś przykładu z zasobów producenta a takie przykłady niemal zawsze są w C.

I tak, jedną metodą lub drugą, wszystkie projekty startują jako C. Rozwijanie ich przez dopisywanie kodu w C++ wymaga pewnego ogarnięcia, którego w tej branży może brakować.

Ta teoria ma potwierdzenie również w kategorii desktop, gdzie kod w C++ był masowo pisany wtedy, gdy projekty były inicjowane z wizardów lub frameworków w C++ (MFC, Qt, itp.).

Czyli to nie całkiem jest wybór programisty. Producenci narzedzi (a w przypadku embedów nawet producenci krzemu) mają istotny wpływ na to, jaki język "wybierze" programista.

-- 
Maciej Sobczak * http://www.inspirel.com

W dniu niedziela, 12 stycznia 2020 19:39:19 UTC+1 użytkownik Maciej Sobczak napisał:
> > <troll mode on>
> > Nie rozumiem. Dlaczego nie C++?
> 
> Ależ nie ma w tym nic z trollowania.

Pewnie kwestia perspektywy ;]

> Też nie rozumiem w sensie własnych wyborów, aczkolwiek potrafię sobie wyobrazić mechanizm, który wpycha ludzi w C. Otóż tym mechanizmem są obecnie generatory kodu produkujące wstępnie zainicjalizowany projekt na podstawie konfiguracji peryferiów. Np. (jeśli nie w szczególności) ten:
> 
> https://www.st.com/en/development-tools/stm32cubemx.html
> 
> Nie opłaca się tego robić ręcznie a z wizarda wychodzi kod w C.

Wręcz bym powiedział, że "gówno-kod w C".
Co jest smutne. Bo o ile pomysł "wykonywalnej dokumentacji" jest jak najbardziej chwalebny, to - pomijając nawet kwestię samego działania narzędzia, które jest raczej toporne - wygenerowany kod to jest jakiś koszmarek.

Podobnie jak to, żeby na mikrokontrolery dostarczać "warstwę abstrakcji sprzętowej" (?).
Tzn. ja bym się raczej spodziewał po opisie takiego narzędzia, że dostanę wysoce zoptymalizowany kod inicjalizujący, a nie jakąś monstrualną bibliotekę, najeżoną od funkcji, których celem jest wypełnianie struktur danymi. (Serio, wygląda to tak, jakby inżynierowe w ST nie rozkminili jeszcze, że w C istnieje składnia do inicjalizacji struktur. I jakby nie wiedzieli, do czego służy const.)

> Pozostaje go rozwijać dalej.

Moim zdaniem to ma sens do szybkiego uruchomienia/wypróbowania czegoś.
Bo jest kod wygenerowany, który nie ja pisałem, i w którym wprowadzanie zmian jest bolesne (bo muszę regenerować projekt)

> Inną metodą rozpoczynania projektu jest wzięcie na żywca jakiegoś przykładu z zasobów producenta a takie przykłady niemal zawsze są w C.

I pewnie C jest do tego wystarczającym językiem.

> I tak, jedną metodą lub drugą, wszystkie projekty startują jako C. Rozwijanie ich przez dopisywanie kodu w C++ wymaga pewnego ogarnięcia, którego w tej branży może brakować.
> 
> Ta teoria ma potwierdzenie również w kategorii desktop, gdzie kod w C++ był masowo pisany wtedy, gdy projekty były inicjowane z wizardów lub frameworków w C++ (MFC, Qt, itp.).
> 
> Czyli to nie całkiem jest wybór programisty. Producenci narzedzi (a w przypadku embedów nawet producenci krzemu) mają istotny wpływ na to, jaki język "wybierze" programista.

Uwaga bardzo słuszna.

(Czasem sobie myślę, że ST specjalnie rozdmuchuje tego HALa, żeby klienci kupowali kontrolery z większą ilością flasha na pokładzie.)

> Co jest smutne. Bo o ile pomysł "wykonywalnej dokumentacji" jest jak najbardziej chwalebny, to - pomijając nawet kwestię samego działania narzędzia, które jest raczej toporne - wygenerowany kod to jest jakiś koszmarek.

Tak. Tym bardziej jest to przerażające, jeśli sobie uświadomimy, że zapewne taki kod steruje nie tylko spłuczką w kiblu, ale też np. dozownikiem lekarstw w szpitalu.

> Podobnie jak to, żeby na mikrokontrolery dostarczać "warstwę abstrakcji sprzętowej" (?).

To nie jest zły pomysł (ale można go oczywiście źle zrealizować). Jeśli jest cała rodzina mikrokontrolerów, które np. mają Ethernet, to nie jest złym pomysłem, żeby ten Ethernet był obsługiwany z grubsza przez takie samo API.
To znakomicie ułatwia producentowi wciśnięcie odbiorcom nowego mikrokontrolera a tempo tego wciskania jest coraz szybsze. Przecież bez takiego HALa nikt by nigdy nie kupił nowego układu.

Pytanie 1: co ma dłuższy czas życia? Software czy hardware?
Pytanie 2: jak na poprzednią odpowiedź wpływa rozróżnienie pomiędzy PC i embedy?

> Tzn. ja bym się raczej spodziewał po opisie takiego narzędzia, że dostanę wysoce zoptymalizowany kod inicjalizujący,

A po co zoptymalizowany? To się wykonuje tylko raz.
Być może chciałbyś mieć błyskawicznie startujący układ, ale oczekiwanie na fizyczny rozruch peryferiów i tak trwa dłużej, niż wykonanie nawet najbardziej szmacianego kodu inicjalizującego.

> a nie jakąś monstrualną bibliotekę, najeżoną od funkcji, których celem jest wypełnianie struktur danymi.

Tu się zgadzam, efekt końcowy powoduje opad kończyn.
Ale wystarczy nie zaglądać do środka, i można pozostać optymistą.

> Moim zdaniem to ma sens do szybkiego uruchomienia/wypróbowania czegoś.

I nawet wtedy jesteś w plecy z robotą, bo ten produkt już jest komuś obiecany albo wręcz sprzedany.

> Bo jest kod wygenerowany, który nie ja pisałem, i w którym wprowadzanie zmian jest bolesne (bo muszę regenerować projekt)

Teoretycznie nie musi być bolesne, bo są mechanizmy pozwalające rozgraniczyć kod generowany od modyfikowanego.

> (Czasem sobie myślę, że ST specjalnie rozdmuchuje tego HALa, żeby klienci kupowali kontrolery z większą ilością flasha na pokładzie.)

Flash to pikuś. Możesz mieć ile chcesz. Wyścig jest raczej o peryferia. Typowy mikrokontroler ma więcej funkcjonalnych peryferiów niż nóżek. A skoro ilość nóżek przestała być ograniczeniem, to wyścig trwa w najlepsze. I po to jest ten HAL, żeby użytkownik dzisiejszego mikrokontrolera nie miał obaw zamawiając nowy model.

Oczywiście to nadal nie usprawiedliwia wypychania języka C na tron. Ale tak się właśnie dzieje.

-- 
Maciej Sobczak * http://www.inspirel.com

W dniu poniedziałek, 13 stycznia 2020 19:30:20 UTC+1 użytkownik Maciej Sobczak napisał:
> > Podobnie jak to, żeby na mikrokontrolery dostarczać "warstwę abstrakcji sprzętowej" (?).
> 
> To nie jest zły pomysł (ale można go oczywiście źle zrealizować). Jeśli jest cała rodzina mikrokontrolerów, które np. mają Ethernet, to nie jest złym pomysłem, żeby ten Ethernet był obsługiwany z grubsza przez takie samo API.
> To znakomicie ułatwia producentowi wciśnięcie odbiorcom nowego mikrokontrolera a tempo tego wciskania jest coraz szybsze. Przecież bez takiego HALa nikt by nigdy nie kupił nowego układu.

No, ale w moim odczuciu lepszym pomysłem byłoby po prostu dbanie o zgodność niskopoziomowego interfejsu pomiędzy kolejnymi urządzeniami kontrolera.
(A jeżeli miałoby to być niemożliwe, to zastanowienie się, dlaczego ma to być niemożliwe)

> Pytanie 1: co ma dłuższy czas życia? Software czy hardware?
> Pytanie 2: jak na poprzednią odpowiedź wpływa rozróżnienie pomiędzy PC i embedy?
> 
> > Tzn. ja bym się raczej spodziewał po opisie takiego narzędzia, że dostanę wysoce zoptymalizowany kod inicjalizujący,
> 
> A po co zoptymalizowany? To się wykonuje tylko raz.
> Być może chciałbyś mieć błyskawicznie startujący układ, ale oczekiwanie na fizyczny rozruch peryferiów i tak trwa dłużej, niż wykonanie nawet najbardziej szmacianego kodu inicjalizującego.

Zoptymalizowany pod dwoma kątami:
- rozmiaru, jaki zajmuje w pamięci stałej
- kolejności inicjalizacji, ze względu na czas inicjalizacji peryferiów (bo producent wie to lepiej ode mnie)

> > Bo jest kod wygenerowany, który nie ja pisałem, i w którym wprowadzanie zmian jest bolesne (bo muszę regenerować projekt)
> 
> Teoretycznie nie musi być bolesne, bo są mechanizmy pozwalające rozgraniczyć kod generowany od modyfikowanego.

Jest bolesne.
Fajny pomysł mają goście z Krakowa, język Luna
https://www.luna-lang.org
opiera się o "dualną reprezentację graficzno tekstową". Można sobie przełączać. To jest lepsze od generowania, bo mamy izomorfizm. Czyli można np. używać tradycyjnych narzędzi diffujących (o czym sam kiedyś wspominałeś).

W CubeMX nie można (albo ja nie wiem jak). A ich pomysł na rozwój aplikacji (że dają mi szablony, i ja wciskam swój kod pomiędzy ich komentarze) jest po prostu koszmarny.

> Oczywiście to nadal nie usprawiedliwia wypychania języka C na tron. Ale tak się właśnie dzieje.

Nie wiem jaki inny język mieliby wcisnąć.

[HAL]
> No, ale w moim odczuciu lepszym pomysłem byłoby po prostu dbanie o zgodność niskopoziomowego interfejsu pomiędzy kolejnymi urządzeniami kontrolera.

Niskopoziomowego, czyli co? Adresy rejestrów i układ bitów w środku? To za nisko, bo na tym poziomie i tak nikt nie chce pracować. Pomrugać LEDem to się jeszcze da na tym poziomie, ale obsługa jakiegokolwiek interfejsu komunikacyjnego to już wyższa forma masochizmu. Po prostu nikt normalny tak nie robi.
A cokolwiek powyżej tego poziomu to właśnie HAL.

[kod inicjalizacyjny]
> Zoptymalizowany pod dwoma kątami:
> - rozmiaru, jaki zajmuje w pamięci stałej

A po co? To i tak jest najmniejsza część całości, w skład której zwykle wchodzi jakiś RTOS, być może też jakiś stos TCP, itd.
Optymalizowanie tego to strata czasu - chociaż, oczywiście, spodziewamy się jakiegoś minimum rozsądku, np. że ten kod nie będzie zawierał fragmentów odpowiedzialnych za nieużywane peryferia. Ale właśnie po to jest wizard, żeby taką konfigurowalność zapewnić.

Mnie bardziej śmieszy fakt, że ten CubeMX wymaga Javy. I w ten sposób, żeby napisać program liczony w kilobajtach trzeba zainstalować softu liczonego w gigabajtach. To jest obiektywnie głupie. Konfigurator jądra Linuksa można było kiedyś zrobić kilka rzędów wielkości taniej a teraz całe dziedzictwo IT z ostatnich 30 lat bierze udział w konfigurowaniu nóżki w mikrokontrolerze.

> - kolejności inicjalizacji, ze względu na czas inicjalizacji peryferiów (bo producent wie to lepiej ode mnie)

Zakładamy, że tak jest. Nie widzę powodu, żeby nie było.

> > Teoretycznie nie musi być bolesne, bo są mechanizmy pozwalające rozgraniczyć kod generowany od modyfikowanego.
> 
> Jest bolesne.

Dlaczego?

> Fajny pomysł mają goście z Krakowa, język Luna
> https://www.luna-lang.org
> opiera się o "dualną reprezentację graficzno tekstową". Można sobie przełączać. To jest lepsze od generowania, bo mamy izomorfizm. Czyli można np. używać tradycyjnych narzędzi diffujących (o czym sam kiedyś wspominałeś).

Izomorfizm daje np. konfigurator Texas Instruments (bo przecież ST to nie jedyna firma na rynku). Konfiguracja to tradycyjny plik tekstowy, ale ogląda się to graficznie (jeśli ktoś chce).

> W CubeMX nie można (albo ja nie wiem jak). A ich pomysł na rozwój aplikacji (że dają mi szablony, i ja wciskam swój kod pomiędzy ich komentarze) jest po prostu koszmarny.

To wciskaj tam nie swój kod, tylko jedną linijkę wywołującą właściwy program w innych plikach. Wtedy nie jest bolesne a poniesione ryzyko to właśnie ta jedna linijka.

> > Oczywiście to nadal nie usprawiedliwia wypychania języka C na tron. Ale tak się właśnie dzieje.
> 
> Nie wiem jaki inny język mieliby wcisnąć.

C++? Przecież całe środowisko Arduino tak działa.
I tak każdy producent ma kompilator C++, więc nie widzę problemu.

Do zastosowań krytycznych te wizardy i tak się nie nadają, więc nie ma się co spinać. A rozsądny pozdbiór C++ na tym poziomie (powiedzmy bez wyjątków i polimorfizmu) byłby wystarczająco tani.

-- 
Maciej Sobczak * http://www.inspirel.com

On Saturday, January 11, 2020 at 11:50:00 PM UTC+1, Maciej Sobczak wrote:
> [...]
> Wszystko wina embedów.

Nie wiem czy to wina embedów, ja na Atmega8 programowałem w C++:

https://pdf1.alldatasheet.com/datasheet-pdf/view/171426/ATMEL/ATMEGA8.html

Cytat
[
– 8K Bytes of In-System Self-Programmable Flash
– 512 Bytes EEPROM
– 1K Byte Internal SRAM
]

Pozdrawiam

Maciej Sobczak <see.my.homepage@gmail.com> Wrote in message:
> Tylko żeby nie było płakania, że TIOBE nie jest miarodajny. 

Wadą TIOBE jest rozdzielanie C/C++/C# - choć należałoby sumować
 ich popularność jako dialektów jednego języka.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

> Wadą TIOBE jest rozdzielanie C/C++/C# - choć należałoby sumować
>  ich popularność jako dialektów jednego języka.

Oj, nie wiem. Związek między C i C# jest taki jak między polskim i łacińskim. Na oko wygląda podobnie, nawet niektóre wyrazy da się użyć tu i tam.

C i C++ mają do siebie bliżej, z racji współdzielonych narzędzi i platform docelowych. Ale C#? Nie, to jest odrębny język.

-- 
Maciej Sobczak * http://www.inspirel.com

On Friday, January 24, 2020 at 8:19:44 AM UTC+1, Maciej Sobczak wrote:
> > Wadą TIOBE jest rozdzielanie C/C++/C# - choć należałoby sumować
> >  ich popularność jako dialektów jednego języka.
> 
> Oj, nie wiem. Związek między C i C# jest taki jak między polskim i łacińskim. Na oko wygląda podobnie, nawet niektóre wyrazy da się użyć tu i tam.
> 
> C i C++ mają do siebie bliżej, z racji współdzielonych narzędzi i platform docelowych. Ale C#? Nie, to jest odrębny język.

C i C++ to też dwa zupełnie odrębne języki. Chyba, że łączymy języki wg pierwszej literki, to wpadnie też Cobol, Closure czy Clean. :)

w.

On 1/24/20 8:19 AM, Maciej Sobczak wrote:
>> Wadą TIOBE jest rozdzielanie C/C++/C# - choć należałoby sumować
>>   ich popularność jako dialektów jednego języka.
> 
> Oj, nie wiem. Związek między C i C# jest taki jak między polskim i łacińskim. Na oko wygląda podobnie, nawet niektóre wyrazy da się użyć tu i tam.
> 
> C i C++ mają do siebie bliżej, z racji współdzielonych narzędzi i platform docelowych. Ale C#? Nie, to jest odrębny język.
> 

C# jest cąłkiem różny od C, już blizej mu do Javy:
((C C++) Rust) (Java C#)

On Friday, January 24, 2020 at 8:19:44 AM UTC+1, Maciej Sobczak wrote:
> > Wadą TIOBE jest rozdzielanie C/C++/C# - choć należałoby sumować
> >  ich popularność jako dialektów jednego języka.
> 
> Oj, nie wiem. Związek między C i C# jest taki jak między polskim i łacińskim. Na oko wygląda podobnie, nawet niektóre wyrazy da się użyć tu i tam.
> 
> C i C++ mają do siebie bliżej, z racji współdzielonych narzędzi i platform docelowych. Ale C#? Nie, to jest odrębny język.
> 

Prawdy są dwie, po pierwsze tak jak napisałeś, C i C++  to całkiem inne 
języki, po drugie C jest (nie licząc paru drobiazgów) w całości kompilowany
przez kompilator języka C++. A C# i Java to chyba tylko wizualnie są
podobne do C++, jakby nie znak dolara, to i PHP byłoby (tylko) wizualnie 
podobne do C++. 

Pozdrawiam

"M.M." <mmarszik@gmail.com> Wrote in message:
> On Friday, January 24, 2020 at 8:19:44 AM UTC+1, Maciej Sobczak wrote:> > Wadą TIOBE jest rozdzielanie C/C++/C# - choć należałoby sumować> >  ich popularność jako dialektów jednego języka.> > Oj, nie wiem. Związek między C i C# jest taki jak między polskim i łacińskim. Na oko wygląda podobnie, nawet niektóre wyrazy da się użyć tu i tam.> > C i C++ mają do siebie bliżej, z racji współdzielonych narzędzi i platform docelowych. Ale C#? Nie, to jest odrębny język.> Prawdy są dwie, po pierwsze tak jak napisałeś, C i C++  to całkiem inne języki, po drugie C jest (nie licząc paru drobiazgów) w całości kompilowanyprzez kompilator języka C++. A C# i Java to chyba tylko wizualnie sąpodobne do C++, jakby nie znak dolara, to i PHP byłoby (tylko) wizualnie podobne do C++. Pozdrawiam

1. Kompilator C++ kompiluje C. Da się pisać w C++ tak, że
 skompiluje to się jako C. Jeżeli np. zobaczysz taki fragment jak
 *ptr++ to równie dobrze może to być C jak C++. Preprocesor jest
 identyczny.

2. Różnica pomiędzy C a C# jest - tak samo jak pomiędzy Pascalem a
 Delphi. Zwykle "delfiarze" mówią że Delphi to Pascal.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

W dniu piątek, 24 stycznia 2020 15:43:15 UTC+1 użytkownik slawek napisał:

> 
> 1. Kompilator C++ kompiluje C.

Ściśle rzecz biorąc, kompilator C++ kompiluje C++.

https://www.quora.com/Is-there-any-C-code-that-isn-t-valid-C-code/answer/Joe-Zbiciak

> Da się pisać w C++ tak, że skompiluje to się jako C.

Nawet w JavaScripcie da się tak pisać. Np. takie coś:

function() {
   return 5;
}

> Jeżeli np. zobaczysz taki fragment jak
>  *ptr++ to równie dobrze może to być C jak C++.

Jeżeli np. zobaczysz taki fragment jak 2+2 albo f(x) to równie dobrze może to być FORTRAN albo Pascal albo Python albo Lua.

Więc może można by w ogóle spłaszczyć to całe TIOBE.

> Preprocesor jest
>  identyczny.

https://www.youtube.com/watch?v=1ClCpfeIELw

> 2. Różnica pomiędzy C a C# jest - tak samo jak pomiędzy Pascalem a
>  Delphi. Zwykle "delfiarze" mówią że Delphi to Pascal.

Pascal to język programowania, a Delphi to środowisko programistyczne.
C# to nie jest środowisko programistyczne.

On Fri, 24 Jan 2020 15:43:11 +0100 (GMT+01:00), slawek wrote:

> 2. Różnica pomiędzy C a C# jest - tak samo jak pomiędzy Pascalem a
>  Delphi. 

Tak nawiasem mówiąc to C# powstał na bazie doświadczeń z Delphi tylko
składnię dostał z rodziny C.

> Zwykle "delfiarze" mówią że Delphi to Pascal.

Nie, to Ty uparcie nazywasz Delphi pascalem. "Delfiarze" nazywają ten język
Delphi lub, gdy gadają z kimś spoza środowiska, Object Pascal.

-- 
pozdrawiam
Roman Tyczka

> C i C++ to też dwa zupełnie odrębne języki.

Niezupełnie. Standard języka C++ w pierwszym rozdziale (Scope) stwierdza, że to, co oferuje C++, to jest "in addition" do tego, co oferuje język C. Podobnie w rozdziale 20, o bibliotece standardowej: "The C++standard library also makes available the facilities of the C standard library".

To jest wystarczająco czytelna i oficjalna deklaracja. Raczej nie da się z tym przepychać tezy, że to są "zupełnie odrębne języki".

Natomiast, co ciekawe, społeczności używające tych języków są wobec siebie bardziej odrębne (w sensie wzajemnej pogardy), niż te języki.

-- 
Maciej Sobczak * http://www.inspirel.com

On Friday, January 24, 2020 at 4:11:41 PM UTC+1, godek...@gmail.com wrote:
> W dniu piątek, 24 stycznia 2020 15:43:15 UTC+1 użytkownik slawek napisał:
> 
> > 
> > 1. Kompilator C++ kompiluje C.
> 
> Ściśle rzecz biorąc, kompilator C++ kompiluje C++.
> 
> https://www.quora.com/Is-there-any-C-code-that-isn-t-valid-C-code/answer/Joe-Zbiciak
> 
> > Da się pisać w C++ tak, że skompiluje to się jako C.
> 
> Nawet w JavaScripcie da się tak pisać. Np. takie coś:
> 
> function() {
>    return 5;
> }
> 
> > Jeżeli np. zobaczysz taki fragment jak
> >  *ptr++ to równie dobrze może to być C jak C++.
> 
> Jeżeli np. zobaczysz taki fragment jak 2+2 albo f(x) to równie dobrze może to być FORTRAN albo Pascal albo Python albo Lua.
> 
> Więc może można by w ogóle spłaszczyć to całe TIOBE.

Przepraszam, ja tak ogólnie napomknąłem o podobieństwach 'języków 
klamerkowych', odleciałem z kontekstu TIOBE. Nawet nie wiem co to
jest TIOBE, widzę w pośpiechu, że jakieś rankingi języków.

Pozdrawiam

godek.maciek@gmail.com Wrote in message:
> Ściśle rzecz biorąc, kompilator C++ kompiluje C++.

Tak myślisz? Nie. Kompilator C++ musi rozpoznać extern "C" i musi
 kompilować C jeżeli kod źródłowy będzie w C. Zwykle, np. Visual
 Studio, rozpoznaje to po rozszerzeniu, inaczej traktując pliki .c
 i pliki .cpp - chodzi m.i. o "maglowanie".

> Nawet w JavaScripcie da się tak pisać.

Nie. Nie o to chodzi. Ale np. kod Jagged Alliance (klasyka
 turowych gier taktycznych, odświerzona przez fanów) jest napisany
 w C++ - tyle że w zasadzie bez użycia jakichkolwiek " nowinek"
 wprowadzonych tymi ++. Wygląda to tak, jakby ktoś wziął stary kod
 w C i po prostu nie zauważał że jak pliki kończą się na cpp to
 już jest C++. Widząc sam kod źródłowy - niemal nie da się
 zorientować że to nie C++.

 > 2+2 albo f(x) to równie dobrze może to być FORTRAN albo Pascal
 albo Python albo Lua.

Jeżeli miałby to być stary Fortran, to raczej F(X). I raczej nie
 Lisp, Forth lub Haskell.


>Pascal to język programowania, a Delphi to środowisko programistyczne.

Sprawdź jak to określa TIOBE.


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On Saturday, January 25, 2020 at 8:21:40 PM UTC+1, slawek wrote:
> godek.maciek@gmail.com Wrote in message:
> > Ściśle rzecz biorąc, kompilator C++ kompiluje C++.
> 
> Tak myślisz? Nie. Kompilator C++ musi rozpoznać extern "C"

extern "string" określa jedynie "language linkage",
kod jest cały czas kompilowany jako C++:

extern "C" void foo() {
  raise "That's the C++ code";
}

> i musi kompilować C jeżeli kod źródłowy będzie w C.

Gdzie to jest w standardzie C++?

w.

On Friday, January 24, 2020 at 9:01:53 PM UTC+1, Maciej Sobczak wrote:
> > C i C++ to też dwa zupełnie odrębne języki.
> 
> Niezupełnie. Standard języka C++ w pierwszym rozdziale (Scope) stwierdza, że to, co oferuje C++, to jest "in addition" do tego, co oferuje język C.
>
> Podobnie w rozdziale 20, o bibliotece standardowej: "The C++standard library also makes available the facilities of the standard library".
> 
> To jest wystarczająco czytelna i oficjalna deklaracja. Raczej nie da się z tym przepychać tezy, że to są "zupełnie odrębne języki".

"Zupełnie" to faktycznie za mocne.

Tyle że te dodatkowe rzeczy w stosunku do C stanowią 95%
języka C++ i są zupełnie niekompatybilne z protoplastą.
A sam C powoli rozjeżdża się z C++, np. poprzez zmianę
semantyki 'auto' w C++11, usunięcie słowa 'register' w
C++17, czy planowane zmiany w 'volatile' w C++20.

w.

Wojciech Muła <wojtek.mula@gmail.com> Wrote in message:
> A sam C powoli rozjeżdża się z C++, np. poprzez zmianęsemantyki 'auto' w C++11, usunięcie słowa 'register' wC++17, czy planowane zmiany w 'volatile' w C++20.w.


I to właśnie zniechęca do C++. Komitetniki bez przerwy grzebią w
 języku (m.i. dlatego aby udowodnić jak są ważni). W efekcie
 zaczynając duży projekt w 2020 (taki na 5 lat pisania i ponad 20
 lat użytkowania) nie wiadomo w czym się będzie pisać i czy się to
 nie rozleci. Dlatego C wydaje się bardziej "bezpieczne" -
 dzisiejszy kompilator C łyknie nawet K&R.

90% "postępowych modernizacji" to IMO jest zbędna lub wynika z
 prób załatania błędnych fundamentów. W efekcie psuje
 język.

Z dwojga złego wolę C# niż nie-wiadomo-jak-ewolujący C++. 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

Wojciech Muła <wojtek.mula@gmail.com> Wrote in message:
> Kompilator C++ musi rozpoznać extern "C"extern "string" określa jedynie "language linkage"

Owszem, jednak jeżeli to "linkage" odnosi się do czegoś co jest w
 C (np. pliku ncurses.c), to aby zrobić program trzeba te coś
 skompilować jako C a nie C++. I tu ciekawostka, o której pewnie
 nie wiedziałeś: zarówno GCC jak MSVS dają sobie z tym radę
 doskonale.

Osobną sprawą jest że w 90% przypadków można olać extern "C" i
 zmienić .c na .cpp - też przejdzie - choć np. VLA są tyko w
 C-bez-plusów, inaczej jest ze struct-ami itd. Tyle że VLA nadal
 nie ma w MSVSC - no i dobrze.



----Android NewsGroup Reader----
http://usenet.sinaapp.com/

On 1/26/20 12:38 PM, slawek wrote:
> Z dwojga złego wolę C# niż nie-wiadomo-jak-ewolujący C++.

C# jest bardzo "fajny", łatwo się w nim pisze, od razu dostarczona jest 
biblioteka GUI i bardzo dobrze wygląda współpraca z debuggerem.
Ale ma wady:
Potrzebuje dodatkowych bibliotek, róznych wersji np. NET4.6. Są 
trudności z przenośnością, w C/C++ są bardziej przenoścne wersje 
Windows<->Linux, a nawet skompilowane Exe pójdzie pod WinE. Natomiast C# 
przywiązuje jeszcze bardziej do Windows.

On 1/26/20 12:53 PM, slawek wrote:
> Owszem, jednak jeżeli to "linkage" odnosi się do czegoś co jest w
>   C (np. pliku ncurses.c), to aby zrobić program trzeba te coś
>   skompilować jako C a nie C++. I tu ciekawostka, o której pewnie
>   nie wiedziałeś: zarówno GCC jak MSVS dają sobie z tym radę
>   doskonale.

Pliki z rozszerzeniem .c kompilowane są jako C, z .cpp czy .cxx jako 
C++. Natomiast extern "C" może być włączone zarówno do C jak i C++, 
wtedy gdy włączone do C++, będzie kompilowane jako C++ tylko nie będzie 
name manglingu.

Borneq <borneq@antyspam.hidden.pl> Wrote in message:
> On 1/26/20 12:53 PM, slawek wrote:> Owszem, jednak jeżeli to "linkage" odnosi się do czegoś co jest w>   C (np. pliku ncurses.c), to aby zrobić program trzeba te coś>   skompilować jako C a nie C++. I tu ciekawostka, o której pewnie>   nie wiedziałeś: zarówno GCC jak MSVS dają sobie z tym radę>   doskonale.Pliki z rozszerzeniem .c kompilowane są jako C, z .cpp czy .cxx jako C++. Natomiast extern "C" może być włączone zarówno do C jak i C++, wtedy gdy włączone do C++, będzie kompilowane jako C++ tylko nie będzie name manglingu.

W praktyce tak. Jednakże teoretycznie jest to tylko ułatwienie.
 Można mieć kod źródłowy w pliku a.java i skonfigurować to jako do
 kompilacji c++. 
-- 


----Android NewsGroup Reader----
http://usenet.sinaapp.com/