23:38] == vicc [c21d8901@gateway/web/freenode/ip.194.29.137.1] has joined #cplusplus.com
[23:38] <vicc> hello, i got a question
[23:39] <Fabtasticwill> ok
[23:39] <Fabtasticwill> What is it?
[23:39] <SGH> write it out
[23:40] <vicc> i have a class graph and i want to define a operator+ which sums two graphs
[23:40] <vicc> adn here's the question
[23:41] <vicc> should operator+ return an object and make on inside a function
[23:42] <vicc> or should operator+ allocate memory by using 'new' and return a refference
[23:42] <SGH> return an object.
[23:42] <SGH> no new's or references.
[23:43] <vicc> but if my class holds a pointer to a stl container (std list o list exactly), should i overload = operator?
[23:43] <charmander> morning
[23:43] <charmander> what did i walk in one
[23:43] <charmander> *on?
[23:44] <charmander> also, i figured out the issue to my multiple os's
[23:44] <SGH> yes
[23:45] <SGH> if you hold any pointer you've allocated with new or delete, you always need to redefine operator= and copyconstructor.
[23:45] <SGH> if possible, also operator=(T&&) and moveconstructor.
[23:45] <SGH> (move assignment ^)
[23:45] <charmander> and ~class()
[23:46] <vicc> so then, what will be the difference between what operator= and constructor does
[23:46] <SGH> btw holding a pointer on its own is a bad idea
[23:46] <SGH> <<copy>> constructor calls operator=
[23:46] <charmander> i think you have it backwards
[23:46] <SGH> nope
[23:46] <charmander> oh wait never mind
[23:46] <SGH> you can't call a constructor from operator= :p
[23:47] <charmander> im thinking of initialization construction
[23:47] <SGH> and operator= should allocate the pointer (if it wasn't already allocated)
[23:47] <SGH> and assign the container themselves (not the pointers!)
[23:47] <SGH> eg
[23:47] <charmander> also, you probably want to use smart pointers vicc
[23:47] <SGH> *m_vector_pointer = *o.m_vector_pointer;
[23:48] <SGH> or you can avoid using pointers in the first places
[23:48] <SGH> container don't weigh a lot, since they internally store two or three pointers
[23:48] <charmander> geordi << sizeof(std::vector<int>)
[23:48] <+geordi> 56
[23:48] <charmander> o.O
[23:49] <SGH> geordi << sizeof(void*)
[23:49] <+geordi> 8
[23:49] <vicc> i think i got confused a bit
[23:49] <charmander> geordi << sizeof(std::vector<int>) - sizeof(int)
[23:49] <+geordi> 52
[23:49] <SGH> geordi << 52/8
[23:49] <+geordi> 6
[23:49] <SGH> 6 pointers there
[23:49] <charmander> i thought it was like that
[23:49] <charmander> also, nice teamwork
[23:49] <SGH> lol
[23:49] <SGH> oops
[23:49] <SGH> 7 pointers*
[23:49] <SGH> it was 56.
[23:50] <SGH> wait wait
[23:50] <SGH> 56 / 8 = ?
[23:50] <SGH> lol
[23:50] <charmander> is 7
[23:50] <SGH> yes, 7.
[23:50] <SGH> @vicc: using pointers to containers is a bad idea
[23:50] <charmander> vicc: ignore this whole thing. SGH was just confirming something
[23:51] <SGH> you should use something like this, which simplifies everything
[23:51] <charmander> i knew it had to be more than 3. there are also iterators and and allocation things and such
[23:51] <SGH> class myClass { std::vector<int> m_mycontainer; };
[23:51] <charmander> ^
[23:51] <SGH> no allocations needed, no copy constructors or anything
[23:51] <SGH> @charmander: usually they only store begin() and size()
[23:51] <SGH> (end() too for std::list, I believe)
[23:52] <SGH> sounds like libc++ keeps some more.
[23:52] <charmander> they also have reverse iterators
[23:52] == Zereo [~quassel@unaffiliated/zereo] has joined #cplusplus.com
[23:52] <SGH> reverse iterators aren't stored separately
[23:52] <SGH> they simply return a proxy class that stores end() and iterates backwards
[23:52] <charmander> hmm
[23:52] == nrd [~nerdux@190.176.193.190] has quit [Quit: Saliendo]
[23:52] <SGH> but, end() is already stored.
[23:52] <SGH> eg
[23:53] == nerdux [~nerdux@unaffiliated/nrd] has joined #cplusplus.com
[23:53] <charmander> i need to find an std::vector implementation one of these days
[23:53] <SGH> template <typename T> class backward_iterator { T iterator; backward_iterator& operator++(){--iterator; return *this; };
[23:53] <SGH> as you see, they simply override operator++ and negate the effects.
[23:53] <SGH> a little bit more overridden operators, but that's the point.
[23:53] <charmander> ah i see
[23:54] <SGH> @vicc: something you didn't get?
[23:54] <SGH> besides my speak with charmander, which is probably more complex than what you may get atm
[23:55] <charmander> ignore everything from: <SGH> container don't weigh a lot, since they internally store two or three pointers
[23:55] <charmander> to: <SGH> yes, 7.
[23:55] <SGH> hmmm. Just found ~28 Kg of "Dinky the T-Rex Souvenirs"
[23:55] <charmander> dibs
[23:55] <SGH> unsurprisingly, cannot move anymore.
[23:56] <vicc> my std::list of pointers to classes may grow signifantly by adding new verticles. Is is still more effective to hold a container in graph class instead a pointer to it?
[23:58] <SGH> As long as you allocate them, they must be stored somewhere. By storing it as a pointer-to-container, you are simply allocating an extra pointer (and adding the overhead to pointer-tracking mechanics).
[23:58] <SGH> So, you are *also* saving space.
[23:59] <vicc> ok, understood
[00:02] <charmander> i need to update my whiteboard :/
[00:02] <SGH> brb dropping 280 Dinky's in the middle of the road.
[00:02] <SGH> ah... it only drops one ;_;
[00:04] <vicc> but, coming back to previous questions, am i thinking right? : to do something like that: Graph c = a + b; (a,b exist) i should make operator+ to return a Graph object which i create inside a function. Then I overload = operator which copies everything from rvalue to lvalue. What about copy constructor then?
[00:05] <SGH> The copy constructor is created by default, and unless you store pointers, you can use that one.
[00:05] <SGH> as for the operator+, its signature should be something on the lines of:
[00:05] <vicc> i do store pointers
[00:05] <SGH> Graph operator= (Graph const& o) const;
[00:06] <computerquip> https://www.youtube.com/watch?v=nDjz5qHIzsc
[00:06] <+usandbots> [ If Anti-Vaccine Parents Rode The Magic School Bus - YouTube ]
[00:06] <SGH> er, operator+ *
[00:06] <SGH> if you do store pointers, your copy constructor should "new" them
[00:06] <SGH> e.g.
[00:06] <SGH> Graph::Graph(Graph const& o) { m_pointer = new PointedType(); *m_pointer = *(o.m_pointer); }
[00:07] <SGH> Or...
[00:07] <SGH> You can first allocate all pointers, then call operator=
[00:07] <SGH> Graph::Graph(Graph const& o) { m_pointer = new PointedType(); m_pointer2 = new PointedType2(); (*this) = o; }
[00:07] <SGH> And your operator= simply copies the pointee values as follows
[00:08] <SGH> Graph& Graph::operator= (Graph const& o) { *m_pointer = *(o.m_pointer); *m_pointer2 = *(o.m_pointer2); return *this; }
[00:08] <SGH> Of course your default constructor must allocate these pointers as well, as follows:
[00:08] <SGH> Graph::Graph() { m_pointer = new PointedType(); m_pointer2 = new PointedType2(); }
[00:09] <SGH> If you care enough, you can initialize them via "initializer lists". Not sure if you know them.
[00:09] <SGH> It simply changes the syntax a bit. They only work with constructors, as follows:
[00:09] <SGH> Graph::Graph() : m_pointer(new PointedType()), m_pointer2(new PointedType2()) {}
[00:10] <SGH> Graph::Graph(Graph const& o) : m_pointer(new PointedType()), m_pointer2(new PointedType2()) {*this = o;}