Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #29702 > unrolled thread

Oszczędności

Back to article view | Back to pl.comp.programming

Contents

  Oszczędności Sebastian Biały <heby@poczta.onet.pl> - 2017-05-30 22:04 +0200
    Re: Oszczędności niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-31 17:57 +0200
      Re: Oszczędności szykcech@gmail.com - 2017-05-31 21:05 -0700
        Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 09:17 +0200
        Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-01 09:21 +0200
          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-01 10:55 +0200
          Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 16:03 +0200
            Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-01 19:15 +0200
              Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 23:54 +0200
                Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 09:14 +0200
                  Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-02 11:31 +0200
                    Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 12:01 +0200
                      Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 04:05 -0700
                        Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-02 15:54 +0200
                          Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 08:27 -0700
                      Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-02 15:43 +0200
                        Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 20:41 +0200
                          Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-03 11:06 +0200
                            Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 10:14 +0200
                      Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-02 15:44 +0200
                      Re: Oszczędności bartekltg <bartekltg@gmail.com> - 2017-06-02 08:29 -0700
                        Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 08:41 -0700
                          Re: Oszczędności nikt mnie k_rwa nie lubi 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-06-02 18:10 +0200
                          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 18:51 +0200
                            Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 11:53 -0700
                              Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 21:07 +0200
                                Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 12:36 -0700
                                  Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 23:07 +0200
                                    Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-03 00:38 -0700
                                      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 09:55 +0200
                                        Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-07 00:03 -0700
                                    Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 08:32 +0200
                                      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 09:18 +0200
                                        Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 11:00 +0200
                                          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 11:19 +0200
                                            Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 11:38 +0200
                                              Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 12:29 +0200
                                                Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 12:32 +0200
                                                  Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 13:47 +0200
                                                    Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 13:51 +0200
                                                      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 14:08 +0200
                                                        Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 14:28 +0200
                                                          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 15:34 +0200
                                Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-03 10:55 +0200
                                  Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 10:13 +0200
                                    Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 11:03 +0200
                                      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 11:35 +0200
                                        Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 11:42 +0200
                                          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 12:45 +0200
                                            Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 12:57 +0200
                        Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 18:44 +0200
                          Re: Oszczędności bartekltg <bartekltg@gmail.com> - 2017-06-03 03:26 -0700
                            Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-03 14:36 -0700
                              Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 10:11 +0200
                        Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-03 10:52 +0200
              Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 23:55 +0200
                Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 09:18 +0200
          Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 16:17 +0200
            Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-01 19:12 +0200
    Re: Oszczędności Wojciech Muła <wojtek.mula@gmail.com> - 2017-06-01 00:24 -0700
    Re: Oszczędności Zenon Oktawiec <zenon@samm.com.pl> - 2017-06-02 08:53 +0200
      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 09:24 +0200
      Re: Oszczędności Sebastian Biały <heby@poczta.onet.pl> - 2017-06-03 21:14 +0200
      Re: Oszczędności Budzik <budzik61@poczta.o.n.e.t.pl.nie.spam.oj> - 2017-06-04 11:55 +0000
        Re: Oszczędności w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-06-04 14:12 +0200

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#29771

Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał:

>W dniu 2017-06-05 o 13:47, AK pisze:
>> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał:
>>
>>> Ale to chyba Ty nie rozumiesz, takie standardy musi wypracować twórca systemu, a kompilatory 
>>> muszą się do tego dostosować. Dll to kwestia jednego systemu. Jeśli dll będzie wymagał danej 
>>> struktury, to kompilator taką wygeneruje, niezależnie czy będzie to kompilator języka 
>>> c/c++/pascala/asemblera/innego języka kompilowalnego.
>>
>> Nie. Nie wygeneruje. Bo nie musi . Bo standard C++ go nie zmusza.
>
> a co ma zmuszanie standardu, do tego, że wygeneruje? Standard nie zmuszał, by generował 
> jakikolwiek kompilator biblioteki typu .library, a patrz, są takie, które to robią.

A to ma, ze wtedy _jestes pewien_ ze kompillator wygeneruje.
Co do zwyklych bibliotek to byl/jesy ten sam syf.
Kilka formatow (.lib, .a), rozne formaty obj-tow itp
Kiedys linkowanie bylo scislej oddzielone od kompilacji
i to wymuszalo trzymanie sie pewnych zaszlosci/zgodnosc
(np. MS mial jeden linker do wszuytskich jezyow: Pascala, C/C++ i Fortranu,
a Borlandowskiegotlinka uzywalo sie powszechnie do linkowania.. Clippera
bo byl kikanascie razy szybszy od natywnego plinkera,
niktiire porzadne srodowiska mialy wspolne - zwykle Cowe - core bibliotek
np MicroWay NDP (Fortran, Pascal, C/C++) i idealne wzajemne
miedzujezykowe bridges (i to 20 lat przez .NETem).
Potem C++ _olal_ mangling i biblioteki dzielone i poszla dowolnosc juz pelna.
Skutkiem i wszem "rozwoj" nawet w skrajnej forwie net-services/"serwerow aplikacyjnych:)"
konwertujacych  C++ sowy string na javowy i abarot:)
PS: Cale szczescie ze powstal COM/ActiveX a pozneij .NET

>> PS: ...i to ,ma byc nowoczesny jezyk programowania wysokiego poziomu?  ;))
>
> nie wiem, czy ma być, czy nie, bo mnie to rybka, jak go nazwiesz. Ale jeśli generowanie dll-i 
> obiektowych ma byc wyznacznikiem,

Ty dalej nic nie rowumiesz.
Nie mowie o generowaniu dllki tylko o wymogu w standardzie C++
aby kazdy kompilator z nim zgodny zapewnial wsparcie dla uzycia
_standardowych_ rzeczy (glownie stl) w publicznym API dll/so/kazdego rodzaju biblioteki
Tyle (na poczatek:)

AK 

[toc] | [prev] | [next] | [standalone]

#29772

W dniu 2017-06-05 o 14:08, AK pisze:
> 
> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał:
> 
>> W dniu 2017-06-05 o 13:47, AK pisze:
>>> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał:
>>>
>>>> Ale to chyba Ty nie rozumiesz, takie standardy musi wypracować 
>>>> twórca systemu, a kompilatory muszą się do tego dostosować. Dll to 
>>>> kwestia jednego systemu. Jeśli dll będzie wymagał danej struktury, 
>>>> to kompilator taką wygeneruje, niezależnie czy będzie to kompilator 
>>>> języka c/c++/pascala/asemblera/innego języka kompilowalnego.
>>>
>>> Nie. Nie wygeneruje. Bo nie musi . Bo standard C++ go nie zmusza.
>>
>> a co ma zmuszanie standardu, do tego, że wygeneruje? Standard nie 
>> zmuszał, by generował jakikolwiek kompilator biblioteki typu .library, 
>> a patrz, są takie, które to robią.
> 
> A to ma, ze wtedy _jestes pewien_ ze kompillator wygeneruje.
> Co do zwyklych bibliotek to byl/jesy ten sam syf.
> Kilka formatow (.lib, .a), rozne formaty obj-tow itp
> Kiedys linkowanie bylo scislej oddzielone od kompilacji
> i to wymuszalo trzymanie sie pewnych zaszlosci/zgodnosc
> (np. MS mial jeden linker do wszuytskich jezyow: Pascala, C/C++ i Fortranu,
> a Borlandowskiegotlinka uzywalo sie powszechnie do linkowania.. Clippera
> bo byl kikanascie razy szybszy od natywnego plinkera,
> niktiire porzadne srodowiska mialy wspolne - zwykle Cowe - core bibliotek
> np MicroWay NDP (Fortran, Pascal, C/C++) i idealne wzajemne
> miedzujezykowe bridges (i to 20 lat przez .NETem).
> Potem C++ _olal_ mangling i biblioteki dzielone i poszla dowolnosc juz 
> pelna.

No patrz, biblioteki kompilowane kompilatorem sasc nie koniecznie 
chciały współdziałać z tymi kompilowanymi kompilatorem maxona... To, że 
na jednej platformie działało (choć wiem, z doświadczenia, że nie 
działało do końca pomiędzy niektórymi kompilatorami, no, ale przeciez Ty 
wiesz lepiej, bo Tobie się kilka razy to udało), to zupełnie inny przypadek.



>>> PS: ...i to ,ma byc nowoczesny jezyk programowania wysokiego 
>>> poziomu?  ;))
>>
>> nie wiem, czy ma być, czy nie, bo mnie to rybka, jak go nazwiesz. Ale 
>> jeśli generowanie dll-i obiektowych ma byc wyznacznikiem,
> 
> Ty dalej nic nie rowumiesz.
> Nie mowie o generowaniu dllki tylko o wymogu w standardzie C++
> aby kazdy kompilator z nim zgodny zapewnial wsparcie dla uzycia
> _standardowych_ rzeczy (glownie stl) w publicznym API dll/so/kazdego 
> rodzaju biblioteki
> Tyle (na poczatek:)

publiczne api: dll, so, library itp to rzeczy systemowe i to twórcy 
systemu muszą o to zadbać,jeśli tak będzie, będą generowane odpowiednie 
kody przez kompilatory. podchodzenie od tyłka strony spowoduje, że taka 
bibliotekę będziesz mógł użyć tylko w jednym języku, bo twórcy systemu 
zleją takie rzeczy, jeśli nie będą im dawały żadnych bonusów.

-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#29773

Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał:

>> Ty dalej nic nie rowumiesz.
>> Nie mowie o generowaniu dllki tylko o wymogu w standardzie C++
>> aby kazdy kompilator z nim zgodny zapewnial wsparcie dla uzycia
>> _standardowych_ rzeczy (glownie stl) w publicznym API dll/so/kazdego rodzaju biblioteki
>> Tyle (na poczatek:)
>
> publiczne api: dll, so, library itp to rzeczy systemowe

Zle Wasc prawisz.
W tym publicznym API sa nazwy ktore nadaje sobie dowolnie kompilator.
Te nazwy sa nieustandaryzowane (brak usstandaryzowania mainglingu w C++) - to raz
ta nazwy tycza metod i "zmiennych" dostepnych poprzez to API.
Te metody i atrybuty sluza do "dobrania" sie do ich adresow po aladowaniu dll-ki
(innym sposobem - szybszym, ale mniej "flexible" - jest dobieranie sie przez ordinal number).
W poruszanym problemie chodzi o to ze kompilator  generuje _calkiem inne_ instancje
tempaltes dla przypadku.

class A
{
public:
std::list sequence;
};

niz dla:

class A
{
public:
declspec(export) std::list sequence;
};

i linkerowi brakuje implementacji w bibliotece kompilatora.
Standard C++ powinien nie tyle nawet zalecic, ale _wymusic_ na kompilatorze
dostarczenie implementacji stl/std:: _rowniez_ dla bibliotek dzielonych.

To o czym Wasc prawisz to ABI, ktore faktycznie jest tworem os/systemowym
(ale i tak dosc glekoko "zanurzonym" w czystym C, choc na Win jest to akurat
 bardziej Pascalowaty twor:).

PS: Poza tym zwykle/statyczne libraries to niekoniecznie rzeczy systemowe,
      ale jak najbardziej rowniez kompilatorowe.

AK

[toc] | [prev] | [next] | [standalone]

#29746

On Fri, 2 Jun 2017 21:07:38 +0200, "AK" <nobody@nowhere.net> wrote:
> Probowals to robic ? Da sie uzyc/zlinkowac dll-ke majaca w swym API
> uzycie standardowego kontenera STL ?

Da się. Rzutowaniem i warperem.

[toc] | [prev] | [next] | [standalone]

#29757

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> On Fri, 2 Jun 2017 21:07:38 +0200, "AK" <nobody@nowhere.net> wrote:
>> Probowals to robic ? Da sie uzyc/zlinkowac dll-ke majaca w swym API
>> uzycie standardowego kontenera STL ?
>
> Da się. Rzutowaniem i warperem.

Owszem. Tylko, ze ten wrapper to nie banal i wcale nie daje
gwarancji "na przyszlosc".

AK

[toc] | [prev] | [next] | [standalone]

#29760

W dniu 2017-06-05 o 10:13, AK pisze:
> Użytkownik "slawek" <fake@fakeemail.com> napisał:
> 
>> On Fri, 2 Jun 2017 21:07:38 +0200, "AK" <nobody@nowhere.net> wrote:
>>> Probowals to robic ? Da sie uzyc/zlinkowac dll-ke majaca w swym API
>>> uzycie standardowego kontenera STL ?
>>
>> Da się. Rzutowaniem i warperem.
> 
> Owszem. Tylko, ze ten wrapper to nie banal i wcale nie daje
> gwarancji "na przyszlosc".

A co daje ci jakiekolwiek gwarancje "na przyszłość"?
-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#29762

Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał:

>> Owszem. Tylko, ze ten wrapper to nie banal i wcale nie daje
>> gwarancji "na przyszlosc".
>
> A co daje ci jakiekolwiek gwarancje "na przyszłość"?

Zgodnosc ze standardem.
Wtedy to tworcy kompilatorow sa zmuszeni do dbania o
backward compatibility, a nie programista.

AK

[toc] | [prev] | [next] | [standalone]

#29764

W dniu 2017-06-05 o 11:35, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał:
> 
>>> Owszem. Tylko, ze ten wrapper to nie banal i wcale nie daje
>>> gwarancji "na przyszlosc".
>>
>> A co daje ci jakiekolwiek gwarancje "na przyszłość"?
> 
> Zgodnosc ze standardem.
> Wtedy to tworcy kompilatorow sa zmuszeni do dbania o
> backward compatibility, a nie programista.

tia.... widać to w wielu językach, jak właśnie czegos podobnego brakuje. 
W zasadzie wbrew pozorom, to najwięcej zgodności jest właśnie w C i C++, 
a to pewnie dzięki temu, że starają cię mieć pewne normy. Języki 
zmieniają się wolniej, bo normy muszą być wypracowane ect, ale są.

-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#29767

Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał:

>> Zgodnosc ze standardem.
>> Wtedy to tworcy kompilatorow sa zmuszeni do dbania o
>> backward compatibility, a nie programista.
>
> tia.... widać to w wielu językach, jak właśnie czegos podobnego brakuje.

Widac, raz mniej raz wiecej.
np. w Javie super - kopiuje jary i chodzi
np. w Pythonie nienajgorzej (choc gorzej niz w Javie), jednak pelne ABI wciaz w marzeniach.
np. W .NET super. Kopiuje z Win->*nix exe-ki i dll-ki (oczywiscie w srodku bytecode)
i chodzi/dziala
W "zwyklym C++" pomarzyc. A przeciez mozna by....
Takie MS VC z 90tych lat mialo opcje "bytecode generate", a tak wygenerowany
zwykly exe-k byl zaledwie ~15% wolniejszy od "processor code".
A przeciez mozna by to dzis jeszcze ulepszyc (jit-y czy techniki rodem z JS v8).

> W zasadzie wbrew pozorom, to najwięcej zgodności jest właśnie w C i C++,

Wbrew pozorom to piszac to dajesz przyklad, ze C/C++ znasz tylko z ksiazek i Internetu.

C/C++ jest wciaz dzis jednym z najbardziej uciazliwych jezykow w sensie portability.
(Jestem skrajnym wieloplatformowcem :) - od 1992 roku wlasciwie kazdy system w ktorym
bralem udzial byl full porable na : Win, Linux, Solaris, HP-UX .
Dobrze radze nie "wyzywac mnie na pojedynek" w tym temacie bo mozna byc
"zjedzonym na sniadanie" ;)

AK

[toc] | [prev] | [next] | [standalone]

#29768

W dniu 2017-06-05 o 12:45, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.onet.pl> napisał:
> 
>>> Zgodnosc ze standardem.
>>> Wtedy to tworcy kompilatorow sa zmuszeni do dbania o
>>> backward compatibility, a nie programista.
>>
>> tia.... widać to w wielu językach, jak właśnie czegos podobnego brakuje.
> 
> Widac, raz mniej raz wiecej.
> np. w Javie super - kopiuje jary i chodzi
> np. w Pythonie nienajgorzej (choc gorzej niz w Javie), jednak pelne ABI 
> wciaz w marzeniach.
> np. W .NET super. Kopiuje z Win->*nix exe-ki i dll-ki (oczywiscie w 
> srodku bytecode)

Dawno nie próbowałem, ale na platformach z innym endianem nie działało....


> i chodzi/dziala
> W "zwyklym C++" pomarzyc. A przeciez mozna by....
> Takie MS VC z 90tych lat mialo opcje "bytecode generate", a tak 
> wygenerowany
> zwykly exe-k byl zaledwie ~15% wolniejszy od "processor code".
> A przeciez mozna by to dzis jeszcze ulepszyc (jit-y czy techniki rodem z 
> JS v8).

tia i pochłania kilka razy tyle pamięci.


>> W zasadzie wbrew pozorom, to najwięcej zgodności jest właśnie w C i C++,
> 
> Wbrew pozorom to piszac to dajesz przyklad, ze C/C++ znasz tylko z 
> ksiazek i Internetu.
> 
> C/C++ jest wciaz dzis jednym z najbardziej uciazliwych jezykow w sensie 
> portability.
> (Jestem skrajnym wieloplatformowcem :) - od 1992 roku wlasciwie kazdy 
> system w ktorym
> bralem udzial byl full porable na : Win, Linux, Solaris, HP-UX .
> Dobrze radze nie "wyzywac mnie na pojedynek" w tym temacie bo mozna byc
> "zjedzonym na sniadanie" ;)


też jestem wieloplatformowcem, i często przenoszę kod na bardziej dziwne 
platformy niż windows np: uclinux, rtos, morphos... jakoś aplikacje js 8 
na tym nie chca działać, dodatkowo często różna endianowość też nie 
ułatwia, nawet na linuksie z procesorem z innym endianem juz jest 
inaczej (nie pisze tu o javie jeśli chodzi o endianowość, żeby nie 
było). Ale pewnie to wiesz, skoroś tak wyedukowany

-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#29730

Użytkownik "bartekltg" <bartekltg@gmail.com> napisał:

On Friday, June 2, 2017 at 12:01:15 PM UTC+2, AK wrote:
> Użytkownik "slawek" <fake@fakeemail.com> napisał:

> Niskopoziomowo nalezy pisac dopiero wtedy gdy wszytsko inne zawiedzie, gdyz po prostu i zwyczajnie
> jezyki niskopoziomowe (tak tak, w tym C i C++) sa wielokrotnie bardziej

> Co jest niskopoziomowego w c++?

Caly podset czyli C a w nim m.in..
- chory preprocesor zamiast normalnych modulow (a mozna bylo!, patrz C2)
- chore wskazniki i arytmetyke na nich  (juz w Silmuli67 byly porzadne
   referencje i one starczaly az nadto).
- brak chociazby reflleksji (ze juz o first-class nie wspomne)
  co skutkuje statycznoscia wrappingu (nie do obejscia, trzeba generowac
   naglowki itp)
- dynamiczny przydzial (a i statyczny) na poziomoe kamienia lupanego
  (w takiej Simuli dalo sie np.spokojnie napisac:
    begin
    integer array a [expr1:expr2, expr3:expr4])
- brak do dzis (mimo wielu standardow i kilku niezaleznych implementacji
   Borland i MS) np. jakze przydatnych "properties".
- chore (bo "z boku jezyka") kontenery (STL) skutkujace niewspieraniem ich
   przez for (nie ma prawdziwego/normalnego np. foreach), ze juz o pofdejsciu takim
   jak np. w Pythonie (comprehensions) nie wspomne.
- na ustandaryzowanie obslugi watkow trzeba bylo czekac 25 lat :)
   /w koncu i tak wybrali pthread-y:)/
- na ustandaryzowanie smart pointerow trzeba bylo czekac 20 lat :)
   /w koncu i tak wybrali boostowe:)/
- itp itd, mozna by tak do rana..

> C++ daje dostęp do bebechów i przez to daje się tam pisać jak
> w przenośnym assemblerze zwanym C (za co powinni bić linijką po rękach)

C jest bardzo dobry w swej roli (wlasniue przenosnego assemblera)
Upchanie go do C++ bylo zupelnie niepotrzebne (a raczej bylo duzym bledem).
Wystarczylaby w pelni lacznosc z C na poziomie linkera.

> ale sam w sobie jest zdecydowanie językiem wysokiego poziomu.

Tak ?
Moze wtedy gdy pisze sie wylacznie w oparciu np o Qt a nie w "normalnym"
standardowym C++ :)
Ba! Sam autor nie uwaza C++ za jezyk wysokiego poziomu.
Jest to jezyk hybrydowy a elementami obiektowosci przeznaczony
do zastosowan systemowych. Koniec kropka.

Dinozaur

[toc] | [prev] | [next] | [standalone]

#29748

On Friday, June 2, 2017 at 6:44:55 PM UTC+2, AK wrote:
> Użytkownik "bartekltg" <bartekltg@gmail.com> napisał:
> 
> On Friday, June 2, 2017 at 12:01:15 PM UTC+2, AK wrote:
> > Użytkownik "slawek" <fake@fakeemail.com> napisał:
> 
> > Niskopoziomowo nalezy pisac dopiero wtedy gdy wszytsko inne zawiedzie, gdyz po prostu i zwyczajnie
> > jezyki niskopoziomowe (tak tak, w tym C i C++) sa wielokrotnie bardziej
> 
> > Co jest niskopoziomowego w c++?
> 
> Caly podset czyli C a w nim m.in..

Wymieniasz tu niskopoziomowe elementy. O wysokopozimowości
języka świadczy istnienie 

> - chore wskazniki i arytmetyke na nich  (juz w Silmuli67 byly porzadne
>    referencje i one starczaly az nadto).

To jest narzędzie którego nie używa się we wspolczesnym c++ poza
spacjalizowanym kodem bibliotecznym. 

> - brak chociazby reflleksji (ze juz o first-class nie 
Prawda, uciązliwe. 

> - dynamiczny przydzial (a i statyczny) na poziomoe kamienia lupanego

Nic nie rozumiem. 

> - brak do dzis (mimo wielu standardow i kilku niezaleznych implementacji
>    Borland i MS) np. jakze przydatnych "properties".

To lukier syntktyczny na get/set znany z pascala. Do szczęscia naprawde
niepotrzebny, a są i głosy, że prowadzi do błędów. Spodziewasz się dostępu 
do zmiennej, a tu nagle jest modyfikowany stan obiektu. 
Niewiele ma to wspolnego z wysokopoziomowością.


> - chore (bo "z boku jezyka") kontenery (STL) skutkujace niewspieraniem ich

To jest właśnie jedno z największych osiągnieć wysokopoziomowości c++.
odcięcie jęsyka od standardowych struktur danych. Twoja struktura (cz z boosta)
jest równie dobra co z STL. I możesz ją zrobić równoie wydają (i rownei wydajną
co gole tablice). Bardzo ciezkie do osiągnięcia w innych językach. 

>    przez for (nie ma prawdziwego/normalnego np. foreach), ze juz o pofdejsciu takim

foreach w ramach stl było od dawna. 

BTW, chyba dyskutujesz o c++ z epoki kamienia łupanego, bo od lat mamy

for (auto &v: kontener){
....
}

Nie głupio ropzmawiać o jezyku, którego się nie zna?


>    jak np. w Pythonie (comprehensions) nie wspomne.
> - na ustandaryzowanie obslugi watkow trzeba bylo czekac 25 lat :)
>    /w koncu i tak wybrali pthread-y:)/
> - na ustandaryzowanie smart pointerow trzeba bylo czekac 20 lat :)

I jak to ma się do tematu?
Przypomnę, pytam o uzasadnienie twierdzenia, że c++ to język niskopoziomowy,
a ty mi wymieniasz powody, dlaczego 10 lat temu go nie lubiłeś. 

> > C++ daje dostęp do bebechów i przez to daje się tam pisać jak
> > w przenośnym assemblerze zwanym C (za co powinni bić linijką po rękach)
> 
> C jest bardzo dobry w swej roli (wlasniue przenosnego assemblera)
> Upchanie go do C++ bylo zupelnie niepotrzebne (a raczej bylo duzym bledem).
> Wystarczylaby w pelni lacznosc z C na poziomie linkera.

Przepraszam, jaja sobie robisz?



> > ale sam w sobie jest zdecydowanie językiem wysokiego poziomu.
> 
> Tak ?
> Moze wtedy gdy pisze sie wylacznie w oparciu np o Qt a nie w "normalnym"
> standardowym C++ :)
> Ba! Sam autor nie uwaza C++ za jezyk wysokiego poziomu.
> Jest to jezyk hybrydowy a elementami obiektowosci przeznaczony
> do zastosowan systemowych. 

Czyli nie jest językiem niskopoziomowym. 

> Koniec, Kropka.

:)

pzdr
bartekltg

[toc] | [prev] | [next] | [standalone]

#29750

On Saturday, June 3, 2017 at 12:26:15 PM UTC+2, bartekltg wrote:
> > - brak chociazby reflleksji (ze juz o first-class nie 
> Prawda, uciązliwe. 
Jeśli ktoś wychowany na Javie, napisze program spodziewając się, że
za kilkaset linijek coś napisze wykorzystując refleksje, to owszem
brak refleksji będzie uciążliwy. Jeśli od razu rozwiąże problem 
inaczej, to nie będzie zbyt uciążliwe.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#29756

Użytkownik "M.M." <mmarszik@gmail.com> napisał:

> Jeśli ktoś wychowany na Javie, napisze program spodziewając się, że
> za kilkaset linijek coś napisze wykorzystując refleksje, to owszem
> brak refleksji będzie uciążliwy. Jeśli od razu rozwiąże problem
> inaczej, to nie będzie zbyt uciążliwe.

Nie o to chodzi (generalnie jestem przeciwnikiem uzywania mechnizmow
refleksji jezyka prog. w nim samym - oczywiscie poza uzasadnionymi
miejscami faktycznie wymagajacymi podejscia "dynamicznego").

Refleksja/first-class/dynamizm jest szczegolnie przydatna przy
"otwieraniu" jezyka na inne srodowiska/jezyki programowania
(brigdes, wrapping, multilanguage/multiplatform APIs itp).

C++ jest tu jednym z najpaskudniejszych jezykow.
Nawet C jest wiele lepsze niz C++.
Prawie idealna jest Java (JNI) - prawie bo JNA powinno byc IMHO od dawna w standardzie/instalce 
Javy.
Stary Fortran jest w tym obszarze lepszy od C++.
Idealny ject C#/.NET.

AK

[toc] | [prev] | [next] | [standalone]

#29745

On Fri, 2 Jun 2017 08:29:29 -0700 (PDT), bartekltg 
<bartekltg@gmail.com> wrote:
> w przenośnym assemblerze zwanym C (za co powinni bić linijką=
>  po rękach)

Sam się zdziwiłem: w C bez plusów daje się pisać wysokopoziomowo. A 
nawet obiektowo (z dziedziczeniem, polimorfizmem itd.)

Tyle że przypomina to granie IX Symfonii na pile do drewna.

[toc] | [prev] | [next] | [standalone]

#29715

On Thu, 1 Jun 2017 19:15:39 +0200, "AK" <nobody@nowhere.net> wrote:
> Phi! Kazda małpa tak powie.

Często słyszysz małpy w swojej głowie?!

[toc] | [prev] | [next] | [standalone]

#29718

Użytkownik "slawek" <fake@fakeemail.com> napisał w wiadomości 
news:almarsoft.5406384613711976466@news.v.pl...
> On Thu, 1 Jun 2017 19:15:39 +0200, "AK" <nobody@nowhere.net> wrote:
>> Phi! Kazda małpa tak powie.
>
> Często słyszysz małpy w swojej głowie?!

Nie, gdyz bardzo rzadko mysle o Tobie (szanuję swoj czas, a nie mam cienia szacunku dla ludzi 
oklamujacych
innych/mlodych/mniej doswiadczonych - niewazne czy robia to intencjonalnie, czy wierza (sic!) w to 
co mowia).

Dinozaur

[toc] | [prev] | [next] | [standalone]

#29711

On Thu, 1 Jun 2017 09:21:50 +0200, "AK" <nobody@nowhere.net> wrote:
> PS: Właśnie sobie próbuję przypomnieć kiedy ostatnio potrzebna mi 
była znajomość
> systemu dwójkowego/notacji uzupełnieniowej do 2/ONP itp. Hm...

A mi się przydała jakieś parę tygodni temu: algorytm się uprościł po 
zapisaniu czegoś tam w systemie trójkowym. Ale oczywiście przy 
pisaniu bazy danych magazynu szlauchów i kaloszy to zbędne, ;)

[toc] | [prev] | [next] | [standalone]

#29712

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> A mi się przydała jakieś parę tygodni temu: algorytm się uprościł po zapisaniu czegoś tam w 
> systemie trójkowym. Ale oczywiście przy pisaniu bazy danych magazynu szlauchów i kaloszy to 
> zbędne, ;)

Wspołczuję Ci (Norek?). Mnie sie niezwykle rzadko przydaje, choc
 nigdy nie dotknalem informatyki "kanalizacyjnej".

Dinozaur

[toc] | [prev] | [next] | [standalone]

#29708

On Tuesday, May 30, 2017 at 10:04:34 PM UTC+2, Sebastian Biały wrote:
> Takie info:
> 
> http://next.gazeta.pl/next/7,151003,21884996,milionowe-straty-polskiej-spolki-przez-bledy-w-systemie-wysylala.html#BoxBizImg
> 
> Ktos wie kto jest za ten bałagan odpowiedzialny? Pytam z nadzieja że 
> kilku abitniejszych programistów w przyszłości nie trafi do firmy 
> odpowiedzialnej za takie dziadostwo. Może warto żeby ślad pozostał jak w 
> przypadku Nabino.

Zdawkowy opis tego problemu, właściwie tylko skutki. Ciekawsza
byłyby analiza źródeł błędów, szczególnie, że system miał przejść
testy wewnętrzne. Tak to jest zgadywanka.

w.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | pl.comp.programming

csiph-web