Problem ze zrozumieniem struktur i funkcji

Question

Przerabiam ksiażkę S. Prathy (jak można wywnioskować z moich pytań) i nadziałem się na temat, gdzie nie do końca wytłumaczył o co chodzi, a mianowicie - mamy taki kawałek kodu:

struct polar
{
    double distance; //odleglosc od poczatku ukladu
    double angle; //kat wzgledem dodatniej polosi x
};

struct rect
{
    double x; //odleglosc od poczatku ukladu w poziomie
    double y; //odleglosc od poczatku ukladu w pionie
};

//prototypy funkcji
polar rect_to_polar(rect xypos);

Jak tworzy się wlasne funkcje, to nie koniecznie musi ona coś zwracać i w tym przypadku stosuje się polecenie

void

Ale tutaj mamy takie coś jak

polar rect_to_polar(rect xypos);

W takim razie funkcja zwraca polar? Czyli wartość typu double z tej struktury? Bo ma przyjąć wartości ze struktury rect.

Dobrze rozumiem? Może ktoś to na chłopski rozum wytłumaczyć?

Answer 1

Funkcja zwraca strukturę polar. Może łatwiej będzie na przykładzie, załóżmy strukturę wektor oraz funkcję dodającą dwie struktury wektor i zwracającą wartość typu wektor:

struct wektor
{
  double x;
  double y;
  double z;
};

wektor dodawanie(wektor skladnik1,wektor skladnik2)
{
  wektor suma;
  suma.x=skladnik1.x+skladnik2.x;
  suma.y=skladnik1.y+skladnik2.y;
  suma.z=skladnik1.z+skladnik2.z;
  return suma;
}

Funkcja zwraca strukturę wektor (wszystkie pola, które się w niej znajdują, czyli x, y oraz z). Używając tej funkcji, a potem wyświetlając za pomocą standardowego cout zobaczysz, że zwracana jest cała struktura. Przykład:
 

int main()
{
  wektor w1={4.0,5.0,6.0};
  wektor w2={3.0,2.0,1.0};
  wektor wynik=dodawanie(w1,w2);
  cout<<wynik.x<<" "<<wynik.y<<" "<<wynik.z;
  return 0;
}

 

Comments

Twój przykład najbardziej mi rozjaśnił problem. Wychodzi na to, że czym dalej w lasy tym więcej drzew. :p

Dzięki! :)

---

Tak to już jest.:) Jeszcze odnosząc się do tego co ja i inni użytkownicy napisali... Na tyle, ile znam już C/C++  to struktura jest kolejnym szczeblem. Ucząc się programowania, zaczynasz od tych prostych zmiennych (char, int, double, itd). Potem stwierdzasz, że w pewnych sytuacjach dobrze jest "takie same" (tego samego typu) zmienne zebrać razem bo łatwiej jest wtedy nimi manipulować. Na dalszym etapie, może zajść potrzeba złożenia w pewną całość rzeczy różnych typów, wtedy tworzysz strukturę.
A żeby było bardziej strawne, korzystając z tego że lato jest...
To zaczynasz od piwka, jednego drugiego -> proste zmienne (char, int , double)
Jak więcej amatorów browarka, to lepiej browarki w skrzynce albo zgrzewce przynieść -> tablica
A jak jest ognisko, to nie tylko browar idzie, dobrze by było jeszcze coś przegryźć ->struktura.
Takie luźne rozmyślania na temat programowania i browarkowania.

---

Zastanawiałeś się nad karierą naukową? :D

---

Ha ha;) Skąd to pytanie?;)

---

Z doświadczenia wiem, że na studiach lepiej zrozumieć zagadnienie korzystając z życiowych sytuacji niż przepisywać słowo w słowo książkę. :)

---

Powiem tak, z doświadczeń wyniesionych (w sumie dalej wynoszonych, jako że nie mam tego etapu zakończonego) ze studiów nasuwa mi się sporo wniosków i przemyśleń. Mam na to trochę inne spojrzenie, także ze względu na 4 lata technikum.
1. Moim zdaniem, zbytnie nastawienie się wykładowców (ćwiczeniowców) na zapisanie całej tablicy wzorami, przy których po kilku minutach całe audytorium ma tego gościa i to co on mówi w głębokim poważaniu. Rozumiem, że uczelnia wyższa, że inżynier ma główkować,liczyć, posługiwać się wzorami, itd. Ale przede wszystkim inżynier ma rozumieć zagadnienie na poziomie technika, jak załóżmy dany mechanizm ma działać, warunki w jakich działa, takie sprawy. A ponadto umieć go zaprojektować, itd. Potem wychodzą sytuację, że pierwszy lepszy technik mówiąc brutalnie "zjada" takiego inżyniera na przy pierwszej lepszej okazji. Nie to, że zwalam całą winę na wykładowców, bo jak student nie chce nauczyć się/zrozumieć to siłą mu wiedzy do głowy nie nakładziesz.
2. Zawsze mnie wkurzał model tego typu:
- wykłady (omawianie teoretycznych zagadnień) - to akurat musi zostać, bo jak składać rymy wielokrotne to musisz się najpierw alfabetu nauczyć i składania słów z liter. Sorry, taki mamy klimat, tego się nie da ominąć.
- ćwiczenia (liczenie zadań często oderwanych od rzeczywistości, bo tak) - no, coś trzeba policzyć, przełożenie przekładni, odpowiedni rezystor do układu, cokolwiek innego).
- laborki - praktyka, żeby student umiał się sprzętem obsłużyć.
Po zaliczeniu dwóch dalszych rygorów (laborki, ćwiczenia), następuje egzamin, najczęście teoria klepana wcześniej.
Wszystkie wymienione przeze mnie punkty w mniejszym/większym stopniu powinny zostać, bo tego się nie da ominąć. Ja bardziej bym się nastawiał na projekty. Zaprojektuj jakiś układ, napisz program, etc. uwzględniając warunki typu nie wiem koszt układu, konkretna platforma, jakieś inne wymagania, To powinno być clue sprawy, wykorzystać wiedzę z wykładów umiejętności z ćwiczeń laborek do stworzenia czegoś co ma jakieś przełożenie na rzeczywistość. Takie zadania najbardziej pobudzają kreatywność, kombinowanie jak ominąć jakieś ograniczenia bez uszczerbku, lub z jak najmniejszym uszczerbkiem na efekt finalny. Jak mi to zawsze mówił szef w robocie "Nie ma, że się nie da, trzeba tylko trochę pomyśleć". Mam nadzieję, że wyraziłem się w miarę składnie, mimo późnej pory.

---

A co do moich "wybryków" na tym forum.;) Doświadczenie w nauczaniu, skoro już wspomniałeś o karierze naukowej, myślę że całkiem spore mam. No już prawie 2 lata oprócz studiowania, trudnie się hobbystycznie korepetycjami. Zakres nawet dość szeroki, zaczynałem od układów cyfrowych, assemblera na x86, przez programowanie w C/C++, kończąc na programowaniu mikrokontrolerów (od x51 w assembly do jak na razie AVR-ów w assembly i C). Z racji kierunku studiów - mechatronika, programowanie jest zmieszane z elektroniką, automatyką, przetwarzaniem sygnałów, to i zdarzało się tłumaczyć rzeczy raczej dalekie od programowania, typu jak działa wzmacniacz albo jak sygnał analogowy się digitalizuje.
Zawsze starałem się, na ile się da oczywiście, uciekać od wzorów na rzecz tłumaczenia rzeczy od podstaw (kopanie rowów od budowy szpadla a nie od budowy koparki gąsienicowej) i tłumaczenia zawiłych hermetycznych pojęć na język ludzki. Bo jak zakuma się jak działa szpadel, to po nitce do kłębka łatwiej jest zrozumieć jak działa koparka gąsienicowa, a nie zaczynając od koparki.
A co do programowania jeszcze, jak wspomniałem wcześnie zaczynałem od assemblera. Do tej pory mi została miłość do assemblera. Ucząc się assemblera, budowy danego procesora łatwiej mi przyszło potem zrozumienie zmiennych, tablic, funkcji w programowaniu wysokopoziomowym i łatwiej mi potem komuś tłumaczyć pewne rzeczy.

Answer 2

Ma zwrócić instancję struktury polar. :) To co stawiasz przed nazwą funkcji to typ, jaki zwracasz.

Answer 3

ta funkcja zwróci obiekt typu polar :)

struct polar
{
         double distance;
         double angle;
}

...

polar p;
p = rect_to_polar(..);
cout << p.distance << " " << p.angle << "\n";

troche pseudokod ale chyba na tyle jasny że zrozumiesz ;P

Answer 4

Wnioskując z nazwy funkcji, to na podstawie obiektu xypos, który przyjmuje jako parametr, tworzy obiekt struktury polar, oblicza distance, angle i uzupełnia te zmienne w nowo powstałej strukturze po czym zwraca taką strukturę. Wywołanie będzie wyglądało mniej więcej tak 

rect myRect;
myRect.x = 10;
myRect.y = 15;
polar MyPolar = rect_to_polar(myRect);

Answer 5

Hmm...No tutaj masz problem, bo nie rozumiesz do końca czym są struktury i klasy.

To zacznijmy od definicji - struktura, to twój własny, opisany typ danych. Posiada ona pola, określane przez typ zmiennych. Pozwala to na uporządkowanie wielu aspektów w kodzie. Klasa, jest w gruncie rzeczy tym samym - to także wyspecjalizowany typ danych, opisany przez programiste.

Każda struktura/klasa zajmuje w pamięci pewną ilość miejsca, zazwyczaj zależną od typu i ilości pól. Kiedy zwracasz strukturę, to zwracasz cały jej rozmiar w pamięci wraz ze wszystkimi polami.

Pan Pratha w owym kodzie na temat wektorów, jednak tych matematycznych/fizycznych stworzył dwojaką reprezentację danych - jedną według klasycznego wyglądu wektora matematycznego, drugą z opisem kąta oraz długością. Aby teraz przekonwertować jedną reprezentację na drugą, będziemy musieli znaleźć długości, bądź kąt oraz przeciwprostokątną.

W funkcji o którą pytasz, wyliczymy z twierdzenia pitagorasa długość przeciwprostokątnej na podstawie przyprostokątnych i zapiszemy ją do pola distance. Kąt możemy wyliczyć z funkcji arcus tangenes, bądź arcus cotangens i zapiszemy go do pola angle.

Oczywiście będziemy zwracać nasz typ danych, czyli całą strukturę. Tutaj mamy dwie opcje - napisać sobie wygodny konstruktor owej struktury, i zwrócić obiekt anonimowy, bądź stworzyć wewnątrz funkcji strukturę, wypełnić ją i zwrócić.

Np.

struct polar
{
     double distance;
     double angle;
     
     polar( double x, double y ) //dla drugiej wersji zwracania wartosci
     {
           distance = x;
           angle = y;
     }
}


//1 wersja
polar rect_to_polar(rect const & r)
{
    polar temp;
    temp.distance = //tutaj odleglosc
    temp.angle = //tutaj kat

    return temp;
}

//2 wersja
polar rect_to_polar(rect const & r)
{   
    double t_distance = //tutaj odleglosc
    double t_angle = //tutaj kat

    return polar( t_distance, t_angle );
}

 

Myślę, że mogłem Ci coś rozjaśnić! :)

Comments

Jednak zbyt długo to pisałem

---

Nic w przyrodzie nie ginie! Każda pomoc się przyda. Dzięki! :)