Kolejność wykonywania C ++ w łańcuchu metod

Wynik tego programu:

#include <iostream> 
class c1
{   
  public:
    c1& meth1(int* ar) {
      std::cout << "method 1" << std::endl;
      *ar = 1;
      return *this;
    }
    void meth2(int ar)
    {
      std::cout << "method 2:"<< ar << std::endl;
    }
};

int main()
{
  c1 c;
  int nu = 0;
  c.meth1(&nu).meth2(nu);
}

Jest:

method 1
method 2:0

Dlaczego nunie ma 1, kiedy meth2()zaczyna się?

Ponieważ kolejność oceny jest nieokreślona.

Widzisz nuw mainocenianej na 0zanim nawet meth1nazywa. To jest problem z łańcuchem. Radzę tego nie robić.

Po prostu utwórz ładny, prosty, przejrzysty, czytelny i łatwy do zrozumienia program:

int main()
{
  c1 c;
  int nu = 0;
  c.meth1(&nu);
  c.meth2(nu);
}

Myślę, że ta część projektu normy dotycząca kolejności ocen jest istotna:

1.9 Wykonanie programu

...

15. O ile nie zaznaczono inaczej, oceny operandów poszczególnych operatorów i podwyrażeń poszczególnych wyrażeń nie są sekwencjonowane. Obliczenia wartości operandów operatora są sekwencjonowane przed obliczeniem wartości wyniku operatora. Jeśli efekt uboczny na obiekcie skalarnym nie jest sekwencjonowany względem innego efektu ubocznego tego samego obiektu skalarnego lub obliczenia wartości przy użyciu wartości tego samego obiektu skalarnego i nie są one potencjalnie współbieżne, zachowanie jest niezdefiniowane

i również:

5.2.2 Wywołanie funkcji

...

8. [Uwaga: Obliczenia wyrażenia z przyrostkiem i argumentów nie mają kolejności względem siebie. Wszystkie skutki uboczne oceny argumentów są sekwencjonowane przed wejściem do funkcji - uwaga końcowa]

Więc dla twojej linii c.meth1(&nu).meth2(nu);zastanów się, co dzieje się w operatorze pod względem operatora wywołania funkcji dla końcowego wywołania meth2, więc wyraźnie widzimy podział na wyrażenie i argument z przyrostka nu:

operator()(c.meth1(&nu).meth2, nu);

Wartości wyrażenia przyrostka i argumentu dla końcowego wywołania funkcji (tj. Wyrażenia przyrostka c.meth1(&nu).meth2i nu) nie są sekwencjonowane względem siebie, zgodnie z powyższą regułą wywołania funkcji . Dlatego efekt uboczny obliczania wyrażenia postfiksowego na obiekcie skalarnym arjest bez kolejności w stosunku do oceny argumentu nuprzed meth2wywołaniem funkcji. Zgodnie z powyższą regułą wykonywania programu jest to niezdefiniowane zachowanie.

Innymi słowy, kompilator nie musi oceniać nuargumentu meth2wywołania po meth1wywołaniu - może zakładać, że nie ma skutków ubocznych meth1wpływania na nuocenę.

Kod asemblera utworzony przez powyższe zawiera następującą sekwencję w mainfunkcji:

1. Zmienna nujest przydzielana na stosie i inicjalizowana z wartością 0.
2. Rejestr ( ebxw moim przypadku) otrzymuje kopię wartościnu
3. Adresy nui csą ładowane do rejestrów parametrów
4. meth1 jest nazywany
5. Rejestr wartość powrotu a poprzednio buforowane wartość z nuw ebxrejestrze są ładowane do rejestrów parametrów
6. meth2 jest nazywany

Co najważniejsze, w kroku 5 powyżej kompilator umożliwia nuponowne użycie zbuforowanej wartości z kroku 2 w wywołaniu funkcji meth2. W tym przypadku pomija możliwość, która numogła zostać zmieniona przez wezwanie do meth1- „niezdefiniowanego zachowania” w akcji.

UWAGA: Ta odpowiedź zmieniła się zasadniczo w stosunku do pierwotnej formy. Moje początkowe wyjaśnienie w zakresie skutków ubocznych obliczania argumentów, które nie były sekwencjonowane przed ostatecznym wywołaniem funkcji, było niepoprawne, ponieważ tak jest. Problem polega na tym, że obliczenia samych operandów są nieokreślone.

W standardzie C ++ z 1998 r., Sekcja 5, pkt 4

O ile nie zaznaczono, kolejność oceny operandów poszczególnych operatorów i podwyrażeń poszczególnych wyrażeń oraz kolejność, w jakiej występują skutki uboczne, jest nieokreślona. Pomiędzy poprzednim a następnym punktem sekwencji obiekt skalarny będzie miał swoją przechowywaną wartość zmodyfikowaną co najmniej raz przez ocenę wyrażenia. Ponadto dostęp do wcześniejszej wartości jest możliwy tylko w celu określenia wartości, która ma być przechowywana. Wymagania niniejszego punktu muszą być spełnione dla każdego dopuszczalnego uporządkowania podwyrażeń pełnego wyrażenia; w przeciwnym razie zachowanie jest niezdefiniowane.

(Pominąłem odniesienie do przypisu # 53, który nie dotyczy tego pytania).

Zasadniczo &nunależy ocenić przed wywołaniem c1::meth1()i nuprzed wywołaniem c1::meth2(). Nie ma jednak żadnego wymagania, które nunależy ocenić wcześniej &nu(np. Dozwolone jest, aby nunajpierw zostać ocenione &nu, a następnie c1::meth1()wywoływane - co może być tym, co robi twój kompilator). Wyrażenie *ar = 1w c1::meth1()związku z tym nie jest gwarantowana być oceniane przed nuw main()oceniana jest, aby być przekazywane c1::meth2().

Późniejsze standardy C ++ (których obecnie nie mam na komputerze, którego używam dziś wieczorem) mają zasadniczo tę samą klauzulę.

Myślę, że podczas kompilacji, zanim naprawdę zostaną wywołane funkcje met1 i met2, parametry zostały do ​​nich przekazane. Mam na myśli, kiedy używasz „c.meth1 (& nu) .meth2 (nu);” wartość nu = 0 została przekazana do meth2, więc nie ma znaczenia, czy "nu" zostanie zmienione później.

możesz spróbować tego:

#include <iostream> 
class c1
{
public:
    c1& meth1(int* ar) {
        std::cout << "method 1" << std::endl;
        *ar = 1;
        return *this;
    }
    void meth2(int* ar)
    {
        std::cout << "method 2:" << *ar << std::endl;
    }
};

int main()
{
    c1 c;
    int nu = 0;
    c.meth1(&nu).meth2(&nu);
    getchar();
}

otrzyma odpowiedź, której chcesz