Returning containers from function - C++ [closed]

Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
1
down vote
favorite
I've been trying to implement a few interfaces for processing data. And most of the time I do new of container and return a smart pointer to this container. Something like this:
class GenericUtil
private:
// Some members here
public:
unique_ptr<vector<string>> BreakStringOnDelimiter( string& dataStr );
;
But recently I came across "The c++ Programming Language" book and observed that Stroustrup seems to be suggesting to return containers just like that. But some other cases, he also demonstrates use of smart pointers for the same. So I have been just wondering what would be most efficient and maintainable way (plus a style which doesn't come as surprise to other fellow devs) of doing this?
unique_ptr<vector<string>> BreakStringOnDelimiter( string& dataStr );
or
vector<string> BreakStringOnDelimiter( string& dataStr );
or
vector<string>* BreakStringOnDelimiter( string& dataStr );
or something else?
Please suggest which one and why?
Thanks in advance!
c++ c++11 collections pointers
closed as off-topic by vnp, Vogel612â¦, 200_success Jan 28 at 22:17
This question appears to be off-topic. The users who voted to close gave these specific reasons:
- "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." â 200_success
- "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it." â vnp, Vogel612
add a comment |Â
up vote
1
down vote
favorite
I've been trying to implement a few interfaces for processing data. And most of the time I do new of container and return a smart pointer to this container. Something like this:
class GenericUtil
private:
// Some members here
public:
unique_ptr<vector<string>> BreakStringOnDelimiter( string& dataStr );
;
But recently I came across "The c++ Programming Language" book and observed that Stroustrup seems to be suggesting to return containers just like that. But some other cases, he also demonstrates use of smart pointers for the same. So I have been just wondering what would be most efficient and maintainable way (plus a style which doesn't come as surprise to other fellow devs) of doing this?
unique_ptr<vector<string>> BreakStringOnDelimiter( string& dataStr );
or
vector<string> BreakStringOnDelimiter( string& dataStr );
or
vector<string>* BreakStringOnDelimiter( string& dataStr );
or something else?
Please suggest which one and why?
Thanks in advance!
c++ c++11 collections pointers
closed as off-topic by vnp, Vogel612â¦, 200_success Jan 28 at 22:17
This question appears to be off-topic. The users who voted to close gave these specific reasons:
- "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." â 200_success
- "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it." â vnp, Vogel612
1
Thevector<string> BreakStringOnDelimiter( string& dataStr );is the most idiomatic way. In C++03 the compiler will elide the copy because of RVO. In C++11 this was made even more formal with Move Semantics. There is definitely no reason to use a smart pointer to hold a container. Containers and smart pointers are designed for memory management you don't need to use a smart pointer when the container is already doing the memory management (that just makes things slower).
â Martin York
Jan 29 at 23:34
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I've been trying to implement a few interfaces for processing data. And most of the time I do new of container and return a smart pointer to this container. Something like this:
class GenericUtil
private:
// Some members here
public:
unique_ptr<vector<string>> BreakStringOnDelimiter( string& dataStr );
;
But recently I came across "The c++ Programming Language" book and observed that Stroustrup seems to be suggesting to return containers just like that. But some other cases, he also demonstrates use of smart pointers for the same. So I have been just wondering what would be most efficient and maintainable way (plus a style which doesn't come as surprise to other fellow devs) of doing this?
unique_ptr<vector<string>> BreakStringOnDelimiter( string& dataStr );
or
vector<string> BreakStringOnDelimiter( string& dataStr );
or
vector<string>* BreakStringOnDelimiter( string& dataStr );
or something else?
Please suggest which one and why?
Thanks in advance!
c++ c++11 collections pointers
I've been trying to implement a few interfaces for processing data. And most of the time I do new of container and return a smart pointer to this container. Something like this:
class GenericUtil
private:
// Some members here
public:
unique_ptr<vector<string>> BreakStringOnDelimiter( string& dataStr );
;
But recently I came across "The c++ Programming Language" book and observed that Stroustrup seems to be suggesting to return containers just like that. But some other cases, he also demonstrates use of smart pointers for the same. So I have been just wondering what would be most efficient and maintainable way (plus a style which doesn't come as surprise to other fellow devs) of doing this?
unique_ptr<vector<string>> BreakStringOnDelimiter( string& dataStr );
or
vector<string> BreakStringOnDelimiter( string& dataStr );
or
vector<string>* BreakStringOnDelimiter( string& dataStr );
or something else?
Please suggest which one and why?
Thanks in advance!
c++ c++11 collections pointers
asked Jan 28 at 18:59
Shivendra Mishra
11118
11118
closed as off-topic by vnp, Vogel612â¦, 200_success Jan 28 at 22:17
This question appears to be off-topic. The users who voted to close gave these specific reasons:
- "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." â 200_success
- "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it." â vnp, Vogel612
closed as off-topic by vnp, Vogel612â¦, 200_success Jan 28 at 22:17
This question appears to be off-topic. The users who voted to close gave these specific reasons:
- "Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also off-topic." â 200_success
- "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it." â vnp, Vogel612
1
Thevector<string> BreakStringOnDelimiter( string& dataStr );is the most idiomatic way. In C++03 the compiler will elide the copy because of RVO. In C++11 this was made even more formal with Move Semantics. There is definitely no reason to use a smart pointer to hold a container. Containers and smart pointers are designed for memory management you don't need to use a smart pointer when the container is already doing the memory management (that just makes things slower).
â Martin York
Jan 29 at 23:34
add a comment |Â
1
Thevector<string> BreakStringOnDelimiter( string& dataStr );is the most idiomatic way. In C++03 the compiler will elide the copy because of RVO. In C++11 this was made even more formal with Move Semantics. There is definitely no reason to use a smart pointer to hold a container. Containers and smart pointers are designed for memory management you don't need to use a smart pointer when the container is already doing the memory management (that just makes things slower).
â Martin York
Jan 29 at 23:34
1
1
The
vector<string> BreakStringOnDelimiter( string& dataStr ); is the most idiomatic way. In C++03 the compiler will elide the copy because of RVO. In C++11 this was made even more formal with Move Semantics. There is definitely no reason to use a smart pointer to hold a container. Containers and smart pointers are designed for memory management you don't need to use a smart pointer when the container is already doing the memory management (that just makes things slower).â Martin York
Jan 29 at 23:34
The
vector<string> BreakStringOnDelimiter( string& dataStr ); is the most idiomatic way. In C++03 the compiler will elide the copy because of RVO. In C++11 this was made even more formal with Move Semantics. There is definitely no reason to use a smart pointer to hold a container. Containers and smart pointers are designed for memory management you don't need to use a smart pointer when the container is already doing the memory management (that just makes things slower).â Martin York
Jan 29 at 23:34
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
In C++ 11 you probably would use
vector<string> BreakStringOnDelimiter( const string& dataStr );
The container classes can be very efficiently move constructed (this is a new and smart feature of C++ 11 which can avoid temporary objects in many cases), which means that on return no expensive copy construction of the containers (and the strings in the container) is needed. Essentially only the some pointers are passed around on return.
Alternatively the solution with unique_ptr would also work, but is in my opinion not as good (and probably not really more efficient).
Given these alternative options, returning a bare pointer is not recommended.
For maximum efficiency you should consider using the emplace function when filling the vector. This avoids additional copies of string.
Also probably const string & as argument is better suited.
Even in C++-3 this was efficient. TheRVOandNRVOoptimizations built into the compiler would basically elide the copy.
â Martin York
Jan 29 at 23:35
@MartinYork: true, even though it is guaranteed to happen only with C++17 and later. Although RVO and NRVO was implemented by virtually all compilers even before C++17.
â Andreas H.
Feb 5 at 10:13
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
In C++ 11 you probably would use
vector<string> BreakStringOnDelimiter( const string& dataStr );
The container classes can be very efficiently move constructed (this is a new and smart feature of C++ 11 which can avoid temporary objects in many cases), which means that on return no expensive copy construction of the containers (and the strings in the container) is needed. Essentially only the some pointers are passed around on return.
Alternatively the solution with unique_ptr would also work, but is in my opinion not as good (and probably not really more efficient).
Given these alternative options, returning a bare pointer is not recommended.
For maximum efficiency you should consider using the emplace function when filling the vector. This avoids additional copies of string.
Also probably const string & as argument is better suited.
Even in C++-3 this was efficient. TheRVOandNRVOoptimizations built into the compiler would basically elide the copy.
â Martin York
Jan 29 at 23:35
@MartinYork: true, even though it is guaranteed to happen only with C++17 and later. Although RVO and NRVO was implemented by virtually all compilers even before C++17.
â Andreas H.
Feb 5 at 10:13
add a comment |Â
up vote
1
down vote
accepted
In C++ 11 you probably would use
vector<string> BreakStringOnDelimiter( const string& dataStr );
The container classes can be very efficiently move constructed (this is a new and smart feature of C++ 11 which can avoid temporary objects in many cases), which means that on return no expensive copy construction of the containers (and the strings in the container) is needed. Essentially only the some pointers are passed around on return.
Alternatively the solution with unique_ptr would also work, but is in my opinion not as good (and probably not really more efficient).
Given these alternative options, returning a bare pointer is not recommended.
For maximum efficiency you should consider using the emplace function when filling the vector. This avoids additional copies of string.
Also probably const string & as argument is better suited.
Even in C++-3 this was efficient. TheRVOandNRVOoptimizations built into the compiler would basically elide the copy.
â Martin York
Jan 29 at 23:35
@MartinYork: true, even though it is guaranteed to happen only with C++17 and later. Although RVO and NRVO was implemented by virtually all compilers even before C++17.
â Andreas H.
Feb 5 at 10:13
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
In C++ 11 you probably would use
vector<string> BreakStringOnDelimiter( const string& dataStr );
The container classes can be very efficiently move constructed (this is a new and smart feature of C++ 11 which can avoid temporary objects in many cases), which means that on return no expensive copy construction of the containers (and the strings in the container) is needed. Essentially only the some pointers are passed around on return.
Alternatively the solution with unique_ptr would also work, but is in my opinion not as good (and probably not really more efficient).
Given these alternative options, returning a bare pointer is not recommended.
For maximum efficiency you should consider using the emplace function when filling the vector. This avoids additional copies of string.
Also probably const string & as argument is better suited.
In C++ 11 you probably would use
vector<string> BreakStringOnDelimiter( const string& dataStr );
The container classes can be very efficiently move constructed (this is a new and smart feature of C++ 11 which can avoid temporary objects in many cases), which means that on return no expensive copy construction of the containers (and the strings in the container) is needed. Essentially only the some pointers are passed around on return.
Alternatively the solution with unique_ptr would also work, but is in my opinion not as good (and probably not really more efficient).
Given these alternative options, returning a bare pointer is not recommended.
For maximum efficiency you should consider using the emplace function when filling the vector. This avoids additional copies of string.
Also probably const string & as argument is better suited.
answered Jan 28 at 19:08
Andreas H.
57635
57635
Even in C++-3 this was efficient. TheRVOandNRVOoptimizations built into the compiler would basically elide the copy.
â Martin York
Jan 29 at 23:35
@MartinYork: true, even though it is guaranteed to happen only with C++17 and later. Although RVO and NRVO was implemented by virtually all compilers even before C++17.
â Andreas H.
Feb 5 at 10:13
add a comment |Â
Even in C++-3 this was efficient. TheRVOandNRVOoptimizations built into the compiler would basically elide the copy.
â Martin York
Jan 29 at 23:35
@MartinYork: true, even though it is guaranteed to happen only with C++17 and later. Although RVO and NRVO was implemented by virtually all compilers even before C++17.
â Andreas H.
Feb 5 at 10:13
Even in C++-3 this was efficient. The
RVO and NRVO optimizations built into the compiler would basically elide the copy.â Martin York
Jan 29 at 23:35
Even in C++-3 this was efficient. The
RVO and NRVO optimizations built into the compiler would basically elide the copy.â Martin York
Jan 29 at 23:35
@MartinYork: true, even though it is guaranteed to happen only with C++17 and later. Although RVO and NRVO was implemented by virtually all compilers even before C++17.
â Andreas H.
Feb 5 at 10:13
@MartinYork: true, even though it is guaranteed to happen only with C++17 and later. Although RVO and NRVO was implemented by virtually all compilers even before C++17.
â Andreas H.
Feb 5 at 10:13
add a comment |Â
1
The
vector<string> BreakStringOnDelimiter( string& dataStr );is the most idiomatic way. In C++03 the compiler will elide the copy because of RVO. In C++11 this was made even more formal with Move Semantics. There is definitely no reason to use a smart pointer to hold a container. Containers and smart pointers are designed for memory management you don't need to use a smart pointer when the container is already doing the memory management (that just makes things slower).â Martin York
Jan 29 at 23:34