C++ return reference – C / C++ – Fórum – Programujte.com

Ahoj, na stackoverflow som sa cital , ze nieco ako 
 

int& func() {
    int x;
    return x;
	
}

je zle, pretoze 'x' zanikne po returne .
Ak spravim nieco taketo tak je to v poriadku ? 

int& func() {
    int& x;
    return x;

}

Co by sa stalo v takomto pripade? 
 

int func() {
    int& x;
    return x;

}

dakujem za objasnenie :-))

Vracení ukazatele nebo reference na lokální proměnnou je nesmysl - v okamžiku návratu funkce už takový ukazatel nebo reference odkazují na neplatnou paměť.

Funkci lze předat referenci jako parametr. Funkce pak může změnit obsah proměnné na kterou reference odkazuje.

hu

Ak sa nemylim , tak 'return by value = kopirovanie' , co teda znamena ,
ze kazdy objekt vytvoreny vo funkcii ktory vratime hodnotou budeme musiet kopirovat pri volani funkcie resp.
neexistuje ziadny sposob ako vratit lokalny objekt bez kopirovania? 
 

Pokud vytvořím objekt vně funkce a funkci předám ukazatel nebo referenci jako parametr, ke kopírování objektu nedojde. Např. u polí se tento přístup běžně používá.

Konkrétně v případu int bych to neřešil, nemyslím si, že by kopírování představovalo významnou režii. Navíc při úrovni optimalizace u dnešních překladačů nemusí ke kopírování dojít.

hu

Co se tyce vstupne vystupnich parametru, tak je soucasnym trendem uplne se tomu vyhybat. Prejit napriklad k metodam objektu: https://www.fluentcpp.com/2018/09/07/input-output-values/

Nicmene to u POD typu moc nejde.

Taktez se to nedoporucuje, pokud by se musel delat wrapper jen kvuli tomu.

Int sluzil iba ako priklad :-))  

class Account {
    public:
        Account(const std::string& ac_name): account_name(ac_name) {}
        std::string account_name;
};

class Bank {
    private:
        std::vector<Account> accounts;
        
    public:
        Account searchForAccount (const std::string& name) { 
            auto it = std::find(...);
            Account acc = *it; 
            return acc; // return without copying     
        } 
        void add(const std::string& name) { accounts.push_back(Account(name)); }
        void print() { for (auto& x : accounts) { std::cout << x.account_name << std::endl; }}
};
    

A co v takomto pripade? Je nieco take mozne? Dakujem :-) 

#6 Rtt

Tohle je zrovna orisek, reference se vraci blbe, protoze account taky nemusi existovat. Musel bys to mit podobne jako nektere stl knihovny - udelat test prezence a pak pripadne vratit referenci. Teoreticky by slo pouzit std::optional (nebo boost::optional), ale nejsem si jist, jestli zvlada reference (boost::optional udajne reference i zvlada).

Dalsi moznost je vytvorit pomocny objekt, ktery by mel k dispozici akorat dva iteratory, dokazal by rici, jestli byl Account nalezen a pri dereferenci pomoci operatoru* by vratil referenci nebo konstantni referenci.

A pokial by sme predpokladali, ze account musi existovat? 
Teoreticky bolo by mozne (a v poriadku) nieco taketo? 
V takomto pripade by uz teda neslo o vracanie lokalneho objektu
ale priamo o vracanie daneho objektu z vectora , tak? 
 

const Account& searchForAccount (const std::string& name) const { 
            std::vector<int>::const_iter it = std::find(...);
            return *it;  // vratene bez kopirovania? 
        } 

#8 Rtt
ano, pokud overis existenci pred touhle dereferenci iteratoru, tak to pujde. Nicmene na overeni budes potrebovat jeden find, a na vraceni reference dalsi. Proto bych zvolil ten extra objekt, kde by byl ten vraceny iterator a end iterator, a vse se z toho uz da zjistit.

Moc nerozumiem ako by to vyzeralo s tym extra objektom .. :-) 
nebolo by jednoduchsie spravit si nejaku metodu ktora by vratila true/false podla
toho ci by si tam account nachadzal? 

#10 Rtt
zhruba by to vypadalo takhle:

#include <iostream>
#include <string>
#include <vector>
#include <algorithm>

class Account {
    public:
        Account(const std::string& ac_name): account_name(ac_name) {}
        std::string account_name;
};


class Bank {
private:
    std::vector<Account> accounts;
        
public:
        
    class AccountResult
    {
    public:
        AccountResult(std::vector<Account>::const_iterator iter, std::vector<Account>::const_iterator end)
        : iter{ iter }
        , end{ end }
        {}
    
        operator bool() const { return iter != end; }
        Account const& operator*() { return *iter; }
        Account const* operator->() { return &*iter; }
        
    private:
        std::vector<Account>::const_iterator  iter;
        std::vector<Account>::const_iterator  end;
    };
    
    
    AccountResult find(const std::string& name)
    { 
        return
        { 
            std::find_if(
                accounts.begin(),
                accounts.end(),
                [name](Account const& acct){ return acct.account_name == name; }
            ),
            accounts.end()
        };
    } 
        
    void add(const std::string& name)
    {
        accounts.emplace_back(name);
    }
        
    void print()
    {
        for (auto& x : accounts)
        {
            std::cout << x.account_name << std::endl;
        }
    }
};




int main()
{
    Bank banka;
    
    banka.add("prvy");
    banka.add("druhy");

    banka.print();
    
    if (auto account = banka.find("prvy"))
    {
        std::cout << "Nalezeno: " << account->account_name << "\n"; 
    }
    
    if (auto account = banka.find("druhy"))
    {
        std::cout << "Nalezeno: " << (*account).account_name << "\n"; 
    }
}

Nicmene v tomhle pripade je otazkou, jestli pouzivat zrovna vector, kdyz by se vic hodil typ std::map

#1 Rtt
hele proč se zabejváš takovejma kravinama ? Prostě v té/nějaké metodě dané třídy dej "new" vytvoř si dynamickou proměnnou na hladě a vrať její ukazatel return-em a když opustíš metodu tak proměnná zůstane.

já už sem v nativeC++ nedělal ani nepamatuju ale mám pocit, že se smaže až když dáš delete na třídu/class, ve který je definovaná. Nicméně podle mě sou celý Interface class nesmysly co někdo vytvořil protože nevěděl jak dál. Vem si že třeba v C# muže interface class pouze obsahovat deklarace, které musíš vytvořit v následovníkovi, ale interface samotný nejde dynamicky změnit. Což je paradox, takže je to vlastně k ničemu protože když do metody, které je vyžadována nedáš potřebný kod tak se stejně všechno sesype.

#12 Jerry
a co se týče in-out proměnných no tak používej properties a máš to. jednu properties na in operace a jinou na out operace :) nebo se to dá ošetřit přetížením metod prostě v céčku de všechno nastotisíc různých způsobů a pak se v tom stejně nevyznáš když se k tomu musíš vrátit po roce... :)