On Friday, June 2, 2017 at 6:51:17 PM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> > Hmmm trudno tak programować, bo biblioteki używają klas, szablonów
> > i wyjątków także, choć rzadziej.
>
> Tak?. To napisz C++sowy dll, ktory w interface/API ma cus (np pole, parametr
metody) ze
> standardowego STL-a...
>
> AK

Biblioteki to nie tylko dll, są biblioteki nagłówków - o czym dobrze
wiesz. Gdy potrzeba funkcjonalności szablonów na poziomie biblioteki, to
nie ma innego wyjścia, jak wygenerować kod szablonu, wywołać kompilator i
skompilować szablon do biblioteki, a potem dynamicznie załadować - o
czym też dobrze wiesz ;-)

Pozdrawiam

do góry

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

> Gdy potrzeba funkcjonalności szablonów na poziomie biblioteki, to
> nie ma innego wyjścia, jak wygenerować kod szablonu, wywołać kompilator i
> skompilować szablon do biblioteki, a potem dynamicznie załadować - o
> czym też dobrze wiesz ;-)

Probowals to robic ? Da sie uzyc/zlinkowac dll-ke majaca w swym API
uzycie standardowego kontenera STL ?
C++/SzacownyKomitetANSIC++ to przewidzial/zezwala ?

AK

do góry

On Friday, June 2, 2017 at 9:07:46 PM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> > Gdy potrzeba funkcjonalności szablonów na poziomie biblioteki, to
> > nie ma innego wyjścia, jak wygenerować kod szablonu, wywołać kompilator i
> > skompilować szablon do biblioteki, a potem dynamicznie załadować - o
> > czym też dobrze wiesz ;-)
>
> Probowals to robic ?
> Da sie uzyc/zlinkowac dll-ke majaca w swym API
> uzycie standardowego kontenera STL ?
> C++/SzacownyKomitetANSIC++ to przewidzial/zezwala ?

Nie wiem w czym widzisz problem. We wszystkich wariantach nie próbowałem.
Po prawdzie, częściej :

1) generowałem cały program, kompilowałem i uruchamiałem przez jakieś
exec;

2) program umiał sam wygenerować fragment swojego kodu, potem trzeba
było ręcznie ten fragment podmienić i skompilować.

Zawsze działało. Dlaczego to nie miałoby działać z biblioteką?
Oczywiście jeśli generujemy tylko bibliotekę, a nie cały program,
to w programie magicznie nie dopasują się interfejsy. Wywołanie
musi być przy pomocy wcześniej przewidzianej metody, ale wewnątrz
biblioteki, np. w celu optymalizacji, można używać szablonów.
Wszystko co napisałem wiesz i Ty wiesz, że ja wiem, więc nie
wiem w czym widzisz problem? Chyba nie w tym dopatrujesz się
problemu (bo po co?), że to się dzieje na poziomie bibliotek/systemu, a
nie w ramach standardu C++?


Pozdrawiam

do góry

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++.

Pozdrawiam

AK

do góry

On Friday, June 2, 2017 at 11:07:14 PM UTC+2, AK wrote:
> 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++.
>
> Pozdrawiam
>
> AK

Ok, przyznaję że opisujesz obszar z którym miałem zbyt małą styczność
żeby wyrobić sobie zdanie. Warunek konieczny: szablon musi być
identycznie skompilowany w bibliotece i w programie korzystającym z
biblioteki, aby nie było problemów przy linkowaniu statycznym bądź
dynamicznym. Musi też być standardowo wystawiony na zewnątrz. Czy są z
tym aż takie problemy? Skoro piszesz że są, to wierzę na słowo.

Pozdrawiam

do góry

On Fri, 2 Jun 2017 08:29:29 -0700 (PDT), bartekltg
<b...@g...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.

do góry

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.

do góry

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

do góry

On Friday, June 2, 2017 at 6:44:55 PM UTC+2, AK wrote:
> Użytkownik "bartekltg" <b...@g...com> napisał:
>
> On Friday, June 2, 2017 at 12:01:15 PM UTC+2, AK wrote:
> > Użytkownik "slawek" <f...@f...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

do góry

On 6/2/2017 8:53 AM, Zenon Oktawiec wrote:
> Przecież wyraźnie w tekście stoi, że tu niczego nie pisano, tylko
> wdrażali SAP'a.

No ale przecież to nie polega na odpaleniu setup.exe. Ktoś to
skonfigurował. To że nie było to C++ przeciez nie oznacza że to nie jest
informatyka czy programowanie.

> Problem jest więc jest pozainformatyczny - ewidentnie
> zawinił "manadżment".

Tego nie wiadomo, chciałbym się własnie dowiedzieć kto zawinił. Własnie
po to aby ktoś miał podobne firmy na czarnej liście.

Miałem nadzieje na jakiegoś anonima ;)

> IMHO - temat nie na tą grupę.

A IMHO jak najbardziej. SAP czy assembler, nie ma różnicy, chodzi o
dziadostwo a to jest uniwersalne.

do góry