i have a priority queue that stores shared_ptr<obj>. in these obj's there is a method that returns a certain value e.g obj.method1() would return an int. I want to order the queue in ascending order of this value. I tried writing a compare class in the same file but when i add it in as the 3rd parameter it says use of undeclared identifier(I don't have access to the main function that actually runs the code) I also tried using std::greater<shared_ptr<Searchable>> as the 3rd parameter, but I'm not sure if that was the write solution. any help would be appreciated.
priority_queue<shared_ptr<obj>, vector<shared_ptr<obj>>, std::greater<shared_ptr<obj>> > Q;
That is what i have right now but i dont think its working like i wanted it to
Does this work for you?
#include <memory>
#include <queue>
#include <vector>
class obj {
public:
int method1() const { return 123; }
};
using obj_ptr = std::shared_ptr<obj>;
class obj_ptr_comparator {
int operator()(const obj_ptr& lhs, const obj_ptr& rhs)
{
return lhs.get()->method1() < rhs.get()->method1();
}
};
std::priority_queue<obj_ptr, std::vector<obj_ptr>, obj_ptr_comparator> my_queue;
To clarify: The item you'll get with a my_queue.pop() will be the one with the highest value of method1() (because we're essentially running std::less, the default comparator, on the method1() value instead of the shared pointer). See also the cppreference.com entry on std::priority_queue.
Related
Briefly, I have a class that lazily initializes one of its data members and I'd like to figure out the best way to do this in a multithreaded environment.
In more detail, my class currently looks something like this:
#include <algorithm>
#include <optional>
#include <vector>
class A_single_threaded
{
public:
bool query(const int val) const
{
// if opt_vec is not initialized, do that now
if (!(opt_vec.has_value()))
initialize_vec();
// return true if opt_vec contains val
return std::find(std::cbegin(opt_vec), std::cend(opt_vec), val) != std::cend(opt_vec);
}
private:
mutable std::optional<std::vector<int>> opt_vec;
// sets opt_vec
void initialize_vec() const;
};
initialize_vec is the only method that modifies opt_vec, and query is the only method that calls initialize_vec. opt_vec can potentially be empty after initialize_vec returns, so giving the data member std::optional type helps distinguish when it's unset and when it's set and empty. In other instances opt_vec winds up being large and initializing it is time-consuming. And since not every A_single_threaded instance will need to run query anyway, it makes sense to avoid initializing opt_vec until a user call to query makes clear that initialization is necessary.
The approach above seems OK for a single thread, but I think it isn't naturally multithread-able. The calls to opt_vec.has_value() and initialize_vec are necessarily unsynchronized, and the gap between their return times allows for a data race that I don't think can be fixed with a mutex. Instead I think the correct solution involves replacing the std::optional with std::call_once, something like the below:
#include <algorithm>
#include <mutex>
#include <vector>
class A_multi_threaded
{
public:
bool query(const int val) const
{
// if opt_vec is not initialized, do that now
std::call_once(opt_vec_flag, initialize_vec, this);
// return true if opt_vec contains val
return std::find(std::cbegin(opt_vec), std::cend(opt_vec), val) != std::cend(opt_vec);
}
private:
mutable std::vector<int> opt_vec;
mutable std::once_flag opt_vec_flag;
// sets opt_vec
void initialize_vec() const;
};
I'd appreciate answers to a couple of questions:
Is the implementation I sketched for A_multi_threaded actually thread-safe?
Will A_multi_threaded have the same behavior as A_single_threaded in a single-threaded environment?
Is there a sensible implementation of A_multi_threaded that mimics the implementation of A_single_threaded?
Say I have the following classes:
#include <string>
class Item {
public:
Item(std::string name, int id);
virtual int getWeight() = 0;
protected:
std::string name;
const int id;
}
#include <vector>
#include <memory>
#include "Item.h"
class Bucket : Item {
public:
Bucket(std::string name, std::string type, int id) // In the implementation this will call the Constructor of Item
bool operator<(const Bucket& b) const {
return (id < b.id );
}
void addItem(std::shared_ptr<Item> itemm) {
this->weight += item->getWeight();
this->items.push_back(item);
}
int getWeight() override; //this implementation does not matter to the problem
private:
std::string type;
std::vector<std::shared_ptr<Item>> items;
int weight = 0;
}
There are other classes inheriting from class Item aswell, but to make it easier I am only showing the class Bucket.
Now in my main method, I want to iterate over a map, that already contains some entries and call a method that changes one property of the key object.
main.cpp:
#include <map>
#include <memory>
#include <vector>
#include "Item.h"
#include "Bucket.h"
using namespace std;
int main(){
map<Bucket, vector<shared_ptr<Item>>> map; // Imagine this map has some entries
for(auto itr = map.begin(); itr != map.end(); itr++){
for_each(itr->second.begin(), itr->second.begin(), [&itr](shared_ptr<Item> item){
itr->first.addItem(item); // This does not compile, the error will be in the text below
});
}
As told in the code, it does not compile with the following error on line itr->first.addItem(item);:
'this' argument to member function 'addItem' has type 'const Bucket', but function is not marked const.
I can't make the method const, since it is changeing some property of the object and I would get an error there.
I am not sure if I understand this error correctly, but I think the problem is, that as I put a Bucket into a map (Bucket is the key), it becomes const.
If that is the case, is there a way to tell the compiler to use only the id property of Bucket as the const key of the map (Without changeing the map to something like map<int, <pair<Bucket,vector<shared_ptr<Item>>>>>)? Or am I not understanding the main problem here?
I think the problem is, that as I put a Bucket into a map (Bucket is the key), it becomes const
Correct. Maps are supposed to be ordered, and if you were able to mutate a key, you could break this invariant. Doing this would potentially break every subsequent search or insert horribly.
The linked workaround is effective, but ugly. Unless map-key-ness is a core feature of your Bucket (I can't tell from the sample code whether that's likely), making some of its members mutable feels like a hack.
Your whole design looks odd, tbh - you're going to end up with a map full of Bucket keys that duplicate the information in the second half of the key,value pair. Are you going to move those Buckets somewhere else afterwards, or are they going to live forever shackled to those vestigial vectors of redundant references?
If that map is an intermediate step in building up connections, it shouldn't be where the Bucket objects live. Perhaps you should have one main lookup map<id, Item>, another transient mapping multimap<id, id> describing which Item contains which other Items.
I want to build a simple iterator, for example - in the class: "myVector":
#include <iostream>
using namespace std;
#define maxSize 10
class myVector {
private:
int *arr;
int sp;
public:
myVector() {
arr = new int[maxSize];
sp = 0;
}
bool add(int num) {
if (sp==maxSize) return 0;
arr[sp] = num;
sp++;
return 1;
}
};
in the Example - I built a class that produces objects of type myVector. Now I want to build iterator with an operator ++ to run on the private Array of the vector.
thank you very much
You must support std::iterator_traits<YourIterator>. The easy way is to inherit from std::iterator<?> with the appropiate arguments.
In doing so you have to decide on an iterator category. This determines what you guarantee to support, both operator wise and behaviour wise.
Now, boost has some helper types to make writing an iterator a tad easier. Consider using boost. But a basic iterator is not impossible to write without them.
In the particular case above, a pointer is a valid iterator for your problem. And easier than either of the above options. Use this as your first iteration: KISS. Note that pointers have std::iterator_traits support for free.
To make your object iterable (and support for(auto&&x:c) syntax), either write a free begin and end function in the same namespace as your class that produces iterators, or add begin() and end() methods that do the same. I tend to also add size and empty and front and back as I find them useful. As an example:
T& back(){return *std::prev(end());}
T const& back()const{return *std::prev(end());}
You need to write something like this.
class myVector {
class myIterator {
private:
int *position; //operator ++ increment this position
public:
myIterator operator++(){
//increment position here
}
int& operator*(){
//return *pos
}
bool operator==(const myIterator &it)const {
//check that pos and it.pos are the same
}
};
};
This will work but wont be a STL compliant iterator, for that you will also need to add several typedefs, to say for instance the type of your iterator (in your case you have an input iterator). If you want an STL iterator the easiest thing is to use boost facade iterator.
I am trying to do declare a stl map with template parameters like so:
( assume T as typename like so : template <class T>)
map<T, T> m; ( in .h file )
It compiles fine. now in my cpp file, when I want to insert into the map, i am not able to. The only methods i get on intellisense are "at" and "swap" methods.
Any ideas? Anyone please?
Thanks in advance.
here is sample code:
#pragma once
#include <iostream>
#include <map>
using namespace std;
template <class T>
class MySample
{
map<T, T> myMap;
//other details omitted
public:
//constructor
MySample(T t)
{
//here I am not able to use any map methods.
//for example i want to insert some elements into the map
//but the only methods I can see with Visual Studio intellisense
//are the "at" and "swap" and two other operators
//Why???
myMap.
}
//destructor
~MySample(void)
{
}
//other details omitted
};
The usual ways to insert key-value pairs into a std::map are the index-operator syntax as well as the insert function. I'll assume std::string for keys and int for values for the sake of the example:
#include <map>
#include <string>
std::map<std::string,int> m;
m["hello"] = 4; // insert a pair ("hello",4)
m.insert(std::make_pair("hello",4)); // alternative way of doing the same
If you can use C++11, you may use the new uniform initialization syntax instead of the make_pair call:
m.insert({"hello",4});
And, as said in the comments, there is
m.emplace("hello",4);
in C++11, which constructs the new key-value pair in-place, rather than constructing it outside the map and copying it in.
I should add that since your question is actually about initialization, rather than inserting fresh elements, and given that indeed you do this in the constructor of MyClass, what you should really do (in C++11) is this:
MySample(T t)
: myMap { { t,val(t) } }
{}
(Here I assume there is some function val which generates the value to store for t in the map.)
Consider the following class member:
std::vector<sim_mob::Lane *> IncomingLanes_;
the above container shall store the pointer to some if my Lane objects. I don't want the subroutins using this variable as argument, to be able to modify Lane objects.
At the same time, I don't know where to put 'const' keyword that does not stop me from populating the container.
could you please help me with this?
thank you and regards
vahid
Edit:
Based on the answers i got so far(Many Thanks to them all) Suppose this sample:
#include <vector>
#include<iostream>
using namespace std;
class Lane
{
private:
int a;
public:
Lane(int h):a(h){}
void setA(int a_)
{
a=a_;
}
void printLane()
{
std::cout << a << std::endl;
}
};
class B
{
public:
vector< Lane const *> IncomingLanes;
void addLane(Lane *l)
{
IncomingLanes.push_back(l);
}
};
int main()
{
Lane l1(1);
Lane l2(2);
B b;
b.addLane(&l1);
b.addLane(&l2);
b.IncomingLanes.at(1)->printLane();
b.IncomingLanes.at(1)->setA(12);
return 1;
}
What I meant was:
b.IncomingLanes.at(1)->printLane()
should work on IncomingLanes with no problem AND
b.IncomingLanes.at(1)->setA(12)
should not be allowed.(In th above example none of the two mentioned methods work!)
Beside solving the problem, I am loking for good programming practice also. So if you think there is a solution to the above problem but in a bad way, plase let us all know.
Thaks agian
A detour first: Use a smart pointer such shared_ptr and not raw pointers within your container. This would make your life a lot easy down the line.
Typically, what you are looking for is called design-const i.e. functions which do not modify their arguments. This, you achieve, by passing arguments via const-reference. Also, if it is a member function make the function const (i.e. this becomes const within the scope of this function and thus you cannot use this to write to the members).
Without knowing more about your class it would be difficult to advise you to use a container of const-references to lanes. That would make inserting lane objects difficult -- a one-time affair, possible only via initializer lists in the ctor(s).
A few must reads:
The whole of FAQ 18
Sutter on const-correctness
Edit: code sample:
#include <vector>
#include <iostream>
//using namespace std; I'd rather type the 5 characters
// This is almost redundant under the current circumstance
#include <vector>
#include <iostream>
#include <memory>
//using namespace std; I'd rather type the 5 characters
// This is almost redundant under the current circumstance
class Lane
{
private:
int a;
public:
Lane(int h):a(h){}
void setA(int a_) // do you need this?
{
a=a_;
}
void printLane() const // design-const
{
std::cout << a << std::endl;
}
};
class B
{
// be consistent with namespace qualification
std::vector< Lane const * > IncomingLanes; // don't expose impl. details
public:
void addLane(Lane const& l) // who's responsible for freeing `l'?
{
IncomingLanes.push_back(&l); // would change
}
void printLane(size_t index) const
{
#ifdef _DEBUG
IncomingLanes.at( index )->printLane();
#else
IncomingLanes[ index ]->printLane();
#endif
}
};
int main()
{
Lane l1(1);
Lane l2(2);
B b;
b.addLane(l1);
b.addLane(l2);
//b.IncomingLanes.at(1)->printLane(); // this is bad
//b.IncomingLanes.at(1)->setA(12); // this is bad
b.printLane(1);
return 1;
}
Also, as Matthieu M. suggested:
shared ownership is more complicated because it becomes difficult to
tell who really owns the object and when it will be released (and
that's on top of the performance overhead). So unique_ptr should be
the default choice, and shared_ptr a last resort.
Note that unique_ptrs may require you to move them using std::move. I am updating the example to use pointer to const Lane (a simpler interface to get started with).
You can do it this way:
std::vector<const sim_mob::Lane *> IncomingLanes_;
Or this way:
std::vector<sim_mob::Lane const *> IncomingLanes_;
In C/C++, const typename * and typename const * are identical in meaning.
Updated to address updated question:
If really all you need to do is
b.IncomingLanes.at(1)->printLane()
then you just have to declare printLane like this:
void printLane() const // Tell compiler that printLane doesn't change this
{
std::cout << a << std::endl;
}
I suspect that you want the object to be able to modify the elements (i.e., you don't want the elements to truly be const). Instead, you want nonmember functions to only get read-only access to the std::vector (i.e., you want to prohibit changes from outside the object).
As such, I wouldn't put const anywhere on IncomingLanes_. Instead, I would expose IncomingLanes_ as a pair of std::vector<sim_mob::Lane *>::const_iterators (through methods called something like GetIncomingLanesBegin() and GetIncomingLanesEnd()).
you may declare it like:
std::vector<const sim_mob::Lane *> IncomingLanes_;
you will be able to add, or remove item from array, but you want be able to change item see bellow
IncomingLanes_.push_back(someLine); // Ok
IncomingLanes_[0] = someLine; //error
IncomingLanes_[0]->some_meber = someting; //error
IncomingLanes_.erase(IncomingLanes_.end()); //OK
IncomingLanes_[0]->nonConstMethod(); //error
If you don't want other routines to modify IncomingLanes, but you do want to be able to modify it yourself, just use const in the function declarations that you call.
Or if you don't have control over the functions, when they're external, don't give them access to IncomingLanes directly. Make IncomingLanes private and provide a const getter for it.
I don't think what you want is possible without making the pointers stored in the vector const as well.
const std::vector<sim_mob::Lane*> // means the vector is const, not the pointer within it
std::vector<const sim_mob::Lane*> // means no one can modify the data pointed at.
At best, the second version does what you want but you will have this construct throughout your code where ever you do want to modify the data:
const_cast<sim_mob::Lane*>(theVector[i])->non_const_method();
Have you considered a different class hierarchy where sim_mob::Lane's public interface is const and sim_mob::Really_Lane contains the non-const interfaces. Then users of the vector cannot be sure a "Lane" object is "real" without using dynamic_cast?
Before we get to const goodness, you should first use encapsulation.
Do not expose the vector to the external world, and it will become much easier.
A weak (*) encapsulation here is sufficient:
class B {
public:
std::vector<Lane> const& getIncomingLanes() const { return incomingLanes; }
void addLane(Lane l) { incomlingLanes.push_back(l); }
private:
std::vector<Lane> incomingLanes;
};
The above is simplissime, and yet achieves the goal:
clients of the class cannot modify the vector itself
clients of the class cannot modify the vector content (Lane instances)
and of course, the class can access the vector content fully and modify it at will.
Your new main routine becomes:
int main()
{
Lane l1(1);
Lane l2(2);
B b;
b.addLane(l1);
b.addLane(l2);
b.getIncomingLanes().at(1).printLane();
b.getIncomingLanes().at(1).setA(12); // expected-error\
// { passing ‘const Lane’ as ‘this’ argument of
// ‘void Lane::setA(int)’ discards qualifiers }
return 1;
}
(*) This is weak in the sense that even though the attribute itself is not exposed, because we give a reference to it to the external world in practice clients are not really shielded.