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

do góry

Użytkownik Zenon Oktawiec z...@s...com.pl ...

> Przecież wyraźnie w tekście stoi, że tu niczego nie pisano, tylko
> wdrażali SAP'a. Problem jest więc jest pozainformatyczny - ewidentnie
> zawinił "manadżment". Konsultanci SAP'a trochę kosztują - pewnie ktoś
> się chciał wykazać jakimiś tam oszczędnościami.
> IMHO - temat nie na tą grupę.

Ponoc Kompania Piwowarska tez wpadła w powazne problemy informatyczno-
finansowe jak zaczeli SAPa wdrażać.
Wychodzi na to ze ten SAPowy mercedes jest problemem sam w sobie...

--
Pozdrawia... Budzik
b_ud_zi_k_6_1 na poczta kropka onet kropka pl (adres antyspamowy, usuń także "_")
Unix jest gorszy od W98 z tego prostego powodu, że W98 mam
na swoim domowym komputerze, a Unixa nie i nie zamierzam.

do góry

a dobrze im radzili - silverlight!

do góry

W dniu 2017-06-02 o 23:07, AK pisze:
> Użytkownik "M.M." <m...@g...com> napisał:
> On Friday, June 2, 2017 at 9:07:46 PM UTC+2, AK wrote:
>> Użytkownik "M.M." <m...@g...com> napisał:
>
>> Chyba nie w tym dopatrujesz się
>> problemu (bo po co?), że to się dzieje na poziomie bibliotek/systemu, a
>> nie w ramach standardu C++?
>
> Kurde... Nawet ostatni standard tego "wysokopoziomowego" C++
> nie "przewidzial:" czegos takiego jak biblioteki dynamiczne/dzielone
> (mimo ze istnieja juz >30 lat).
> Skutek jest taki, ze nigdzie nie znajdziesz nie tylko unormowanego
> manglingu nazw, ale tez zapewnienia "przrezroczystosci" m.in. kontenerow
> standardowych (czyki STL). Bezpiecznie moga byc przekazywane
> tylko typy proste i surowe pointery (lub pochodne tychze typow, czyli
> wlasciwie typu
> rodem z C). Skutek jest taki ,ze kazdy kompilator dziala z STLem w tym
> obszarze po swojemu
> a czasem/czesto nie dopuszcza/daje bledy linkera itp skutek zlego (bez
> modyfikatora
> dll-export ) generowania templates.
> Skutek finalny jest taki, ze po prostu _NIE WOLNO_ uzywac typow
> stl-owych w API dll-ki
> i to, ze jedne kompilatory to dopuszczaja (gcc) nie stanowi żadnej
> gwarancji
> poprawnosci/portability (bo liczy sie raport jezyka a nie "probkowanie"
> kompilatorow).
> Po prostu templates z atrybutem dll-export sa _inne_ niz bez niego i
> linker glupieje.
> Czyli mamy standard (STL), ale... nie mozemy go uzyc w jakze "rzadkiej"
> sytuacji
> (API dll-ek:).
> To wciaz tyczy tego samego kompilatora dla dllki i programu glownego.
> Jesli kompilatory sa rozne (a to przeciez czesta/normalna sytuacja) to
> juz zaczyna
> sie prawdziwa dzungla (nawet dla dinozaurow nie do przebycia).
>
> Dlatego wole .NET czy Jave gdzie sa normalne moduly gwarantujace normalne
> API a nie "wysokopoziompowy" w tym wzgledzie C++.


Trochę bez sensu. Czemu C++ miałoby mieć jakieś konkretne wytyczne do
tworzenia dll-ek, skoro one sa związane z jednym konkretnym systemem.
Systemów operacyjnych jest więcej na świecie i one mogą w różny sposób
definiować dostęp do bibliotek współdzielonych. Więc takie porównanie
jest bez sensu... .Net natomiast podobnie jak java mają swoje środowisko
uruchomieniowe niezależne od systemu, co czasami pomaga, a czasami
denerwuje. W zalezności od zastosowania.

--
http://kaczus.ppa.pl

do góry

Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:

> Trochę bez sensu. Czemu C++ miałoby mieć jakieś konkretne wytyczne do tworzenia
dll-ek, skoro one
> sa związane z jednym konkretnym systemem. Systemów operacyjnych jest więcej na
świecie i one mogą
> w różny sposób definiować dostęp do bibliotek współdzielonych.

Dokladnie po to, aby ta "dowolnosc" ustandaryzowac i tym samym
uczynic kod przenosnym i nie majacym bzdurnych ograniczen
(zabronione uzycie standardowego jakby nie bylo STLa w APIs
bibliotek dzielonych).

> Więc takie porównanie jest bez sensu...

Otoz nie. Ma _gleboki_ praktyczny sens.
Ominiecie tego problemu w "wysokopoziomowym" C++
wymaga (ze tak to nazwe specjalistycznej "wiedzy" - cudzuslow
zamierzony bo to kolejny syf/smiec w pamieci niz prawdziwa wiedza)
i zejscia na maksynalnie niski poziom - nawet linkera (czyli
"wysokopoziomowosc" C++ idzie sie zwyczajnie pasc.

AK

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Czy są z tym aż takie problemy? Skoro piszesz że są, to wierzę na słowo.

Sa sa. Uzywajac VC++.
Ale to nie jest wina MSa. VC++ nie lamie standardu C++.
To wina "niedostrzegania" przez lata tego problemu/nieustandaryzowania
sprawy przez szacowny komitet do spraw "rozwoju" C++.

PS: Opisze Ci/podam przyklad i obejscie. Moze Ci/komus sie przyda
(oby nie musial:).

PS1: Dla tych co zaraz napisza, ze problem jest blachy, wydumany,
niepraktyczny itd. itp, a C++ wspanialy bo tak !:).

Istnieje sobie lata/a moze i dziesiatki lat wysoce ustandaryzowane
(i uzywane w setkach miejsc) API podstawowego lib-a systemu
w ktorym nagminnie i nowoczesnie korzysta sie z STL miast
chorych wskaznikow char *str itp (i bardzo dobrze).
W pewnym momencie z roznych wzgledow konieczne jest zmiana
statycznego liba (*.lib) na dzielony (*.dll).
Warunek podstawowy wydaje sie oczywisty:
jakakolwiek zmiana dotychczasowego API/naglowkow (*.h*)
jest niedopuszczalna.
Generalnie sprawa wydaje sie prosta i bezproblemowa, a tu...
W najnowoczesniejszym z mozliwych SCRUMie wszyscy
wyciagneli w gore karty: 2 dni, 4 dni, ktos dal tydzien, i tylko
jakis chory stary grzyb wyciagnal karte z napisem 60 dni .
Oczywiscie zostalo to wykpione, wspomniano nawet o dr Alzheimerze
itp (ot Mlodzi Wyksztalceni z Duzych Miast:).
Ostatecznie Temida (Pani Rzeczywistosc) po jakims czasie (napewno
dluzszym niz wspomnany tydzien:) oddala jednak problem w rece tego
grzyba i fakt ze zajelo mu to ok tygodnia, ale podstawowe zalozenie
zostalo zachowane (oczywiscie przy zlamaniu zasady ze w publicznym
API dll-ki nie moze byc uzyty zaden kontener C++owego STLa).
Nie musze dodawac, ze musiala byc zachowana scisle
backward compatibility nie tylko APIs, ale i background-u
(nie mozna bylo zmienic kompilatorow i innych bibliotek na nowsze
wersje itd itp. W ogole prawie niczego nie wolno bylo "ruszyc").
Nie obylo sie takze bez pewnych restrykcji w tym publicznym API
(np. bylo konieczne wymuszenie i uzywania w nim std::vector zamiast
std::list). Na szczescie w tym konkretnym przypadku zmiany byly
na tyle male, ze mozliwe do wykrycia uzycia/przeprowadzenia w tych
setkach miejsc kompilacji.

AK

do góry

Użytkownik "M.M." <m...@g...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

do góry

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

> On Fri, 2 Jun 2017 21:07:38 +0200, "AK" <n...@n...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

do góry

Użytkownik "slawek" <f...@f...com> napisał:
> On Fri, 2 Jun 2017 20:41:01 +0200, "AK" <n...@n...net> wrote:
>> Nie pisz o czyms czego nie dotknales (daaaawane czasy: Odra 1305).
>
> 1.1 DEMAND N AS "NUMBER"
>
> I nie Odra, ale CDC 6000.
>
> rotfl

A wlasnie ze Odra (24bits a nie chore 9:)

AK

do góry

W dniu 2017-06-05 o 09:18, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>
>> Trochę bez sensu. Czemu C++ miałoby mieć jakieś konkretne wytyczne do
>> tworzenia dll-ek, skoro one sa związane z jednym konkretnym systemem.
>> Systemów operacyjnych jest więcej na świecie i one mogą w różny sposób
>> definiować dostęp do bibliotek współdzielonych.
>
> Dokladnie po to, aby ta "dowolnosc" ustandaryzowac i tym samym
> uczynic kod przenosnym i nie majacym bzdurnych ograniczen
> (zabronione uzycie standardowego jakby nie bylo STLa w APIs
> bibliotek dzielonych).

Ale jakie zabronienie. Mylisz 2 pojęcia. DLL to część systemu, tak jak
.library, czy .so Jak to ustandaryzować, nakazać twórcom systemów
korzystanie z takich a nie innych rzeczy? Przecież to bez sensu.
Robienie z C++ coś na modłę javy, dla mnie też bez sensu, wszelkie
zalety c++ idą się paść, już idą często ze względu na pewną
nieprzewidywalność w stosunku do C.


>> Więc takie porównanie jest bez sensu...
>
> Otoz nie. Ma _gleboki_ praktyczny sens.
> Ominiecie tego problemu w "wysokopoziomowym" C++
> wymaga (ze tak to nazwe specjalistycznej "wiedzy" - cudzuslow
> zamierzony bo to kolejny syf/smiec w pamieci niz prawdziwa wiedza)
> i zejscia na maksynalnie niski poziom - nawet linkera (czyli
> "wysokopoziomowosc" C++ idzie sie zwyczajnie pasc.

Ale mi nie zależy na tym by C++ było lub nie wysoko czy niskopoziomowym
językiem. natomiast porównanie było bez sensu, gdyż C++ ma byc przenośny
na poziomie źródeł, a nie binariów.

--
http://kaczus.ppa.pl
http://kaczanowska.info

do góry