🚀 go-pugleaf

W dniu wtorek, 6 sierpnia 2019 14:02:33 UTC+2 użytkownik Queequeg napisał:
> Pytanie do osób, które programują zawodowo w C lub C++. Której wersji 
> standardu używacie w projektach w pracy?
> 
> Zastanawiam się, czy to specyfika środowiska embedded, ale u nas nadal 
> obowiązuje C++03. "Się nie da" chociażby w C++11, bo używamy starego 
> kompilatora (bo nowego nie wspiera archaiczne środowisko).
> 
> A jak to jest u was (+ jaka branża, tak z grubsza, jeśli to nie 
> tajemnica)?

W branży embedded, jeśli się da (czyli np. na ARMy albo na jakieś linuksy) to korzystam z GCC i wówczas używam rozszerzeń GNU99 (-std=gnu99).

Flagi warningów mam
-Wall -Wconversion -Wno-float-conversion -Wno-sign-conversion -Werror=uninitialized -Werror=implicit-int -Werror=return-type -Werror=conversion

To ważne, bo ani -Wall ani nawet -Wextra w GCC nie wyłapie czegoś takiego:

uint32_t f() {
  return JAKAŚ_DUŻA_WARTOŚĆ;
}

uint16_t x = f();

(co uważam że jest skandaliczne i byłem w szoku jak to odkryłem. Zresztą nadal jestem w szoku)

Jak się nie da, to wtedy zależy co mi obsługuje kompilator (np. kompilator Cosmic dla STM8 ma jakieś tam swoje ograniczenia co do wersji języka C, nawet nie wiem, czy w pełni obsłuży C89; Keil uVision dla 8051 chyba podobnie)

Staram się w pracy utrzymywać kulturę pracy w terminalu uniksowym (MSYS2 albo WSL) z Makefile'ami. Moje doświadczenia w pracy z różnymi "dedykowanymi" środowiskami wykazywały, że choć niektóre rzeczy robi się prościej (np. debugowanie), to dedykowane środowiska stanowią barierę dla rozwoju i przenoszenia projektów na większą skalę. Staram się też dbać o to, żeby cała logika kodu, oprócz tego, że można ją uruchomić na kontrolerach, była też uruchamialna i testowalna na PCtach (i np. jak mam urządzenia, które normalnie komunikowałyby się po kablu albo po radiu, to ten sam kod może się komunikować po gniazdach sieciowych). Na pozór wydaje się, że to więcej pracy, ale w praktyce owo "więcej pracy" zajmuje w moim doświadczeniu o rzędy wielkości mniej czasu, bo mogę łatwo pisać testy automatyczne dla logiki, i takie środowisko do debugowania jest dużo wygodniejsze, niż dotykanie rzeczywistych urządzeń (oczywiście obsługę peryferiów trzeba ręcznie wytestować).

Zaletą jest też to, że w ten sposób powstaje lepsza architektura kodu, bo taka praktyka poniekąd wymusza, żeby oddzielać logikę aplikacji od obsługi peryferiów (widziałem projekty, w których to było ze sobą splecione, i nie polecam).

Od C++ wolę się trzymać z daleka.

On 06.08.2019 14:02, Queequeg wrote:
 > Pytanie do osób, które programują zawodowo w C lub C++. Której wersji
 > standardu używacie w projektach w pracy?

Do lutego 2019:
g++ 4.8.x z Qt 5.9.7, Raspbian na Raspberry Pi 3. Branża: Energetyka.

Obecnie:
C++98 z Qt 4.8.7 na Linux wbudowany na ARM32. Branża: Sprzedaż detaliczna.

On Tue, 06 Aug 2019 12:02:30 +0000, Queequeg wrote:
> Pytanie do osób, które programują zawodowo w C lub C++. Której wersji
> standardu używacie w projektach w pracy?
> ...
> A jak to jest u was (+ jaka branża, tak z grubsza, jeśli to nie
> tajemnica)?

ANSI C (tj. C89).

Branża ta: https://www.expereo.com/resources-product-sheets-whitepaper/


Mateusz

On Tuesday, August 6, 2019 at 2:02:33 PM UTC+2, Queequeg wrote:
> Pytanie do osób, które programują zawodowo w C lub C++. Której wersji 
> standardu używacie w projektach w pracy?
> 
> Zastanawiam się, czy to specyfika środowiska embedded, ale u nas nadal 
> obowiązuje C++03. "Się nie da" chociażby w C++11, bo używamy starego 
> kompilatora (bo nowego nie wspiera archaiczne środowisko).
> 
> A jak to jest u was (+ jaka branża, tak z grubsza, jeśli to nie 
> tajemnica)?
> 
> -- 
> https://www.youtube.com/watch?v=9lSzL1DqQn0

C++17, ale robimy całkowicie niezależne, wewnętrzne
narzędzie związane z sieciami. Z C++20 pewnie
zaczniemy korzystać jak tylko GCC i clang ogłoszą
oficjalne wsparcie.

w.

On Tuesday, August 6, 2019 at 3:05:37 PM UTC+2, Maciek Godek wrote:
> To ważne, bo ani -Wall ani nawet -Wextra w GCC nie wyłapie czegoś takiego:
> 
> uint32_t f() {
>   return JAKAŚ_DUŻA_WARTOŚĆ;
> }
> 
> uint16_t x = f();
> 
> (co uważam że jest skandaliczne i byłem w szoku jak to odkryłem. Zresztą nadal jestem w szoku)

Zgłosiłeś buga w GCC?

> [...]
> Od C++ wolę się trzymać z daleka.

Ciekawostka

--- test.cpp ---
#include <cstdint>
constexpr uint32_t f() { return 0x0fffffff; }
int main() { uint16_t x = f(); }
--- eof ---

$ g++ -std=c++11 test.cpp
test.cpp: In function ‘int main()’:
test.cpp:3:28: warning: conversion from ‘uint32_t’ {aka ‘unsigned int’} to ‘uint16_t’ {aka ‘short unsigned int’} changes value from ‘268435455’ to ‘65535’ [-Woverflow]
     uint16_t x = f();
                  ~^~

w.

Maciek Godek pisze:
> W dniu wtorek, 6 sierpnia 2019 14:02:33 UTC+2 użytkownik Queequeg napisał:
> To ważne, bo ani -Wall ani nawet -Wextra w GCC nie wyłapie czegoś takiego:
> 
> uint32_t f() {
>   return JAKAŚ_DUŻA_WARTOŚĆ;
> }
> 
> uint16_t x = f();
> 
> (co uważam że jest skandaliczne i byłem w szoku jak to odkryłem. Zresztą nadal jestem w szoku)

A to ciekawe, bo bez żadnych opcji gcc zgłasza ostrzeżenie:

gcc -v
------
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)

test.c
------
#include <stdint.h>
uint32_t f() {
         return 0xffffffffffff;
}
int main() {
         uint16_t x = f();
         return 0;
}

gcc -o test test.c
------------------
test.c: In function 'f':
test.c:3: warning: integer constant is too large for 'long' type
test.c:3: warning: large integer implicitly truncated to unsigned type

W dniu niedziela, 11 sierpnia 2019 20:12:34 UTC+2 użytkownik PawelS pawel(at)wbcd(dot)pl napisał:
> Maciek Godek pisze:
> > W dniu wtorek, 6 sierpnia 2019 14:02:33 UTC+2 użytkownik Queequeg napisał:
> > To ważne, bo ani -Wall ani nawet -Wextra w GCC nie wyłapie czegoś takiego:
> > 
> > uint32_t f() {
> >   return JAKAŚ_DUŻA_WARTOŚĆ;
> > }
> > 
> > uint16_t x = f();
> > 
> > (co uważam że jest skandaliczne i byłem w szoku jak to odkryłem. Zresztą nadal jestem w szoku)
> 
> A to ciekawe, bo bez żadnych opcji gcc zgłasza ostrzeżenie:
> 
> gcc -v
> ------
> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
> 
> test.c
> ------
> #include <stdint.h>
> uint32_t f() {
>          return 0xffffffffffff;
> }
> int main() {
>          uint16_t x = f();
>          return 0;
> }
> 
> gcc -o test test.c
> ------------------
> test.c: In function 'f':
> test.c:3: warning: integer constant is too large for 'long' type
> test.c:3: warning: large integer implicitly truncated to unsigned type

W tym przykładzie zgłasza błąd konwersji stałej. Zamiast tego spróbuj np.

#include <stdint.h>
uint32_t f(uint32_t x) {
  return x*x;
}
int main(int argc, char *argv[]) {
         uint16_t x = f(argc);
         return 0;
}

U mnie na telefonie (gcc 6) jest milczenie, choć typ zmiennej ewidentnie się nie zgadza z typem funkcji.
(Dopiero -Wconversion pomaga)

Maciek Godek pisze:
> W dniu niedziela, 11 sierpnia 2019 20:12:34 UTC+2 użytkownik PawelS pawel(at)wbcd(dot)pl napisał:
>> Maciek Godek pisze:
>>> W dniu wtorek, 6 sierpnia 2019 14:02:33 UTC+2 użytkownik Queequeg napisał:
>>> To ważne, bo ani -Wall ani nawet -Wextra w GCC nie wyłapie czegoś takiego:
>>>
>>> uint32_t f() {
>>>   return JAKAŚ_DUŻA_WARTOŚĆ;
>>> }
>>>
>>> uint16_t x = f();
>>>
>>> (co uważam że jest skandaliczne i byłem w szoku jak to odkryłem. Zresztą nadal jestem w szoku)
>> A to ciekawe, bo bez żadnych opcji gcc zgłasza ostrzeżenie:
>>
>> gcc -v
>> ------
>> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
>>
>> test.c
>> ------
>> #include <stdint.h>
>> uint32_t f() {
>>          return 0xffffffffffff;
>> }
>> int main() {
>>          uint16_t x = f();
>>          return 0;
>> }
>>
>> gcc -o test test.c
>> ------------------
>> test.c: In function 'f':
>> test.c:3: warning: integer constant is too large for 'long' type
>> test.c:3: warning: large integer implicitly truncated to unsigned type
> 
> W tym przykładzie zgłasza błąd konwersji stałej. Zamiast tego spróbuj np.
> 
> #include <stdint.h>
> uint32_t f(uint32_t x) {
>   return x*x;
> }
> int main(int argc, char *argv[]) {
>          uint16_t x = f(argc);
>          return 0;
> }
> 
> U mnie na telefonie (gcc 6) jest milczenie, choć typ zmiennej ewidentnie się nie zgadza z typem funkcji.
> (Dopiero -Wconversion pomaga)

gcc -o test test.c
------------------

gcc -o test test.c -Wconversion
-------------------------------
test.c: In function ‘main’:
test.c:6: warning: passing argument 1 of ‘f’ as unsigned due to prototype

> choć typ zmiennej ewidentnie się nie zgadza z typem funkcji.
/usr/include/stdint.h
typedef unsigned int        uint32_t;

Być może powinien tutaj zabrać głos ktoś bardziej kompetentny,
ale "int" od "unsigned int" a różni się tylko znakiem,
także moim zdaniem ewidentna niezgodność typów danych to byłoby:
"double" vs "int", "char *" vs "int", "struct ..." vs "int",

Ten znak to kwestia wyświetlania oraz porównywania wartości,
sam często muszę char rzutować na unsigned char,
aby wartości powyżej 127 nie były wyświetlanie jako 0xffffff..,
przy porównywaniu również będą ciekawe rezultaty.

W dniu wtorek, 13 sierpnia 2019 18:08:20 UTC+2 użytkownik PawelS pawel(at)wbcd(dot)pl napisał:
> Maciek Godek pisze:
> > W dniu niedziela, 11 sierpnia 2019 20:12:34 UTC+2 użytkownik PawelS pawel(at)wbcd(dot)pl napisał:
> >> Maciek Godek pisze:
> >>> W dniu wtorek, 6 sierpnia 2019 14:02:33 UTC+2 użytkownik Queequeg napisał:
> >>> To ważne, bo ani -Wall ani nawet -Wextra w GCC nie wyłapie czegoś takiego:
> >>>
> >>> uint32_t f() {
> >>>   return JAKAŚ_DUŻA_WARTOŚĆ;
> >>> }
> >>>
> >>> uint16_t x = f();
> >>>
> >>> (co uważam że jest skandaliczne i byłem w szoku jak to odkryłem. Zresztą nadal jestem w szoku)
> >> A to ciekawe, bo bez żadnych opcji gcc zgłasza ostrzeżenie:
> >>
> >> gcc -v
> >> ------
> >> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
> >>
> >> test.c
> >> ------
> >> #include <stdint.h>
> >> uint32_t f() {
> >>          return 0xffffffffffff;
> >> }
> >> int main() {
> >>          uint16_t x = f();
> >>          return 0;
> >> }
> >>
> >> gcc -o test test.c
> >> ------------------
> >> test.c: In function 'f':
> >> test.c:3: warning: integer constant is too large for 'long' type
> >> test.c:3: warning: large integer implicitly truncated to unsigned type
> > 
> > W tym przykładzie zgłasza błąd konwersji stałej. Zamiast tego spróbuj np.
> > 
> > #include <stdint.h>
> > uint32_t f(uint32_t x) {
> >   return x*x;
> > }
> > int main(int argc, char *argv[]) {
> >          uint16_t x = f(argc);
> >          return 0;
> > }
> > 
> > U mnie na telefonie (gcc 6) jest milczenie, choć typ zmiennej ewidentnie się nie zgadza z typem funkcji.
> > (Dopiero -Wconversion pomaga)
> 
> gcc -o test test.c
> ------------------
> 
> gcc -o test test.c -Wconversion
> -------------------------------
> test.c: In function ‘main’:
> test.c:6: warning: passing argument 1 of ‘f’ as unsigned due to prototype
> 
> > choć typ zmiennej ewidentnie się nie zgadza z typem funkcji.
> /usr/include/stdint.h
> typedef unsigned int        uint32_t;

Nie o ten fragment mi chodzi, tylko o przypisanie wartości funkcji do zmiennej.

Może wyraźniej to będzie widoczne tutaj:

#include <stdint.h>
uint32_t f(int32_t x) {
    return x*x;
}

int main(int32_t argc, char *argv[]) {
    (void) argv;
    uint16_t x = f(argc);
    return x;
}

Jak kompilujesz z -Wall -Wextra to cisza. Jak dodasz -Wconversion, to masz

x.c: In function ‘f’:
x.c:3:13: warning: conversion to ‘uint32_t {aka unsigned int}’ from ‘int32_t {aka int}’ may change the sign of the result [-Wsign-conversion]
     return x*x;
            ~^~
x.c: In function ‘main’:
x.c:8:18: warning: conversion to ‘uint16_t {aka short unsigned int}’ from ‘uint32_t {aka unsigned int}’ may alter its value [-Wconversion]
     uint16_t x = f(argc);

Chodzi mi o tego drugiego warninga. Brak takich ostrzeżeń powoduje, że bardzo poważne błędy mogą bardzo łatwo umknąć.

> Być może powinien tutaj zabrać głos ktoś bardziej kompetentny,
> ale "int" od "unsigned int" a różni się tylko znakiem,
> także moim zdaniem ewidentna niezgodność typów danych to byłoby:
> "double" vs "int", "char *" vs "int", "struct ..." vs "int",

Mi chodzi raczej o błędy w rodzaju przypisania wartości uint32_t do zmiennej typu uint16_t. Kwestia znaku też bywa istotna, ale kwestia precyzji jest ważniejsza.

Maciek Godek pisze:
> W dniu wtorek, 13 sierpnia 2019 18:08:20 UTC+2 użytkownik PawelS pawel(at)wbcd(dot)pl napisał:
>> Maciek Godek pisze:
>>> W dniu niedziela, 11 sierpnia 2019 20:12:34 UTC+2 użytkownik PawelS pawel(at)wbcd(dot)pl napisał:
>>>> Maciek Godek pisze:
>>>>> W dniu wtorek, 6 sierpnia 2019 14:02:33 UTC+2 użytkownik Queequeg napisał:
>>>>> To ważne, bo ani -Wall ani nawet -Wextra w GCC nie wyłapie czegoś takiego:
>>>>>
>>>>> uint32_t f() {
>>>>>   return JAKAŚ_DUŻA_WARTOŚĆ;
>>>>> }
>>>>>
>>>>> uint16_t x = f();
>>>>>
>>>>> (co uważam że jest skandaliczne i byłem w szoku jak to odkryłem. Zresztą nadal jestem w szoku)
>>>> A to ciekawe, bo bez żadnych opcji gcc zgłasza ostrzeżenie:
>>>>
>>>> gcc -v
>>>> ------
>>>> gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
>>>>
>>>> test.c
>>>> ------
>>>> #include <stdint.h>
>>>> uint32_t f() {
>>>>          return 0xffffffffffff;
>>>> }
>>>> int main() {
>>>>          uint16_t x = f();
>>>>          return 0;
>>>> }
>>>>
>>>> gcc -o test test.c
>>>> ------------------
>>>> test.c: In function 'f':
>>>> test.c:3: warning: integer constant is too large for 'long' type
>>>> test.c:3: warning: large integer implicitly truncated to unsigned type
>>> W tym przykładzie zgłasza błąd konwersji stałej. Zamiast tego spróbuj np.
>>>
>>> #include <stdint.h>
>>> uint32_t f(uint32_t x) {
>>>   return x*x;
>>> }
>>> int main(int argc, char *argv[]) {
>>>          uint16_t x = f(argc);
>>>          return 0;
>>> }
>>>
>>> U mnie na telefonie (gcc 6) jest milczenie, choć typ zmiennej ewidentnie się nie zgadza z typem funkcji.
>>> (Dopiero -Wconversion pomaga)
>> gcc -o test test.c
>> ------------------
>>
>> gcc -o test test.c -Wconversion
>> -------------------------------
>> test.c: In function ‘main’:
>> test.c:6: warning: passing argument 1 of ‘f’ as unsigned due to prototype
>>
>>> choć typ zmiennej ewidentnie się nie zgadza z typem funkcji.
>> /usr/include/stdint.h
>> typedef unsigned int        uint32_t;
> 
> Nie o ten fragment mi chodzi, tylko o przypisanie wartości funkcji do zmiennej.
> 
> Może wyraźniej to będzie widoczne tutaj:
> 
> #include <stdint.h>
> uint32_t f(int32_t x) {
>     return x*x;
> }
> 
> int main(int32_t argc, char *argv[]) {
>     (void) argv;
>     uint16_t x = f(argc);
>     return x;
> }
> 
> Jak kompilujesz z -Wall -Wextra to cisza. Jak dodasz -Wconversion, to masz
> 
> x.c: In function ‘f’:
> x.c:3:13: warning: conversion to ‘uint32_t {aka unsigned int}’ from ‘int32_t {aka int}’ may change the sign of the result [-Wsign-conversion]
>      return x*x;
>             ~^~
> x.c: In function ‘main’:
> x.c:8:18: warning: conversion to ‘uint16_t {aka short unsigned int}’ from ‘uint32_t {aka unsigned int}’ may alter its value [-Wconversion]
>      uint16_t x = f(argc);
> 
> Chodzi mi o tego drugiego warninga. Brak takich ostrzeżeń powoduje, że bardzo poważne błędy mogą bardzo łatwo umknąć.
Prawda. Nie wiem czy do tego zmierzasz, prawdopodobnie tak, że -Wall
to wcale nie włącza wszystkich dostępnych dla gcc opcji -W***

-Wall
All of the above -W options combined.  This enables all the warnings about 
constructions that some users consider questionable, and that are easy to 
avoid (or modify to prevent the warning), even in conjunction with macros. 
This also enables some language-specific warnings described in C++ Dialect 
Options and Objective-C and Objective-C++ Dialect Options.

Zgodnie z man gcc -Wall włącza wszystkie opcje -W*** powyżej -Wall
znajdującego się w man gcc (All of the above -W options combined.).
Być może to celowa niekonsekwencja, aby dla odmiany razem z -Wall
nie dodawano dużej ilości opcji typu: -Wno**** (np: -Wno-long-long).
Stąd wniosek, że trzeba wiedzieć jakie dodatkowe opcje ostrzeżeń
trzeba jeszcze podawać dla gcc przy kompilacji, aby kompilator
zgłaszał takie istotne błędy, zwłaszcza przy konwersji.

W dniu środa, 14 sierpnia 2019 19:24:46 UTC+2 użytkownik PawelS 

> Prawda. Nie wiem czy do tego zmierzasz, prawdopodobnie tak, że -Wall
> to wcale nie włącza wszystkich dostępnych dla gcc opcji -W***

Tak, trzeba przyznać, że już sama nazwa jest myląca, no bo na moją znajomość języka angielskiego "all" oznacza wszystkie.
Ale to jeszcze idzie przełknąć, zwłaszcza jak się wie o fladze -Wextra, która włącza dodatkowe warningi, których -Wall nie włącza.

Tak czy inaczej, zdroworozsądkowe oczekiwanie jest takie, że -Wall pomoże wykryć najpoważniejsze i najbardziej typowe błędy, jakie może popełnić programista.
Tego rodzaju błędem jest przypisanie wartości 32-bitowej do zmiennej 16-bitowej (czy ogólniej, przypisania, w których może dojść do utraty informacji).

Jest to o tyle szokujące, że takie błędy są raczej łatwe do sprawdzenia w językach ze statyczną kontrolą typów, i nie widzę dobrego powodu, żeby nie były zgłaszane nawet gdy ktoś nie kompiluje z -Wall.

Maciek Godek <godek.maciek@gmail.com> wrote:

> Od C++ wolę się trzymać z daleka.

Dlaczego?

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

W dniu piątek, 16 sierpnia 2019 15:04:18 UTC+2 użytkownik Queequeg napisał:

> > Od C++ wolę się trzymać z daleka.
> 
> Dlaczego?

Bo z mojego doświadczenia tworzy więcej problemów, niż rozwiązuje.
Ma tak skomplikowaną składnię, że sami twórcy sobie z nią nie radzą, a mechanizmy abstrakcji są w nim tak skopane, że nie da się w nim tworzyć generycznych rozwiązań.

Żeby nie być gołosłownym, oto przykłady:

W definicji szablonu zapis

s.foo<T>();

może w pewnych okolicznościach spowodować błąd składni, bo symbol "<" zostanie zinterpretowany jako znak mniejszości, i trzeba pisać

s.template foo<T>();

https://en.cppreference.com/w/cpp/language/dependent_name#The_template_disambiguator_for_dependent_names

Klasa std::initializer_list nie ma zdefiniowanego operatora indeksowania. Dlaczego? Bo nikt nie wpadł na to, żeby go dodać.

Inny przykład, z prezentacji Scotta Meyersa na DConfie w 2014 roku
https://www.youtube.com/watch?v=KAWA1DuvCnQ&feature=youtu.be
(fragment między 16:40 a 22:00)

Albo wykwity w rodzaju xvalue reference.

Co do generycznych rozwiązań, napisałem kiedyś na Quorze taką odpowiedź:
https://www.quora.com/What-are-some-examples-of-bad-code/answer/Panicz-Godek

Co prawda tylko przypadkowo dotyczyła C++a, ale początkowo próbowałem stworzyć dobre rozwiązanie w C++. Ostatecznie się poddałem, właśnie ze względu na to, że nie było dla mnie oczywiste, w jaki sposób zaprojektować w C++ generyczny interfejs do algorytmu A*.

(Dla kontrastu, w Haskellu i Schemie było to całkiem oczywiste).

Zadałem do tej pory kilku C++owym fanbojom wyzwanie, żeby spróbowali dostarczyć generyczne rozwiązanie w C++, i do tej pory nikt mu nie podołał.

Generyczność w C również jest ułomna, ale przynajmniej dla tej ułomności można znaleźć jakieś uzasadnienie.

Natomiast pracując w C++ zawsze miałem wrażenie, jakbym - oprócz zmagania się z problemem - musiał dodatkowo ładować energię w zmaganie się z językiem.

Użytkownik "Maciek Godek"  napisał w wiadomości grup 
dyskusyjnych:b5f4eb95-eaf8-42e5-8335-8ca1e576adfc@googlegroups.com...

>Natomiast pracując w C++ zawsze miałem wrażenie, jakbym - oprócz zmagania 
>się z problemem - musiał dodatkowo ładować energię w zmaganie się z 
>językiem.

Kwestia małego doświadczenia. C++ nie jest dla każdego, poza tym dzisiaj to 
faktycznie bardzo (i zupełnie niepotrzebnie) rozbudowany język. Kłopot w 
tym, że jego rozrost jest właśnie odpowiedzią na pretensje różnych osób 
atakujących go "a bo w haskhellu", "a bo w dżawie" i mamy to co mamy. Inne 
języki nie ulegają takim naciskom i jakoś funkcjonują. Dlaczego te naciski w 
C++? Bo wielu go nie lubi właśnie z racji takiej, że nie jest dla każdego. 
Tyle w temacie. 

Użytkownik "Maciek Godek"  napisał w wiadomości grup 
dyskusyjnych:4bcfa95e-aaba-445f-9efe-e9008040fb75@googlegroups.com...

>Jest to o tyle szokujące, że takie błędy są raczej łatwe do sprawdzenia w 
>językach ze statyczną kontrolą typów, i nie widzę dobrego powodu, żeby nie 
>były zgłaszane nawet gdy ktoś nie kompiluje z -Wall.

Ale kojarzysz, że to nie o języku mowa a o konkretnym kompilatorze? 

W dniu sobota, 17 sierpnia 2019 10:36:26 UTC+2 użytkownik test napisał:
> Użytkownik "Maciek Godek"  napisał w wiadomości grup 
> dyskusyjnych:b5f4eb95-eaf8-42e5-8335-8ca1e576adfc@googlegroups.com...
> 
> >Natomiast pracując w C++ zawsze miałem wrażenie, jakbym - oprócz zmagania 
> >się z problemem - musiał dodatkowo ładować energię w zmaganie się z 
> >językiem.
> 
> Kwestia małego doświadczenia.
> C++ nie jest dla każdego, poza tym dzisiaj to 
> faktycznie bardzo (i zupełnie niepotrzebnie) rozbudowany język. Kłopot w 
> tym, że jego rozrost jest właśnie odpowiedzią na pretensje różnych osób 
> atakujących go "a bo w haskhellu", "a bo w dżawie" i mamy to co mamy. Inne 
> języki nie ulegają takim naciskom i jakoś funkcjonują. Dlaczego te naciski w 
> C++? Bo wielu go nie lubi właśnie z racji takiej, że nie jest dla każdego. 
> Tyle w temacie.

W takim razie dlaczego inne języki jakoś stać na to, żeby nie ulegać takim naciskom?

Mnie się raczej zdaje, że C++ nigdy nie miał swojego kręgosłupa. O ile powstanie C było związane od początku z konkretnym celem, o tyle C++ był zawsze mieszaniną randomowych ficzerów (Stroustrup w książce "Język C++" pisał o "sprawianiu mu radości").

Jak ktoś lubi, to pewnie, czemu nie.

Jedna rzecz która jeszcze względnie mi się podoba - ale bardziej jako idea, niż realizacja - to kolekcje STL Stepanova (który nb i tak na początku rozwinął je w Scheme)

Użytkownik "Maciek Godek"  napisał w wiadomości grup 
dyskusyjnych:74798088-e7b3-4aff-8652-922b16c7749b@googlegroups.com...

W dniu sobota, 17 sierpnia 2019 10:36:26 UTC+2 użytkownik test napisał:
> Użytkownik "Maciek Godek"  napisał w wiadomości grup
> dyskusyjnych:b5f4eb95-eaf8-42e5-8335-8ca1e576adfc@googlegroups.com...
>
>> >Natomiast pracując w C++ zawsze miałem wrażenie, jakbym - oprócz 
>> >zmagania
>> >się z problemem - musiał dodatkowo ładować energię w zmaganie się z
>> >językiem.
>
>> Kwestia małego doświadczenia.
>> C++ nie jest dla każdego, poza tym dzisiaj to
>> faktycznie bardzo (i zupełnie niepotrzebnie) rozbudowany język. Kłopot w
>> tym, że jego rozrost jest właśnie odpowiedzią na pretensje różnych osób
>> atakujących go "a bo w haskhellu", "a bo w dżawie" i mamy to co mamy. 
>> Inne
>> języki nie ulegają takim naciskom i jakoś funkcjonują. Dlaczego te 
>> naciski w
>> C++? Bo wielu go nie lubi właśnie z racji takiej, że nie jest dla 
>> każdego.
>> Tyle w temacie.

>W takim razie dlaczego inne języki jakoś stać na to, żeby nie ulegać takim 
>naciskom?

Nie stać. Po prostu takich nacisków nie ma. Komuś się zdaje (np. Tobie), że 
skoro C++ jest uniwersalnym językiem to powinno 
_wszystko_dac_sie_zrobic_dokladnie_tak_jak_w_xxx*_

>Mnie się raczej zdaje, że C++ nigdy nie miał swojego kręgosłupa.

Masz rację, zdaje Ci się.

>O ile powstanie C było związane od początku z konkretnym celem, o tyle C++ 
>był zawsze mieszaniną randomowych ficzerów (Stroustrup w książce "Język 
>C++" pisał o "sprawianiu mu radości").

Taaa, sfrustrowany samiec beta wymyślił sobie, że C++ będzie jego chłopakiem 
do bicia. Tu wysiadam, nie mój poziom "profesjonalizmu" dyskusji.

Bye.

*wpisz dowolny język 

W dniu sobota, 17 sierpnia 2019 12:15:20 UTC+2 użytkownik test napisał:

> Taaa, sfrustrowany samiec beta wymyślił sobie, że C++ będzie jego chłopakiem 
> do bicia. Tu wysiadam, nie mój poziom "profesjonalizmu" dyskusji.

Kolejny powód, dla którego wolę unikać C++, to największe z jakim miałem styczność stężenie fanbojów, którzy nie potrafią przyjąć krytyki.

Maciek Godek pisze:
> W dniu środa, 14 sierpnia 2019 19:24:46 UTC+2 użytkownik PawelS 
> 
>> Prawda. Nie wiem czy do tego zmierzasz, prawdopodobnie tak, że -Wall
>> to wcale nie włącza wszystkich dostępnych dla gcc opcji -W***
> 
> Tak, trzeba przyznać, że już sama nazwa jest myląca, no bo na moją znajomość języka angielskiego "all" oznacza wszystkie.
> Ale to jeszcze idzie przełknąć, zwłaszcza jak się wie o fladze -Wextra, która włącza dodatkowe warningi, których -Wall nie włącza.
Tak jak napisałem, jest to prawdopodobnie celowa nie konsekwencja:
int main() {
	char buffdata[256];
	char buffcopy[256];
	/*unsigned*/ char *sp1, *sp2;
	size_t ss;
	
	
	strncpy(buffdata, "test\"1234\"test", sizeof(buffdata));
	
	if ((sp1=strchr(buffdata,0x22))!=NULL && (sp2=strchr(sp1+1,0x22))!=NULL) {
		ss=sp2-sp1;
		if (sp2-sp1<sizeof(buffcopy)) strncpy(buffcopy, sp1+1, sp2-sp1-1);
		else                          strncpy(buffcopy, sp1+1, sizeof(buffcopy));
		printf("buffcopy=|%s|\n", buffcopy);
	}
	
	return 0;
}

test.c:16: warning: comparison between signed and unsigned
test.c:16: warning: passing argument 3 of '__builtin_strncpy' as unsigned due 
to prototype

Włączenie -Wconversion oznaczałoby często w powyższym przypadku
stosowanie rzutowania (size_t), ewentualnie stosowanie dodatkowej
zmiennej dla obliczania długości ciągu znaków. Co ciekawe
kompilator nie zgłasza tutaj ostrzeżenia konwersji:
ss=sp2-sp1;
a sp1, sp2 (char *) są ze znakiem,
natomiast ss (size_t) jest bez znaku.

Zgodnie z wcześniejszym wynikiem kompilacji:
uint32_t f(int32_t x) {
     return x*x;
}

x.c:3:13: warning: conversion to ‘uint32_t {aka unsigned int}’ from ‘int32_t 
{aka int}’ may change the sign of the result [-Wsign-conversion]
      return x*x;

On Friday, August 16, 2019 at 4:02:16 PM UTC+2, Maciek Godek wrote:
> Żeby nie być gołosłownym, oto przykłady:
> 
> W definicji szablonu zapis
> 
> s.foo<T>();
> 
> może w pewnych okolicznościach spowodować błąd składni, bo symbol "<" zostanie zinterpretowany jako znak mniejszości, i trzeba pisać
> 
> s.template foo<T>();

No OK, składnia związana z szablonami bywa trochę dziwna i czasem
trzeba coś podpowiedzieć kompilatorowi. Jest to jednak problem,
który pojawia się rzadko. Tak, używam templejtów w praktyce.

> Klasa std::initializer_list nie ma zdefiniowanego operatora indeksowania.
> Dlaczego? Bo nikt nie wpadł na to, żeby go dodać.

std::initializer_list fajnie wygląda na slajdach, ja ostatni raz std::initializer_list
użyłem, gdy pisałem implementację std::string. W kodzie produkcyjnym ta klasa ma
zastosowanie zerowe i są głosy, żeby ją wywalić.

> Inny przykład, z prezentacji Scotta Meyersa na DConfie w 2014 roku
> https://www.youtube.com/watch?v=KAWA1DuvCnQ&feature=youtu.be
> (fragment między 16:40 a 22:00)

Ojej, bo taka jest definicja domknięcia w C++... przykład kompletnie
z międzypośladzia.

> Albo wykwity w rodzaju xvalue reference.

O których w codziennej pracy nie ma potrzeby wiedzieć.
Zresztą, w tym zachwalanym C masz jakieś rvalue i lvalue.

> Co do generycznych rozwiązań, napisałem kiedyś na Quorze taką odpowiedź:
> https://www.quora.com/What-are-some-examples-of-bad-code/answer/Panicz-Godek

No proszę Cię, wziąłeś mega chujowy kod (który wygląda jak port z plain C)
i oczekujesz, że w takim ścierwie ktoś stworzył dobre abstrakcje?

> Generyczność w C również jest ułomna, ale przynajmniej dla tej ułomności można znaleźć jakieś uzasadnienie.

Mhm, a ułomności C++ nie mają źródła, siły nadprzyrodzone. :)

> Natomiast pracując w C++ zawsze miałem wrażenie, jakbym - oprócz zmagania się z problemem - musiał dodatkowo ładować energię w zmaganie się z językiem.

Owszem, język jest koślawy i trzeba czasu, żeby dobrać sobie pasujący zestaw
narzędzi. Problemem jest też to, że jego biblioteka standardowa przez długi
czas była cholernie słaba, co spowodowało powstanie dużej liczby
rozwiązań własnych wzajemnie niekompatybilnych.

w.

W dniu poniedziałek, 2 września 2019 19:59:36 UTC+2 użytkownik Wojciech Muła napisał:

> > Klasa std::initializer_list nie ma zdefiniowanego operatora indeksowania.
> > Dlaczego? Bo nikt nie wpadł na to, żeby go dodać.
> 
> std::initializer_list fajnie wygląda na slajdach, ja ostatni raz std::initializer_list
> użyłem, gdy pisałem implementację std::string. W kodzie produkcyjnym ta klasa ma
> zastosowanie zerowe i są głosy, żeby ją wywalić.

W takim razie dlaczego ją dodano?
(Nota bene, to samo słyszałem o std::vector)

> > Inny przykład, z prezentacji Scotta Meyersa na DConfie w 2014 roku
> > https://www.youtube.com/watch?v=KAWA1DuvCnQ&feature=youtu.be
> > (fragment między 16:40 a 22:00)
> 
> Ojej, bo taka jest definicja domknięcia w C++... przykład kompletnie
> z międzypośladzia.

Nie. Przykład jest bardzo konkretny. Że język jest niesystematyczny, bo szanowny komitet zapomniał dodać do gramatyki regułę produkcji dla przypadku, gdy gdzieś tam się pojawia jakieś tam słowo kluczowe.
Z czego można wyciągnąć taki wniosek, że składnia C++ jest nawet zbyt skomplikowana dla osób, które się zajmują standaryzacją języka.

> > Albo wykwity w rodzaju xvalue reference.
> 
> O których w codziennej pracy nie ma potrzeby wiedzieć.

Jasne. Można znaleźć jakiś dowolny minimalny podzbiór C++ który będzie "Turing-complete" i sobie w nim programować. Ale za czym to jest argument?
Jeżeli w języku są rzeczy, które są niepotrzebne, to po co je dodawać?

> Zresztą, w tym zachwalanym C masz jakieś rvalue i lvalue.

Które bardzo łatwo wytłumaczyć.
lvalue - to, co może się znaleźć po lewej stronie operatora przypisania
rvalue - to, co musi się znaleźć po prawej stronie operatora przypisania

Albo można jeszcze powiedzieć "lokacje i wartości".

A w C++ masz kompletną sieczkę, bo ktoś kiedyś wymyślił zupełnie głupi typ o nazwie "referencja", który do siły wyrazu języka nic nie wnosi, i się nagle okazało, że nie można jako argumentów do wywołań funkcji przekazywać literałów.

> > Co do generycznych rozwiązań, napisałem kiedyś na Quorze taką odpowiedź:
> > https://www.quora.com/What-are-some-examples-of-bad-code/answer/Panicz-Godek
> 
> No proszę Cię, wziąłeś mega chujowy kod (który wygląda jak port z plain C)
> i oczekujesz, że w takim ścierwie ktoś stworzył dobre abstrakcje?

Nie. Ja próbowałem to napisać w C++. I nie zdołałem.
Później jak prosiłem różnych zwolenników C++, żeby podali, jeśli nawet nie implementację, to chociaż dobry projekt interfejsu dla algorytmu A* w C++, to nikt do tej pory nie podołał temu zadaniu.

Jeśli masz ochotę się z tym zmierzyć, i stworzyć dobry interfejs do algorytmu A*, to ja się z chęcią z tym zapoznam.

> > Generyczność w C również jest ułomna, ale przynajmniej dla tej ułomności można znaleźć jakieś uzasadnienie.
> 
> Mhm, a ułomności C++ nie mają źródła, siły nadprzyrodzone. :)

Mają oczywiście źródło. Ale nie mają dobrego uzasadnienia.
Język C jest często nazywany przenośnym asemblerem - i można znaleźć języki, które się do C kompilują.
Natomiast nie do końca wiadomo, jaka idea stoi za tym całym C++em. Po prostu zbiór randomowo dodawanych ficzerów. "Obiektowość". "Referencje". "Szablony". "Meta-programy w szablonach". "Automatyczne wnioskowanie o typach". "Perfect forwarding". "Koncepty".
I ja oczywiście nie mam nic przeciwko eksperymentowaniu przy projektach języków programowania. Bardziej mierzi mnie to, jak takie języki eksperymentalne nazywa się "produkcyjnie gotowymi".

> > Natomiast pracując w C++ zawsze miałem wrażenie, jakbym - oprócz zmagania się z problemem - musiał dodatkowo ładować energię w zmaganie się z językiem.
> 
> Owszem, język jest koślawy i trzeba czasu, żeby dobrać sobie pasujący zestaw
> narzędzi. Problemem jest też to, że jego biblioteka standardowa przez długi
> czas była cholernie słaba, co spowodowało powstanie dużej liczby
> rozwiązań własnych wzajemnie niekompatybilnych.

Można też poszukać lepszego języka.
(Albo nawet pozostać przy C)

On 2019-09-02 22:03, Maciek Godek wrote:
> W dniu poniedziałek, 2 września 2019 19:59:36 UTC+2 użytkownik Wojciech Muła napisał:
> 
>>> Klasa std::initializer_list nie ma zdefiniowanego operatora indeksowania.
>>> Dlaczego? Bo nikt nie wpadł na to, żeby go dodać.
>>
>> std::initializer_list fajnie wygląda na slajdach, ja ostatni raz std::initializer_list
>> użyłem, gdy pisałem implementację std::string. W kodzie produkcyjnym ta klasa ma
>> zastosowanie zerowe i są głosy, żeby ją wywalić.
> 
> W takim razie dlaczego ją dodano?
> (Nota bene, to samo słyszałem o std::vector)

Baaaardzo dobrze, ze dodano std::vector.
Mozna by sie obejsc bez std::list, ale bez std::vector absolutnie nie.

AK

W dniu wtorek, 3 września 2019 01:23:58 UTC+2 użytkownik AK napisał:
> On 2019-09-02 22:03, Maciek Godek wrote:
> > W dniu poniedziałek, 2 września 2019 19:59:36 UTC+2 użytkownik Wojciech Muła napisał:
> > 
> >>> Klasa std::initializer_list nie ma zdefiniowanego operatora indeksowania.
> >>> Dlaczego? Bo nikt nie wpadł na to, żeby go dodać.
> >>
> >> std::initializer_list fajnie wygląda na slajdach, ja ostatni raz std::initializer_list
> >> użyłem, gdy pisałem implementację std::string. W kodzie produkcyjnym ta klasa ma
> >> zastosowanie zerowe i są głosy, żeby ją wywalić.
> > 
> > W takim razie dlaczego ją dodano?
> > (Nota bene, to samo słyszałem o std::vector)
> 
> Baaaardzo dobrze, ze dodano std::vector.
> Mozna by sie obejsc bez std::list, ale bez std::vector absolutnie nie.

Jeden gość na Quorze twierdził coś takiego:

https://www.quora.com/What-is-C-used-for-and-what-does-it-mean/answer/Hanno-Behrens-2?__nsrc__=4&__snid3__=4836112599&comment_id=102252354&comment_type=2

Ja przyznam, że nie do końca zrozumiałem, o co mu chodzi.
W ogólności, jego wypowiedzi nie wydawały mi się przesadnie składne.

Ale słyszeć, słyszałem.

Ten gosc w kwestii vectora zwyczajnie bzdurzy.
W kwestii przyczyny niewprowadzenia do C STL-o podobnej
blioteki jeszcze bardziej (ze niby w C zbedna).

Slowem stek fanatycznych bzdur.

AK

W dniu poniedziałek, 2 września 2019 22:03:37 UTC+2 użytkownik Maciek Godek napisał:

> > > Co do generycznych rozwiązań, napisałem kiedyś na Quorze taką odpowiedź:
> > > https://www.quora.com/What-are-some-examples-of-bad-code/answer/Panicz-Godek
> > 
> > No proszę Cię, wziąłeś mega chujowy kod (który wygląda jak port z plain C)
> > i oczekujesz, że w takim ścierwie ktoś stworzył dobre abstrakcje?
> 
> Nie. Ja próbowałem to napisać w C++. I nie zdołałem.
> Później jak prosiłem różnych zwolenników C++, żeby podali, jeśli nawet nie implementację, to chociaż dobry projekt interfejsu dla algorytmu A* w C++, to nikt do tej pory nie podołał temu zadaniu.
> 
> Jeśli masz ochotę się z tym zmierzyć, i stworzyć dobry interfejs do algorytmu A*, to ja się z chęcią z tym zapoznam.

Jakby to kogoś interesowało, to ostatnio nieco usystematyzowałem nieco swój "zbiór wyzwań dla programistów C++":

https://www.quora.com/Is-C++-really-as-hard-as-people-say/answer/Panicz-Godek