Consider the following piece of code, where: list<string> elements
bool SearchElement(const string& product) {
for (list<string>::iterator it = elements.begin(); it != elements.end();i++) {
string& element = *it;
if ( element == product) {
return true;
}
}
return false;
}
I want to rewrite it using a pointer:
bool SearchElement(const string& product) {
for (list<string>::iterator it = elements.begin(); it != elements.end();i++) {
string* pelement = it;
if ( *pelement == product) {
return true;
}
}
return false;
}
But it is throwing an error:
C:\Users...\C++\IShoppingApp.h:141: error: cannot convert
'std::__cxx11::liststd::__cxx11::basic_string<char >::iterator' {aka
'std::_List_iteratorstd::__cxx11::basic_string<char >'} to
'std::__cxx11::string*' {aka 'std::__cxx11::basic_string*'} in
initialization In file included from C:/Users/....
My professor said an iterator is roughly speaking a pointer, so I expected to use it as such. Why am I getting this error and how do I fix it?
An iterator acts like a pointer, but it is not a pointer. It refers to a value, but it is not itself a pointer. You can get a pointer, though:
string* pelement = &*it;
Note that although & and * are inverse operations on regular pointers, they are not so in general, and many types (specifically, iterators) override * to behave differently, so the two do not cancel out. It's also possible to override &, although there are fewer justifiable use cases that I can think of for that.
Based on the comments, I think you already understand this, but you want a reference. Raw pointers are generally frowned upon in modern C++, and a reference clearly conveys your intent of "I'm borrowing this for a second, I might modify it, but I'm not responsible for deleting it". Getting it to a pointer for educational purposes is fine, but the reference approach is the correct C++ way to do what you're doing.
Related
I have a function that search a vector and returns the item if it is found. But I want to know that best software appraoch to handle if it is not found.
I have created a function and could return -1 or something but that wouldn't match the return type.
koalaGraph::PVertex Koala::lookUpVertexbyName(const std::string&vertexName, const std::vector<koalaGraph::PVertex>& koalaVertices) {
for (size_t i = 0; i < koalaVertices.size(); i++) {
if(koalaVertices[i]->info.name == vertexName)
return koalaVertices[i];
}
}
If a situation is encountered where the item being searched for is not in the vector then program will exit.
You can use std::optional
#include <optional>
std::optional<koalaGraph::PVertex>
Koala::lookUpVertexbyName(const std::string&vertexName,
const std::vector<koalaGraph::PVertex>& koalaVertices) {
for (size_t i = 0; i < koalaVertices.size(); i++) {
if(koalaVertices[i]->info.name == vertexName)
return koalaVertices[i];
}
return {};
}
int main()
{
Koala k;
//...
auto maybeVertex = k.lookUpVertexByName("foo",vertices);
if(maybeVertex)
koalaGraph::PVertex&& vertex = *maybeVertex;
//alternatively
if(maybeVertex.has_value())
//found
}
You could use a for-loop and return a iterator.
std::vector<koalaGraph::PVertex>::const_iterator
Koala::lookUpVertexbyName(
const std::string&vertexName,
const std::vector<koalaGraph::PVertex>& koalaVertices)
{
for(auto iter = koalaVertices.begin(); iter != koalaVertices.end(); ++iter) {
if(koalaVertices[i]->info.name == vertexName) {
return iter;
}
}
return koalaVertices.end();
}
Further you check if you got end back. end indicates if the value was found or not.
auto iter = <fucntioncall> // lookUpVertexbyName
if (iter == <vector>.end() {
// abort or do what ever you want
}
To use the value you have to dereference the iterator. DON'T derefence the end-iterator, it will lead you to neverland -> undefined behavior.
std::string test = *iter;
Why not use std::find_if instead of reinventing the wheel. See this link.
struct equal
{
equal(const std::string& vertexName) : vertexName_(vertexName) { }
bool operator()(const koalaGraph::PVertex& pVertex) const
{
return pVertex->info.name == vertexName_;
}
private:
std::string vertexName_;
};
And then:
std::find_if(koalaVertices.begin(), koalaVertices.end(), eq(vertexName));
Regarding handling the errors in function as it has already been stated there are multiple approaches that one can take. Returning an iterator instead of object(you will avoid copying this way too) is one of them. end() iterator would then indicate that the name was not found.
There are three ways to exit a function:
Return a value
Throw a value
Call std::abort or std::exit (possibly indirectly)
(std::longjmp which you shouldn't use)
If you don't do any of the above, then behaviour will be undefined. If you don't want to do 1., then your options are 2. or 3. Abort and exit will terminate the process. A throw can be caught, but an uncaught throw will cause std::abort.
Note that just because you don't find a value, it's not necessarily impossible to return some value. What you can do is return a "sentinel" value that represents "not found". For example, std::string functions that return an index will return std::string::npos when there is no result. Functions returning a pointer might return null, and functions returning an iterator would return an iterator the the end of the range.
If there is no representation of your return type that could be reserved for a sentinel, there is a way to add such representation by wrapping the return type with additional state. The standard library has a generic wrapper for this: std::optional.
Another wrapper is the proposed std::expected (it's not accepted to the standard as far as I know, but there are plenty of non-standard implementations). It allows storing information about the reason for not returning a proper value which similar to what you can do with exceptions.
P.S. Your function appears to be nearly identical to std::find_if. Use standard algorithms when possible. Also consider a data structure that is more efficient for searching if the search space is large.
So I've solved this problem, but I need your opinion if what I did is best practice.
A simple class holds a vector of unique_ptrs to order objects. I will explain the member variable null_unique below.
class order_collection {
typedef std::unique_ptr<order> ord_ptr;
typedef std::vector<ord_ptr> ord_ptr_vec;
ord_ptr_vec orders;
ord_ptr null_unique;
public:
...
const ord_ptr & find_order(std::string);
....
So I need the users of this class to get access to the order unique_ptr if found. However I'm not going to move the object out of the vector so I'm returning the unique_ptr as const ref. My implementation of the find_order method:
const order_collection::ord_ptr & order_collection::find_order(std::string id) {
auto it = std::find_if(orders.begin(),orders.end(),
[&](const order_collection::ord_ptr & sptr) {
return sptr->getId() == id;
});
if (it == orders.end())
return null_unique; // can't return nullptr here
return *it;
}
Since I'm returning by reference I can't return a nullptr. If I try to do so, I get warning : returning reference to a temporary. And if nothing is found the program crashes. So I added a unique_ptr<order> member variable called null_unique and I return it when find doesn't find an order. This solves the problem and warning is gone and doesn't crash when no order is found.
However I'm doubting my solution as it make my class ugly. Is this the best practice for handling this situation?
You should only return and accept smart pointers when you care about their ownership semantics. If you only care about what they're pointing to, you should instead return a reference or a raw pointer.
Since you're returning a dummy null_unique, it is clear that the caller of the method doesn't care about the ownership semantics. You can also have a null state: you should therefore return a raw pointer:
order* order_collection::find_order(std::string id) {
auto it = std::find_if(orders.begin(),orders.end(),
[&](const order_collection::ord_ptr & sptr) {
return sptr->getId() == id;
});
if (it == orders.end())
return nullptr;
return it->get();
}
It doesn't really make sense to return a unique_ptr here, reference or otherwise. A unique_ptr implies ownership over the object, and those aren't really the semantics being conveyed by this code.
As suggested in the comments, simply returning a raw pointer is fine here, provided that your Project Design explicitly prohibits you or anyone on your team from calling delete or delete[] outside the context of the destructor of a Resource-owning object.
Alternatively, if you either have access to Boost or C++17, a std::optional<std::reference_wrapper<order>> might be the ideal solution.
std::optional<std::reference_wrapper<order>> order_collection::find_order(std::string id) {
auto it = std::find_if(orders.begin(),orders.end(),
[&](const order_collection::ord_ptr & sptr) {
return sptr->getId() == id;
});
if (it == orders.end())
return {}; //empty optional object
return **it; //will implicitly convert to the correct object type.
}
/*...*/
void func() {
auto opt = collection.find_order("blah blah blah");
if(!opt) return;
order & ord = opt->get();
/*Do whatever*/
}
(EDIT: In testing on the most recent version of MSVC 2017, it looks like std::reference_wrapper<T> will happily do an implicit conversion to T& if you tell it to. So replacing opt->get() with *opt should work exactly the same.)
As long as I'm here, I might point out that a std::vector<std::unique_ptr<type>> object has a very "Code Smell" sense to it. std::vector<type> implies ownership of the object as is, so unless you have a good reason to prefer this (maybe the objects are large, unmovable/uncopyable, and you need to insert and remove entries frequently? Maybe this is a polymorphic type?), you're probably better off reducing this to a simple std::vector.
EDIT:
The boost version is subtly different, because boost::optional has no restrictions against "optional references", which are specifically forbidden by the C++ Standard Library's version of std::optional. The boost version is actually going to be slightly simpler:
//return type changes, nothing else changes
boost::optional<order&> order_collection::find_order(std::string id) {
auto it = std::find_if(orders.begin(),orders.end(),
[&](const order_collection::ord_ptr & sptr) {
return sptr->getId() == id;
});
if (it == orders.end())
return {}; //empty optional object
return **it; //will implicitly convert to the correct object type.
}
/*...*/
//Instead of calling opt->get(), we use *opt instead.
void func() {
auto opt = collection.find_order("blah blah blah");
if(!opt) return;
order & ord = *opt;
/*Do whatever*/
}
I will post my code then explain my query:
typedef std::shared_ptr<SEntity> Entity;
//Scene_Ids is an enum
static std::map<Scene_Ids, std::vector<Entity> > m_scene_entities;
std::shared_ptr<SEntity>& SEntityManager::getEntity(const std::string& entity_name)
{
int counter = 0;
for (auto iter = m_scene_entities.begin(); iter != m_scene_entities.end(); ++iter)
{
if (iter->second[counter]->getId() == entity_name)
return iter->second[counter];
counter++;
}
//What would I return if the entity couldn't be found?
}
The code basically explains it all. I have a method in which if an "entity" is found in the std::vector inside of the map, it will return a reference to the std::shared_ptr type that it is. However, since I'm not returning a pointer, I cannot return nullptr. What could I return in a failure case.
Also, I know that std::shared_ptr is meant for having copies in several different places. For this, do I really need to return a reference or can I just return it by value?
Thanks!
Return the iterator rather than the contents of the iterator. That way you can tell whether you reached the end.
If it is expected that under normal circumstances getEntity will never fail to find the entity, then you should throw an exception.
If you would expect to fail to find some entites, then you can return a default-constructed shared_ptr <SEntity>. Be sure to check for that on the other end.
Remove the return by reference then return an empty shared pointer:
std::shared_ptr<SEntity> SEntityManager::getEntity(const std::string& entity_name) {
for { ... }
return Entity();
}
There's not really a good reason to return the shared pointer by reference. And the shared pointer has a default constructor that's basically the equivalent of nullptr. You can check it in the parent function by testing it as a bool. E.g.:
auto val = getEntity(...);
if (!val) { /* nothing found */ }
I suspect that you need to split tasks. For any normal operation (changing the values of SEntity parameters) you will just need to either return default constructed std::shared_ptr or found entity. No reference needed.
For *replacing the actual contents of shared_ptr* you can have a function like
void SEntityManager::replaceEntity(const std::string& entity_name, Entity* newEntity)
and replace the Entity if its found inside the function.
However, your code still is weird - what if, for example, there are multiple entity_name containing Entities in your vectors ?
I have a function below that searches through a vector of my_type. Currently, it has a compilation warning: control reaches end of non-void function [-Wreturn-type]. It appears that as long as I am using a reference as my return type rather than a pointer, it is not possible to return a null-like value?
struct my_type{
type_a a;
type_b b;
}
type_b& value(type_a& t){
typename std::vector<my_type>::iterator it;
for(it = v.begin(); it != v.end(); ++it){
if ((*it).a == t) return (*it).b;
}
}
It appears that as long as I am using a reference as my return type rather than a pointer, it is not possible to return a null-like value?
Well, yes, but that's not the only issue. References can never be null, but what happens if your if statement never evaluates to true? You don't return anything.
Since references cannot be null, it is not valid to return null. You must return a valid reference from all execution paths.
Also, your code is fragile at best. You are returning a reference to a member of an element in a container... an element that may be moved at any point in the future, making said reference invalid.
The question you have to think about is what should you return if 'nothing' is found when your function has to return my_type. How you handle this directly affects how the caller uses this function and assumptions made.
There are a few ideas you can think about. For example, if your value function returned a pointer type, you could just return NULL to indicate nothing. If it returned a string, you can use an empty string "" or even a special string value like "none" to indicate that. For type_b you can create a special instance of it and just return that instance to indicate nothing. Other functions calling this would check the returned type_b against that instance to see if it's nothing. The point is, there are many ways to go about it and which way you choose is up to you.
But a better approach would be to use what's already provided by the stl -- in particular std::find_if. For example, you can create a functor which specifies when there's a match:
struct find_b
{
const type_a &this_a;
find_b(const type_a &a) : this_a(a) {}
bool operator() (const my_type &lhs)
{
return lhs.a == this_a;
}
};
Then you would use it like this:
item = std::find_if(v.begin(), v.end(), find_b(t));
if(item == v.end()) { /* not found */ }
else { /* found, do something useful here */ }
Im trying to overload the [] operator in c++ so that I can assign / get values from my data structure like a dictionary is used in c#:
Array["myString"] = etc.
Is this possible in c++?
I attempted to overload the operator but it doesnt seem to work,
Record& MyDictionary::operator[] (string& _Key)
{
for (int i = 0; i < used; ++i)
{
if (Records[i].Key == _Key)
{
return Records[i];
}
}
}
Thanks.
Your code is on the right track - you've got the right function signature - but your logic is a bit flawed. In particular, suppose that you go through this loop without finding the key you're looking for:
for (int i = 0; i < used; ++i)
{
if (Records[i].Key == _Key)
{
return Records[i];
}
}
If this happens, your function doesn't return a value, which leads to undefined behavior. Since it's returning a reference, this is probably going to cause a nasty crash the second that you try using the reference.
To fix this, you'll need to add some behavior to ensure that you don't fall off of the end of the function. One option would be to add the key to the table, then to return a reference to that new table entry. This is the behavior of the STL std::map class's operator[] function. Another would be to throw an exception saying that the key wasn't there, which does have the drawback of being a bit counterintuitive.
On a totally unrelated note, I should point out that technically speaking, you should not name the parameter to this function _Key. The C++ standard says that any identifier name that starts with two underscores (i.e. __myFunction), or a single underscore followed by a capital letter (as in your _Key example) is reserved by the implementation for whatever purposes they might deem necessary. They could #define the identifier to something nonsensical, or have it map to some compiler intrinsic. This could potentially cause your program to stop compiling if you move from one platform to another. To fix this, either make the K lower-case (_key), or remove the underscore entirely (Key).
Hope this helps!
On a related note, one of the problems with operator[](const Key& key) is that, as templatetypedef states, in order to return a reference it needs to be non-const.
To have a const accessor, you need a method that can return a fail case value. In STL this is done through using find() and the use of iterators and having end() indicate a fail.
An alternative is to return a pointer, with a null indicating a fail. This is probably justified where the default constructed Record is meaningless. This can be also be done with the array operator:
Record* MyDictionary::operator[] (const string& keyToFind) const
{
for (int i = 0; i < used; ++i)
{
if (Records[i].Key == keyToFind)
{
return &Records[i];
}
}
return 0;
}
There is certainly a view that operator[] should return a reference. In that case, you'd most likely implement find() as well and implement operator[] in terms of it.
To implement find() you need to define an iterator type. The convenient type will depend in implementation. For example, if Records[] is a plain old array:
typedef Record* iterator;
typedef const Record* const_iterator;
const_iterator MyDictionary::end()const
{
return Records + used;
}
const_iterator MyDictionary::begin() const
{
return Records;
}
const_iterator MyDictionary::find(const string& keyToFind) const
{
for (iterator it = begin(); it != end(); ++it)
{
if (it->Key == keyToFind)
{
return it;
}
}
return end();
}