Tuesday, April 28, 2009

comp.lang.c++ - 25 new messages in 11 topics - digest

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

* Deitel &Deitel How to Program C++ 6th Edition full Code solutions contact
allsolutionmanuals11[at]gmail.com - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/bfe24e37a5338ca1?hl=en
* free shipping >>>><<<<Discount replica handbags/ purse True leather AAA
Wholesale (www.guoshitrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/41ae19ceddfc6bd5?hl=en
* Convert to Polymorphism? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/cbec0c1159ff53e8?hl=en
* shared_ptr<T> vs intrusive_ptr<T> - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/21e163bb0245b408?hl=en
* open Souce project in C/C++/Java to convert html, doc, pdf to BMP - 2
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/f238b5078d593099?hl=en
* parallel computing in C++ - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/d9c643de979b9a57?hl=en
* Polymorphism at run-time - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/afb5fdfa6ae286c5?hl=en
* weak_ptr to break cyclic reference - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/22cce0d9cb47fd83?hl=en
* Casting STL's const_iterator to iterator - 3 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/654ce7efa055d1fc?hl=en
* Just want to make sure... - 7 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/a9a8c2c7a4f70ad7?hl=en
* Is it legal to directly call a constructor? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/562e9b8fa0a08333?hl=en

==============================================================================
TOPIC: Deitel &Deitel How to Program C++ 6th Edition full Code solutions
contact allsolutionmanuals11[at]gmail.com
http://groups.google.com/group/comp.lang.c++/t/bfe24e37a5338ca1?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Apr 28 2009 9:36 am
From: Immortal Nephi


On Apr 28, 9:54 am, "Pearson & prentice hall solutions"
<allsolutionmanual...@gmail.com> wrote:
> Deitel &Deitel How to Program C++  6th E d fullCode solutions
> contact allsolutionmanuals11[at]gmail.com

Please respect Deitel's Copyright. Stop selling all key answers on
full code illegally. It is considered to be scam. Do not post to
comp.lang.c++.

==============================================================================
TOPIC: free shipping >>>><<<<Discount replica handbags/ purse True leather AAA
Wholesale (www.guoshitrade.com)
http://groups.google.com/group/comp.lang.c++/t/41ae19ceddfc6bd5?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Apr 28 2009 9:51 am
From: "wholesale free shipping www.guoshitrade.com"


I am a Super seller , i also do the business on Ebay with oversea
friends which come from the world.I have many suppliers in china.So I
can supply you
good items,low price, quick of deliver, win friends to trust me!The
hope can become your forever friend.
Our Bag Purse have:
Discount VERSACE True leather AAA Wholesale (www.guoshitrade.com)
Discount VERSACE bags Wholesale (www.guoshitrade.com)
Discount Chanel Purse Wholesale (www.guoshitrade.com)
Discount CHANEL bags Wholesale (www.guoshitrade.com)
Discount CHANEL True leather AAA Wholesale (www.guoshitrade.com)
Discount PRADA Purse Wholesale (www.guoshitrade.com)
Discount PRADA bags Wholesale (www.guoshitrade.com)
Discount PRADA True leather AAA Wholesale (www.guoshitrade.com)
Discount GUCCI Purse Wholesale (www.guoshitrade.com)
Discount GUCCI True leather AAA Wholesale (www.guoshitrade.com)
Discount Gucci bags Wholesale (www.guoshitrade.com)
Discount Gucci Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount Gucci bag Wholesale (www.guoshitrade.com)
Discount BURBERRY Purse Wholesale (www.guoshitrade.com)
Discount BURBERRY bags Wholesale (www.guoshitrade.com)
Discount pauesmitl bags Wholesale (www.guoshitrade.com)
Discount HERMES True leather AAA Wholesale (www.guoshitrade.com)
Discount HERMES Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount HERMES bags Wholesale (www.guoshitrade.com)
Discount LV bags Wholesale (www.guoshitrade.com)
Discount LV Purse True leather AAA Wholesale (www.guoshitrade.com)
Discount LV Purse Wholesale (www.guoshitrade.com)
Discount LV True leather AAA Wholesale (www.guoshitrade.com)
Discount D&G bag Wholesale (www.guoshitrade.com)
Discount D&G Purse Wholesale (www.guoshitrade.com)
Discount D&G bags Wholesale (www.guoshitrade.com)
Discount D&G Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount ED Purse Wholesale (www.guoshitrade.com)
Discount EDHardy bags Wholesale (www.guoshitrade.com)
Discount UGG bag Wholesale (www.guoshitrade.com)
Discount CHLOE True leather AAA Wholesale (www.guoshitrade.com)
Discount CHLOE bags Wholesale (www.guoshitrade.com)
Discount Chloe Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount JIMMY CHOO Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount JIMMYTOO bags Wholesale (www.guoshitrade.com)
Discount JIMMY THOO True leather AAA Wholesale
(www.guoshitrade.com)
Discount paul smith bags Wholesale (www.guoshitrade.com)

More detail land, address:www.guoshitrade.com

==============================================================================
TOPIC: Convert to Polymorphism?
http://groups.google.com/group/comp.lang.c++/t/cbec0c1159ff53e8?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Apr 28 2009 10:10 am
From: Salt_Peter


On Apr 27, 10:57 pm, Immortal Nephi <Immortal_Ne...@hotmail.com>
wrote:
> Each derived classes are derived from class A through virtual
> multiple inheritance. Only class E is defined. Each data members and
> member functions are inherited into class E from one base class and
> all derived classes.

Thats a misconception. your derived class (E) is not selectively
inheriting members and functions from its base class(es). What it does
inherit is their accessible interfaces.

Otherwise, an instance of class E -is- an instance of the base class
(es), through and through. Think of an egg where the yellow yolk is
the base class portion of the object.

Instead of inherit, think transposition.

> Each derived classes have the same Run() member function name, but
> different implementation. The variable of pFunc_E is a pointer to Run
> () member function. It does not have pointer to member function array
> because I want to reassign any Run() member function to pFunc_E at run-
> time execution.
> pFunc_E is like dispatch function. Inheritance is the answer to
> divide from one large base class into derived sub-classes (from one
> large source code to multiple source code for better readability).
> Class E is used to communicate to all sub-classes.
> Please tell me if one object with multiple sub-classes good design.
> If not, can it be converted to polymorphism? Run() can be set to pure
> virtual function in class A and (non-pure) virtual functions to all
> derived sub-classes. What is your advice? Please give me your
> example if you can. Thanks…

google for NVI (non-virtual idiom)

You should read the faq on diamond inheritance as well.
http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

>
> class E;
>
> class A
> {
> public:
> A();
> ~A();
> void Run_A();
> void (E::*pFunc_E)();
> void Test();
>
> };
>
> class B1 : virtual public A
> {
> public:
> B1();
> ~B1();
> void Run_B1();
>
> };
>
> class B2 : virtual public A
> {
> public:
> B2();
> ~B2();
> void Run_B2();
>
> };
>
> class B3 : virtual public A
> {
> public:
> B3();
> ~B3();
> void Run_B3();
>
> };
>
> class B4 : virtual public A
> {
> public:
> B4();
> ~B4();
> void Run_B4();
>
> };
>
> class C1 : virtual public B1, virtual public B2, virtual public B3,
> virtual public B4
> {
> public:
> C1();
> ~C1();
> void Run_C1();
>
> };
>
> class C2 : virtual public B1, virtual public B2, virtual public B3,
> virtual public B4
> {
> public:
> C2();
> ~C2();
> void Run_C2();
>
> };
>
> class C3 : virtual public B1, virtual public B2, virtual public B3,
> virtual public B4
> {
> public:
> C3();
> ~C3();
> void Run_C3();
>
> };
>
> class D1 : virtual public C1, virtual public C2, virtual public C3
> {
> public:
> D1();
> ~D1();
> void Run_D1();
>
> };
>
> class D2 : virtual public C1, virtual public C2, virtual public C3
> {
> public:
> D2();
> ~D2();
> void Run_D2();
>
> };
>
> class E : virtual public D1, virtual public D2
> {
> public:
> E();
> ~E();
> void Run_E();
>
> };
>
> A::A() {}
> A::~A() {}
> void A::Run_A() {}
> void A::Test() {}
>
> B1::B1() {}
> B1::~B1() {}
> void B1::Run_B1() { pFunc_E = &B2::Run_B2; }
>
> B2::B2() {}
> B2::~B2() {}
> void B2::Run_B2() { pFunc_E = &B3::Run_B3; }
>
> B3::B3() {}
> B3::~B3() {}
> void B3::Run_B3() { pFunc_E = &B4::Run_B4; }
>
> B4::B4() {}
> B4::~B4() {}
> void B4::Run_B4() { pFunc_E = &C1::Run_C1; }
>
> C1::C1() {}
> C1::~C1() {}
> void C1::Run_C1() { pFunc_E = &C2::Run_C2; }
>
> C2::C2() {}
> C2::~C2() {}
> void C2::Run_C2() { pFunc_E = &C3::Run_C3; }
>
> C3::C3() {}
> C3::~C3() {}
> void C3::Run_C3() { pFunc_E = &D1::Run_D1; }
>
> D1::D1() {}
> D1::~D1() {}
> void D1::Run_D1() { pFunc_E = &D2::Run_D2; }
>
> D2::D2() {}
> D2::~D2() {}
> void D2::Run_D2() { pFunc_E = &B1::Run_B1; }
>
> E::E() {}
> E::~E() {}
> void E::Run_E() {}
>
> int main()
> {
> E e[3];
>
> e[0].pFunc_E = &B1::Run_B1;
> e[1].pFunc_E = &B1::Run_B1;
> e[2].pFunc_E = &B1::Run_B1;
>
> for (int y = 0; y < 3; y++)
> {
> for (int x = 0; x < 10; x++)
> (e[y].*(e[y].pFunc_E))();
> }
>
> system("pause");
>
> return 0;
>
> }

Complicated designs, specially multiple diamond inheritance meshes
will fail. Simplicity is beautifull. Stick to the basics, in this
case, note the base constructor A() invoked in the derived class's
init list ( C() : A() { ... } // invoke A() ).

#include <iostream>

class A
{
public:
A() { std::cout << "A()\n"; }
virtual ~A() { std::cout << "~A()\n"; }
protected:
virtual void VirtualRun()
{
std::cout << "A::VirtualRun()\n";
}
public:
void Run() { A::VirtualRun(); }
void PolyRun() { VirtualRun(); }
};

class B1 : public virtual A
{
protected:
void VirtualRun() { std::cout << "B1::VirtualRun()\n"; }
public:
void Run() { B1::VirtualRun(); }
};

class B2 : public virtual A
{
protected:
void VirtualRun() { std::cout << "B2::VirtualRun()\n"; }
public:
void Run() { B2::VirtualRun(); }
};

class C : public B1, public B2
{
public:
C() : A() { std::cout << "C()\n"; } // invoke A()
~C() { std::cout << "~C()\n"; }
protected:
void VirtualRun() { std::cout << "C::VirtualRun()\n"; }
public:
void Run() { VirtualRun(); }
void Run_A() { A::Run(); }
void Run_B1() { B1::Run(); }
void Run_B2() { B2::Run(); }
void Run_all()
{
A::Run();
B1::Run();
B2::Run();
Run();
}
};

int main()
{
C c;
c.Run_all();

A* const p_a = &c;
p_a->Run(); // calls A::VirtualRun()

// calls most derived VirtualRun()
// whatever that might be
p_a->PolyRun();

}

/*
A()
C()
A::VirtualRun()
B1::VirtualRun()
B2::VirtualRun()
C::VirtualRun()
A::VirtualRun() // p_a->Run()
C::VirtualRun() // p_a->PolyRun()
~C()
~A()
*/


==============================================================================
TOPIC: shared_ptr<T> vs intrusive_ptr<T>
http://groups.google.com/group/comp.lang.c++/t/21e163bb0245b408?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Apr 28 2009 10:14 am
From: Pallav singh


Hi All ,

what is the difference between shared_ptr<T> and intrusive_ptr<T> in
Boost smart pointers ?

Thanks
Pallav singh


== 2 of 2 ==
Date: Tues, Apr 28 2009 10:24 am
From: Noah Roberts


Pallav singh wrote:
> Hi All ,
>
> what is the difference between shared_ptr<T> and intrusive_ptr<T> in
> Boost smart pointers ?

intrusive_ptr has requirements with regard to T such that it actually
tracks references in the objects pointed to.

==============================================================================
TOPIC: open Souce project in C/C++/Java to convert html, doc, pdf to BMP
http://groups.google.com/group/comp.lang.c++/t/f238b5078d593099?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Apr 28 2009 10:34 am
From: prashanthegde81@gmail.com


Hi All

Is there any open Souce project in C/C++/Java to convert html, doc,
pdf to BMP?

I would like to get the Bitmap image of contents rendered in the Web
Browser ActiveX control. I want to get the good quality image so I
don't want to use images from the view (rendered content).

Is there any alternate method?

Please Help...

Thanks in Advance.

== 2 of 2 ==
Date: Tues, Apr 28 2009 11:44 am
From: Marcel Müller


Hi!

prashanthegde81@gmail.com wrote:
> Is there any open Souce project in C/C++/Java to convert html, doc,
> pdf to BMP?

Probably yes. Any FAX server will do that. (In fact the rendering is
done in two steps, first by the native application for a format, secondly


> I would like to get the Bitmap image of contents rendered in the Web
> Browser ActiveX control.

? - Download the referenced content as file and send it to a FAX server.
As long as you restrict to html, doc, pdf sources the solution should be
straight forward. The most complicated thing will be doc, because it
requires an office application like Word or OpenOffice. They are not
very reliable in automation mode. And HTML output is ambiguous because
of factors like page width and font scaling. PDF is quite easy.
Ghostscript will do the Job.


Marcel

==============================================================================
TOPIC: parallel computing in C++
http://groups.google.com/group/comp.lang.c++/t/d9c643de979b9a57?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Apr 28 2009 10:43 am
From: SaticCaster


OpenMP Parallel Programming
http://www.viva64.com/links/parallel-programming/


== 2 of 3 ==
Date: Tues, Apr 28 2009 1:13 pm
From: "Chris M. Thomasson"


"Jeff Schwab" <jeff@schwabcenter.com> wrote in message
news:abSdnQBDqaF4YGvUnZ2dnUVZ_tBi4p2d@giganews.com...
> Chris M. Thomasson wrote:
>> "Rui Maciel" <rui.maciel@gmail.com> wrote in message
>> news:49f63d4b$0$29372$a729d347@news.telepac.pt...
>>> Jeff Schwab wrote:
>>>
>>>> It's very low-level, and does not provide most of the tools one need
>>>> for
>>>> real-world parallel processing: thread pools
>>>
>>> Isn't that a common design pattern that is easy to implement?
>>
>> Of course.
>
> Not really.

You can create full-blown lock-based work-stealing schedulers in POSIX that
have pretty darn good scalability. Wait-free work-stealing algorithms are
another story... Here is a pretty good one:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/8ad297f61b369a41


> In particular, assigning tasks to threads at random kills cache coherency
> and performance.

That depends on several factors. Anyway, a simple way to get good cache
performance is to batch up similar actions together and execute them all on
a single CPU:

http://www.usenix.org/events/usenix02/full_papers/larus/larus.pdf


> You can write "a thread pool," but it takes multiple person-months to get
> something competitive with COTS solutions.

Sometimes. Intel TBB and Clik++ are both based on work-stealing, and those
algorihtms are not rocket science, IMVHO of course...

== 3 of 3 ==
Date: Tues, Apr 28 2009 2:13 pm
From: "Chris M. Thomasson"


"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:gt7o07$1qgm$1@news.ett.com.ua...
> "Jeff Schwab" <jeff@schwabcenter.com> wrote in message
>>
>> You can write "a thread pool," but it takes multiple person-months to get
>> something competitive with COTS solutions.
>
> Sometimes. Intel TBB and Clik++ are both based on work-stealing, and those
> algorihtms are not rocket science, IMVHO of course...


However, COTS are OH SO CONVENIENT. AFAICT, Intel TBB is a very good choice.

:^)


==============================================================================
TOPIC: Polymorphism at run-time
http://groups.google.com/group/comp.lang.c++/t/afb5fdfa6ae286c5?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Apr 28 2009 11:10 am
From: Jeff Schwab


Steven G. Johnson wrote:
> On Apr 27, 9:13 am, Jeff Schwab <j...@schwabcenter.com> wrote:
>> No can do, unless you're willing to generate and compile a separate
>> program, on the fly, at run-time. There are programs that do so with
>> spectacular success (e.g.FFTW), but it's probably not what you need.
>
> (FFTW does not do runtime code generation; all of its code is
> generated before compilation. At runtime, it only looks at different
> combinations and calling sequences of the compiled code.)

Well, far be it for me to argue with the you on this topic, but what
genfft does, IIUC, is effectively run-time code generation of the sort
usually restricted to interpreted languages. If you call the compiler
on the client machine, you're defying the traditional compile-then-run
ordering. It's a nice technique, and I'd like to see it used more often.

==============================================================================
TOPIC: weak_ptr to break cyclic reference
http://groups.google.com/group/comp.lang.c++/t/22cce0d9cb47fd83?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Apr 28 2009 11:53 am
From: Pallav singh


Hi All

How to use weak_ptr to break cyclic reference here ?

#include <iostream>
#include <boost/smart_ptr.hpp>
using namespace std;

struct Dad;
struct Child;

typedef boost::shared_ptr<Dad> DadPtr;
typedef boost::shared_ptr<Child> ChildPtr;


struct Dad
{
ChildPtr myBoy;
};

struct CChild
{
DadPtr myDad;
};

// a "thing" that holds a smart pointer to another "thing":
DadPtr parent(new DadPtr);
ChildPtr child(new ChildPtr);

// deliberately create a circular reference:
parent->myBoy = child;
child->myDad = dad;

Thanks
Pallav Singh


== 2 of 2 ==
Date: Tues, Apr 28 2009 12:10 pm
From: Marcel Müller


Hi,

Pallav singh wrote:
> // a "thing" that holds a smart pointer to another "thing":
> DadPtr parent(new DadPtr);
> ChildPtr child(new ChildPtr);
>
> // deliberately create a circular reference:
> parent->myBoy = child;
> child->myDad = dad;

If your child objects have an existence dependency on their parents you
can safely use a weak pointer from child to parent.


Marcel

==============================================================================
TOPIC: Casting STL's const_iterator to iterator
http://groups.google.com/group/comp.lang.c++/t/654ce7efa055d1fc?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Apr 28 2009 12:03 pm
From: Nick Overdijk


Daniel T. wrote:
> In article <49f62a9e$0$92442$dbd4d001@news.wanadoo.nl>,
> Nick Overdijk <nick@dotsimplicity.net> wrote:
>
>> How would I cast a const_iterator to a normal iterator? For example:
>>
>> template <typename T1, typename T2>
>> typename multimap<T1, T2>::iterator &get_indexed_it(const
>> multimap<T1, T2> &container, const T1 &key, size_t index = 0) const
>> throw (out_of_range) {
>> size_t count = container.count(key);
>>
>> if (count != 0 && count-1 >= index) {
>> typename multimap<T1, T2>::const_iterator it =
>> container.find(key);
>> while (index--) it++;
>> return const_cast<typename multimap<T1, T2>::iterator&>
>> (it);
>> } else {
>> throw out_of_range((string)"get_indexed_it->"+"Element
>> " + key + "doesn't exist!");
>> }
>> }
>>
>> MinGW GCC on compiling says:
>> D:\MyDocs\Code\SSSParser\sss.hpp|155|error: invalid const_cast from type
>> `std::_Rb_tree_const_iterator<std::pair<const std::string, sss::node> >'
>> to type `std::_Rb_tree_iterator<std::pair<const std::string, sss::node> >&'|
>>
>> I'm guessing this is because const_iterator isn't the same as const
>> iterator, how else would I accomplish this?
>
> The two obvious solutions for solving your problem:
>
> template <typename T1, typename T2>
> typename multimap<T1, T2>::const_iterator get_indexed_it(
> const multimap<T1, T2>& container,
> const T1& key,
> size_t index = 0) throw (out_of_range)
> {
> size_t count = container.count(key);
> if (count != 0 && count - 1 >= index) {
> typename multimap<T1, T2>::const_iterator it = container.find(key);
> while (index--)
> it++;
> return it;
> } else {
> throw out_of_range((string)"get_indexed_it->" + "Element"
> + key + "doesn't exist!");
> }
> }
>
> or
>
> template <typename T1, typename T2>
> typename multimap<T1, T2>::iterator get_indexed_it(
> multimap<T1, T2>& container,
> const T1& key,
> size_t index = 0) throw (out_of_range)
> {
> size_t count = container.count(key);
> if (count != 0 && count - 1 >= index) {
> typename multimap<T1, T2>::iterator it = container.find(key);
> while (index--)
> it++;
> return it;
> } else {
> throw out_of_range((string)"get_indexed_it->" + "Element"
> + key + "doesn't exist!");
> }
> }
>
> A couple of comments about your code (and the two 'solutions' above.)
>
> a) Returning a reference (either a reference to const_iterator or a
> reference to iterator,) doesn't make much sense to me; iterators are
> light weight and designed to be passed around by value.
I'll do so now and in the future, thanks.

>
> b) If T1 is not a string (or some user defined type designed to work as
> a string,) your code won't compile. Why not just make it a string?
Yeah, that didn't make sense

>
> Writing it more like this:
>
> template <typename Container, typename T>
> typename Container::iterator& get_indexed_it(Container& container, const
> T& key, size_t index = 0) throw (out_of_range)
> {
> if (container.count(key) <= index )
> throw out_of_range("get_indexed_it(Container&, const T&, size_t)");
>
> typename Container::iterator result = container.find(key);
> advance(result, index);
> return result;
> }
>
> a) Allows it to be used with maps, sets and multisets, as well as
> multimaps.
> b) Allows it to work even if 'key' is not a string like object.
> c) (arguably) better expresses the intent of the code.
>
> Better still would be to find some way to cleanly write the function
> without having to do the search twice (once for count, and once for
> find):
>
> template <typename Container, typename T>
> typename Container::iterator& get_indexed_it(
> Container& container,
> const T& key,
> size_t index = 0) throw (out_of_range)
> {
> pair<typename Container::iterator, typename Container::iterator>
> range = container.equal_range(key);
> if (distance(range.first, range.second) <= index)
> throw out_of_range("get_indexed_it(Container&, const T&, size_t)");
>
> advance(range.first, index);
> return range.first;
> }
>
> Just some thoughts.

That's some nice code man! I didn't know about those advance() and
distance() functions. Still learning the STL. Thanks a lot :)


== 2 of 3 ==
Date: Tues, Apr 28 2009 1:43 pm
From: Nick Overdijk


>> Better still would be to find some way to cleanly write the function
>> without having to do the search twice (once for count, and once for
>> find):
>>
>> template <typename Container, typename T>
>> typename Container::iterator& get_indexed_it(
>> Container& container,
>> const T& key,
>> size_t index = 0) throw (out_of_range)
>> {
>> pair<typename Container::iterator, typename Container::iterator>
>> range = container.equal_range(key);
>> if (distance(range.first, range.second) <= index)
>> throw out_of_range("get_indexed_it(Container&, const T&, size_t)");
>>
>> advance(range.first, index);
>> return range.first;
>> }

Hmz, that function still has a bit overhead though. I think this
function has the "littlest" overhead:

template <typename Container, typename T>
typename Container::iterator get_indexed_it2(
Container& container,
const T& key,
size_t index = 0) throw (out_of_range) {
//get the first
typename Container::iterator it = container.find(key);
//iterate over it, doing advance() and distance() in one
while (index-- && it->first==key && it != container.end()) it++;
//IF we went too far.
if (it == container.end()) throw
out_of_range("get_indexed_it(Container&, const T&, size_t)");
//else we're goooood
return it;
}

== 3 of 3 ==
Date: Tues, Apr 28 2009 1:46 pm
From: Nick Overdijk


Nick Overdijk wrote:
>>> Better still would be to find some way to cleanly write the function
>>> without having to do the search twice (once for count, and once for
>>> find):
>>>
>>> template <typename Container, typename T>
>>> typename Container::iterator& get_indexed_it(
>>> Container& container,
>>> const T& key,
>>> size_t index = 0) throw (out_of_range)
>>> {
>>> pair<typename Container::iterator, typename Container::iterator>
>>> range = container.equal_range(key);
>>> if (distance(range.first, range.second) <= index)
>>> throw out_of_range("get_indexed_it(Container&, const T&,
>>> size_t)");
>>>
>>> advance(range.first, index);
>>> return range.first;
>>> }
>
> Hmz, that function still has a bit overhead though. I think this
> function has the "littlest" overhead:
>
> template <typename Container, typename T>
> typename Container::iterator get_indexed_it2(
> Container& container,
> const T& key,
> size_t index = 0) throw (out_of_range) {
> //get the first
> typename Container::iterator it = container.find(key);
> //iterate over it, doing advance() and distance() in one
> while (index-- && it->first==key && it != container.end()) it++;
> //IF we went too far.
> if (it == container.end()) throw
> out_of_range("get_indexed_it(Container&, const T&, size_t)");
> //else we're goooood
> return it;
> }
>

Oh dear, sorry for that. Potential error on line while(...)

Should be:
while (index-- && it != container.end() && it->first==key) it++;

Missed that in the tests. ;-)

==============================================================================
TOPIC: Just want to make sure...
http://groups.google.com/group/comp.lang.c++/t/a9a8c2c7a4f70ad7?hl=en
==============================================================================

== 1 of 7 ==
Date: Tues, Apr 28 2009 12:05 pm
From: Noah Roberts


#include <iostream>

#include <memory>

struct T {};

std::auto_ptr<T> f() { return new T; }


int main()
{
std::auto_ptr<T> at = f();

std::cout << "test\n";
std::cin.get();
}


The above code should compile and work fine, no? I should not be
getting a crash due to doubly deleted memory segments...right?

Because in MSVC++ 8.0 the above code compiles but crashes. I find it
hard to believe that MSVC could have a library that's so trivially
hosed, but by my understanding of the docs on std::auto_ptr...the above
code should run without crashing.


== 2 of 7 ==
Date: Tues, Apr 28 2009 12:10 pm
From: Noah Roberts


Noah Roberts wrote:
> #include <iostream>
>
> #include <memory>
>
> struct T {};
>
> std::auto_ptr<T> f() { return new T; }

That doesn't compile in g++. So I changed the source according to what
g++ expects and it works without craishing in both compilers. Dunno why
MSVC lets me return new T, but it does and then can't handle it.


== 3 of 7 ==
Date: Tues, Apr 28 2009 12:17 pm
From: drew@furrfu.invalid (Drew Lawson)


In article <49f75393$0$2709$cc2e38e6@news.uslec.net>
Noah Roberts <noah@nowhere.com> writes:
>#include <iostream>
>
>#include <memory>
>
>struct T {};
>
>std::auto_ptr<T> f() { return new T; }
>
>
>int main()
>{
> std::auto_ptr<T> at = f();
>
> std::cout << "test\n";
> std::cin.get();
>}
>
>
>The above code should compile and work fine, no? I should not be
>getting a crash due to doubly deleted memory segments...right?

I've used auto_ptr, but never as a return type.
I think you really want to return a T* and store it in auto_ptr.
Otherwise 'at' may be a copy of a temporary auto_ptr.

And that would be bad.

>Because in MSVC++ 8.0 the above code compiles but crashes. I find it
>hard to believe that MSVC could have a library that's so trivially
>hosed, but by my understanding of the docs on std::auto_ptr...the above
>code should run without crashing.


--
Drew Lawson | It's not enough to be alive
| when your future's been deferred


== 4 of 7 ==
Date: Tues, Apr 28 2009 12:20 pm
From: Noah Roberts


Drew Lawson wrote:
> In article <49f75393$0$2709$cc2e38e6@news.uslec.net>
> Noah Roberts <noah@nowhere.com> writes:
>> #include <iostream>
>>
>> #include <memory>
>>
>> struct T {};
>>
>> std::auto_ptr<T> f() { return new T; }
>>
>>
>> int main()
>> {
>> std::auto_ptr<T> at = f();
>>
>> std::cout << "test\n";
>> std::cin.get();
>> }
>>
>>
>> The above code should compile and work fine, no? I should not be
>> getting a crash due to doubly deleted memory segments...right?
>
> I've used auto_ptr, but never as a return type.
> I think you really want to return a T* and store it in auto_ptr.
> Otherwise 'at' may be a copy of a temporary auto_ptr.
>
> And that would be bad.

It shouldn't be. The temporary should be assigned to at, which then
holds the ptr while the original temp holds 0.


== 5 of 7 ==
Date: Tues, Apr 28 2009 12:21 pm
From: peter koch


On 28 Apr., 21:05, Noah Roberts <n...@nowhere.com> wrote:
> #include <iostream>
>
> #include <memory>
>
> struct T {};
>
> std::auto_ptr<T> f() { return new T; }
>
> int main()
> {
>    std::auto_ptr<T> at = f();
>
>    std::cout << "test\n";
>    std::cin.get();
>
> }
>
> The above code should compile and work fine, no?  I should not be
> getting a crash due to doubly deleted memory segments...right?
>
> Because in MSVC++ 8.0 the above code compiles but crashes.  I find it
> hard to believe that MSVC could have a library that's so trivially
> hosed, but by my understanding of the docs on std::auto_ptr...the above
> code should run without crashing.

This is a bug in MSVC++ - I believe you can find it on their website.

/Peter


== 6 of 7 ==
Date: Tues, Apr 28 2009 12:34 pm
From: Victor Bazarov


Noah Roberts wrote:
> Drew Lawson wrote:
>> In article <49f75393$0$2709$cc2e38e6@news.uslec.net>
>> Noah Roberts <noah@nowhere.com> writes:
>>> #include <iostream>
>>>
>>> #include <memory>
>>>
>>> struct T {};
>>>
>>> std::auto_ptr<T> f() { return new T; }
>>>
>>>
>>> int main()
>>> {
>>> std::auto_ptr<T> at = f();
>>>
>>> std::cout << "test\n";
>>> std::cin.get();
>>> }
>>>
>>>
>>> The above code should compile and work fine, no? I should not be
>>> getting a crash due to doubly deleted memory segments...right?
>>
>> I've used auto_ptr, but never as a return type.
>> I think you really want to return a T* and store it in auto_ptr.
>> Otherwise 'at' may be a copy of a temporary auto_ptr.
>>
>> And that would be bad.
>
> It shouldn't be. The temporary should be assigned to at, which then
> holds the ptr while the original temp holds 0.

'std::auto_ptr' has a special copy c-tor, one that takes a non-const
ref. A temporary cannot be used to construct another 'auto_ptr'.
That's the problem, I believe.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


== 7 of 7 ==
Date: Tues, Apr 28 2009 12:39 pm
From: drew@furrfu.invalid (Drew Lawson)


In article <gt7lms$1f0$1@news.datemas.de>
Victor Bazarov <v.Abazarov@comAcast.net> writes:
>Noah Roberts wrote:
>> Drew Lawson wrote:
>>> In article <49f75393$0$2709$cc2e38e6@news.uslec.net>
>>> Noah Roberts <noah@nowhere.com> writes:
>>>> #include <iostream>
>>>>
>>>> #include <memory>
>>>>
>>>> struct T {};
>>>>
>>>> std::auto_ptr<T> f() { return new T; }
>>>>
>>>>
>>>> int main()
>>>> {
>>>> std::auto_ptr<T> at = f();
>>>>
>>>> std::cout << "test\n";
>>>> std::cin.get();
>>>> }
>>>>
>>>>
>>>> The above code should compile and work fine, no? I should not be
>>>> getting a crash due to doubly deleted memory segments...right?
>>>
>>> I've used auto_ptr, but never as a return type.
>>> I think you really want to return a T* and store it in auto_ptr.
>>> Otherwise 'at' may be a copy of a temporary auto_ptr.
>>>
>>> And that would be bad.
>>
>> It shouldn't be. The temporary should be assigned to at, which then
>> holds the ptr while the original temp holds 0.
>
>'std::auto_ptr' has a special copy c-tor, one that takes a non-const
>ref. A temporary cannot be used to construct another 'auto_ptr'.
>That's the problem, I believe.

I was basing my original thought on general copying behavior.
Only after being corrected did it sink in that copying the pointer
in an auto_ptr could never make sense, and would always get double
deletes.

Short at least one cup of coffee today.

--
Drew Lawson | What you own is your own kingdom
| What you do is your own glory
| What you love is your own power
| What you live is your own story

==============================================================================
TOPIC: Is it legal to directly call a constructor?
http://groups.google.com/group/comp.lang.c++/t/562e9b8fa0a08333?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Apr 28 2009 1:13 pm
From: blargg.ei3@gishpuppy.com (blargg)


goodbyeera@gmail.com wrote:
> class A {
> void f() { this->A::A(); }
> };
>
> Let's just put away the logic of the program for a moment. I'm just
> wondering whether this syntax is legal in standard C++ or not. This
> compiles OK in VC and GCC, but fails in Comeau. I'm not able to find
> a direct answer to this in the standard. Can anyone help to explain
> whether it is syntactically legal? Thank you very much.

You can't directly call a constructor in C++. The closest you can do is
use placement new to construct an object in a buffer you provide:

#include <memory>

struct A { };

int main()
{
char* mem = new char [sizeof (A)];
A* a = new (mem) A;
// ...
a->~A();
delete [] mem;
}

(if A's constructor throws an exception in the example, it'll leak the
storage pointed to by mem).


== 2 of 2 ==
Date: Tues, Apr 28 2009 2:23 pm
From: "Alf P. Steinbach"


* blargg:
> goodbyeera@gmail.com wrote:
>> class A {
>> void f() { this->A::A(); }
>> };
>>
>> Let's just put away the logic of the program for a moment. I'm just
>> wondering whether this syntax is legal in standard C++ or not. This
>> compiles OK in VC and GCC, but fails in Comeau. I'm not able to find
>> a direct answer to this in the standard. Can anyone help to explain
>> whether it is syntactically legal? Thank you very much.
>
> You can't directly call a constructor in C++. The closest you can do is
> use placement new to construct an object in a buffer you provide:

On the contrary, that's the farthest from a direct constructor call. The
placement new has to work very indirectly because it has to set up an exception
handler, plus in the general case it has to call the class' allocation function,
before invoking the constructor with the specified arguments, which it has held
on to until now. In contrast, an ordinary direct constructor call is a direct
call, which you can readily verify by inspecting the machine code (unless you
have a really perverse C++ implementation).

Cheers & hth.,

- Alf

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!


==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en

To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

No comments: