Czy jest jakiś ładny sposób zapisu if-wewnątrz-for (ew. innych pętli)
takich, że jest GWARANTOWANE przeniesienie if przed for w wyniku kompilacji,
tak aby test if wykonywał się tylko jeden raz - a nie np. 10 milionów razy -
i to bez sięgania po optymalizację?

Jeżeli jest coś takiego for{ if } -- czyli instrukcja warunkowa wewnątrz
pętli, np.:

for (i = 0; i < 10; i++)
if(x > y)
{
...a...
...b1...
...c...
...d...
...e1...
...f...
}
else
{
...a...
...b2...
...c...
...d...
...e2...
...f...
}

Oczywiście kumaty kompilator (x i y są ustalone z zewnątrz) powinien to
sobie zoptymalizować do

if
{
for
for
}

Ale jak to zapisać bez potrzeby odwoływania się do mądrości kompilatora i
bez rozwlekania jak niżej?

if(a > b)
for (i = 0; i < 10; i++)
{
...a...
...b1...
...c...
...d...
...e1...
...f...
}
else
for (i = 0; i < 10; i++)
{
...a...
...b2...
...c...
...d...
...e2...
...f...
}

W kodzie źródłowym niepotrzebne są dublowane linie ...a... ...c... ...d...
...f..., co jest nieprzyjemne jeżeli jest ich za mało aby robić z nich
procedurę (i nie chcemy mieć narzutów na call/ret - no, ale to też powinien
zoptymalizować kompilator) - a jednocześnie MUSZĄ one być dokładnie takie
same (i np. poprawka w jednym miejscu pociąga za sobą poprawianie w tuzinie
podobnych.

do góry

On 03/17/2012 01:01 PM, slawek wrote:
> Czy jest jakiś ładny sposób zapisu if-wewnątrz-for (ew. innych pętli)
> takich, że jest GWARANTOWANE przeniesienie if przed for w wyniku
> kompilacji, tak aby test if wykonywał się tylko jeden raz - a nie np. 10
> milionów razy - i to bez sięgania po optymalizację?
>
> Jeżeli jest coś takiego for{ if } -- czyli instrukcja warunkowa
> wewnątrz pętli, np.:
>
> for (i = 0; i < 10; i++)
> if(x > y)
> {
> ...a...
> ...b1...
> ...c...
> ...d...
> ...e1...
> ...f...
> }
> else
> {
> ...a...
> ...b2...
> ...c...
> ...d...
> ...e2...
> ...f...
> }
>
> Oczywiście kumaty kompilator (x i y są ustalone z zewnątrz) powinien to
> sobie zoptymalizować do
>
> if
> {
> for
> for
> }
>
> Ale jak to zapisać bez potrzeby odwoływania się do mądrości kompilatora
> i bez rozwlekania jak niżej?
>
> if(a > b)
> for (i = 0; i < 10; i++)
> {
> ...a...
> ...b1...
> ...c...
> ...d...
> ...e1...
> ...f...
> }
> else
> for (i = 0; i < 10; i++)
> {
> ...a...
> ...b2...
> ...c...
> ...d...
> ...e2...
> ...f...
> }
>
> W kodzie źródłowym niepotrzebne są dublowane linie ...a... ...c...
> ...d... ...f..., co jest nieprzyjemne jeżeli jest ich za mało aby robić
> z nich procedurę (i nie chcemy mieć narzutów na call/ret - no, ale to
> też powinien zoptymalizować kompilator) - a jednocześnie MUSZĄ one być
> dokładnie takie same (i np. poprawka w jednym miejscu pociąga za sobą
> poprawianie w tuzinie podobnych.


poczytaj o metaprogramowaniu. w połączeniu ze wzorcem strategii, będzie
to to, czego szukasz.

--
pozdrawiam serdecznie / best regards,
bartek szurgot
/* http://www.baszerr.org */

do góry

On Saturday, March 17, 2012 1:01:53 PM UTC, bartek szurgot wrote:
> On 03/17/2012 01:01 PM, slawek wrote:
> > Czy jest jakiś ładny sposób zapisu if-wewnątrz-for (ew. innych pętli)
> > takich, że jest GWARANTOWANE przeniesienie if przed for w wyniku
> > kompilacji, tak aby test if wykonywał się tylko jeden raz - a nie np. 10
> > milionów razy - i to bez sięgania po optymalizację?
> >
> > Jeżeli jest coś takiego for{ if } -- czyli instrukcja warunkowa
> > wewnątrz pętli, np.:
> >
> > for (i = 0; i < 10; i++)
> > if(x > y)
> > {
> > ...a...
> > ...b1...
> > ...c...
> > ...d...
> > ...e1...
> > ...f...
> > }
> > else
> > {
> > ...a...
> > ...b2...
> > ...c...
> > ...d...
> > ...e2...
> > ...f...
> > }
> >
> > Oczywiście kumaty kompilator (x i y są ustalone z zewnątrz) powinien to
> > sobie zoptymalizować do
> >
> > if
> > {
> > for
> > for
> > }
> >
> > Ale jak to zapisać bez potrzeby odwoływania się do mądrości kompilatora
> > i bez rozwlekania jak niżej?
> >
> > if(a > b)
> > for (i = 0; i < 10; i++)
> > {
> > ...a...
> > ...b1...
> > ...c...
> > ...d...
> > ...e1...
> > ...f...
> > }
> > else
> > for (i = 0; i < 10; i++)
> > {
> > ...a...
> > ...b2...
> > ...c...
> > ...d...
> > ...e2...
> > ...f...
> > }
> >
> > W kodzie źródłowym niepotrzebne są dublowane linie ...a... ...c...
> > ...d... ...f..., co jest nieprzyjemne jeżeli jest ich za mało aby robić
> > z nich procedurę (i nie chcemy mieć narzutów na call/ret - no, ale to
> > też powinien zoptymalizować kompilator) - a jednocześnie MUSZĄ one być
> > dokładnie takie same (i np. poprawka w jednym miejscu pociąga za sobą
> > poprawianie w tuzinie podobnych.
>
>
> poczytaj o metaprogramowaniu. w połączeniu ze wzorcem strategii, będzie
> to to, czego szukasz.

Tez bym tak zrobil, w polaczeniu z funckjami lambda z C++ 0x moze to byc ladne i
eleganckie rozwiazanie. Ale wtedy nadal bedzie mial narzut na wolanie funkcji, jezeli
kompilator nie zdecyduje sie na inlining funkcji (nie musi).

Jezeli to jest NAPRAWDE koniecznie zeby uniknac wolania funkcji, to pozostaja makra
preprocesora.

RW

do góry

Użytkownik "Roman W" <b...@g...pl> napisał w wiadomości grup
dyskusyjnych:3360685.2549.1332001158521.JavaMail.geo
-discussion-forums@vbbfw10...
>> poczytaj o metaprogramowaniu. w połączeniu ze wzorcem strategii, będzie
>> to to, czego szukasz.
>
> Tez bym tak zrobil, w polaczeniu z funckjami lambda z C++ 0x moze to byc
> ladne i eleganckie rozwiazanie. Ale wtedy nadal bedzie mial narzut na
> wolanie funkcji, jezeli kompilator nie zdecyduje sie na inlining funkcji
> (nie musi).
>
> Jezeli to jest NAPRAWDE koniecznie zeby uniknac wolania funkcji, to
> pozostaja makra preprocesora.

Makra i include to rozwiązania połowiczne. I jeszcze kwestia kontekstu -
chodzi o szybkość - czyli zero narzutów na cokolwiek.

Oczywiście można tak:

$$for ( ... )
{
...a...
$$if (cond)
{
...b1...
}
$$else
{
...b2...
}
...c...
}

i potem przepuścić to przez skrypt awk jako przez preprocesor, aby
wygenerować to co trzeba, tj. if{for for} zamiast for{if}. I jeszcze na
wiele innych sposobów.

Ale!

Po pierwsze: to już nie jest w danym Języku - tzn. nie jest to już
Ada/Algol/cokolwiek - tylko w zasadzie "zupełnie nowy język" (dialekt?)

Po drugie: skoro to jest już "zupełnie nowy język" - to przecież tego
rodzaju "cuś" MOŻE BYĆ elementem języka. Czyli teoretycznie można
wprowadzić. Dlaczego wobec tego nie wprowadzono... skoro: a. upraszcza; b.
zabezpiecza; c. przyspiesza. Czyli ma same zalety?!

do góry