http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* █田(⊙o⊙)田█Sneaker Nike,Jordan,Gucci,Adidas,Puma,EdhardyShox,Max,Free,Rift
sneaker and Levis,Polo,Lacoste,BBC,Gucci,Armani,LV,Christina Audigier Tshirt
and Jeans www.toptradea.com - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/cae6f901d30ad656?hl=en
* ★NO.1 Quality★Wholesale Levis,True Religion,Gucci,Coogi,Evisu,Edhardy,BBC,
Affliction,Christina Audigier,Bape Jeans - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b57ad0fbeaf460f6?hl=en
* Subclassing std::string confusion? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/fb74aed8c35e761f?hl=en
* Picking a random element from STL multimap - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/9a043af7369be26e?hl=en
* Disabling selected boost unit tests? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/87a8fa20c5e6da69?hl=en
* casting int's to an enum - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/c1c282ce004187e6?hl=en
* cheap wholesale nike max TN shoes,jordan wholesale,air force one,wholesale
jordan,nike shox wholesale - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3d561e76c3edb406?hl=en
* wholesale Nike Signature Shoes, LeBron James 6 sneakers,sell nike zoom kobe
snekaers collection - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/827911e3656a3a5d?hl=en
* Order of destruction of static members and static objects - 2 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/8c6c8d00ec467068?hl=en
* ❤～❤～❤ 2009 Discount BBC Coat, ED Hardy Coat, Bape Man Coat ect at www.
fjrjtrade.com <Paypal Payment> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b392451e1c6d1682?hl=en
* Why do some code bases don't use exceptions? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/c255001068888229?hl=en
* Multiple inheritance and pointer equivalence - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6ce10e4cd7c07869?hl=en
* Looking for a good memory and CPU profiler - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ac40d4006ea2c71c?hl=en
* I don't have to tell you... - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
* HashTable - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/5a6dd10761e736f9?hl=en
==============================================================================
TOPIC: █田(⊙o⊙)田█Sneaker Nike,Jordan,Gucci,Adidas,Puma,EdhardyShox,Max,Free,
Rift sneaker and Levis,Polo,Lacoste,BBC,Gucci,Armani,LV,Christina Audigier
Tshirt and Jeans www.toptradea.com
http://groups.google.com/group/comp.lang.c++/t/cae6f901d30ad656?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 28 2009 4:55 am
From: "www.toptradea.com"
█田(⊙o⊙)田█Sneaker
Nike,Jordan,Gucci,Adidas,Puma,EdhardyShox,Max,Free,Rift sneaker and
Levis,Polo,Lacoste,BBC,Gucci,Armani,LV,Christina Audigier Tshirt and
Jeans www.toptradea.com
"Nike Air Jordan sneaker www.toptradea.com
Air-Jordan-J1 sneaker www.toptradea.com
Air-Jordan-J3 sneaker www.toptradea.com
Air Jordan J4 sneaker www.toptradea.com
Air Jordan J5 sneaker www.toptradea.com
Air Jordan J6 sneaker www.toptradea.com
Air Jordan J7 sneaker www.toptradea.com
Air Jordan J8 sneaker www.toptradea.com
Air Jordan J9 sneaker www.toptradea.com
Air Jordan J10 sneaker www.toptradea.com
Air Jordan 11 sneaker www.toptradea.com
Air Jordan J12 sneaker www.toptradea.com
Air Jordan J13 sneaker www.toptradea.com
Air Jordan J14 sneaker www.toptradea.com
Air Jordan J16 sneaker www.toptradea.com
Air Jordan J17 sneaker www.toptradea.com
Air Jordan J18 sneaker www.toptradea.com
Air Jordan J19 sneaker www.toptradea.com
Air Jordan J23 sneaker www.toptradea.com
Air Jordan J24 sneaker www.toptradea.com
Air Jordan J25 sneaker www.toptradea.com
Jordan True Flight sneaker www.toptradea.com
+Air Jordan Fusion sneaker www.toptradea.com
Air Jordan mix1257 sneaker www.toptradea.com
Air Jordan fly 45 sneaker www.toptradea.com
Air Jordan Anthony M sneaker www.toptradea.com
Air Jordan J1+AF1 sneaker www.toptradea.com
Air Jordan J1 23 sneaker www.toptradea.com
Air Jordan mix6 sneaker www.toptradea.com
Air Jordan mix sneaker www.toptradea.com
Air Jordan Mix9 sneaker www.toptradea.com
Air Jordan mix3 sneaker www.toptradea.com
Air Jordan J5 mixman sneaker www.toptradea.com
Air Jordan 6+AF1 sneaker www.toptradea.com
Air Jordan J11 mix6 sneaker www.toptradea.com
Air Jordan J11 23woman sneaker www.toptradea.com
Air Jordan J11 Obama sneaker www.toptradea.com
Air Jordan J11 Antho sneaker www.toptradea.com
Air Jordan J12mix sneaker www.toptradea.com
Air Jordan J13+16 sneaker www.toptradea.com
Jordan J13+AF1 new sneaker www.toptradea.com
Air Jordan J20AF1 sneaker www.toptradea.com
Air Jordan J23 mix sneaker www.toptradea.com
"
"Nike Air Max sneaker www.toptradea.com
Air Max 91 sneaker www.toptradea.com
Nike-ID sneaker www.toptradea.com
Air Max 87 sneaker www.toptradea.com
Air-Max-2003 sneaker www.toptradea.com
Air max 5 sneaker www.toptradea.com
Air-Max-Tailwind-09 sneaker www.toptradea.com
Air-Max-new-180 sneaker www.toptradea.com
Air-Max-LTD sneaker www.toptradea.com
Air-Max-2006 sneaker www.toptradea.com
Air Max 97 sneaker www.toptradea.com
Air Max 92 sneaker www.toptradea.com
Air Max 90 sneaker www.toptradea.com
Air-Max-Yeezy sneaker www.toptradea.com
Air Max 09 sneaker www.toptradea.com
Air-Max-TN sneaker www.toptradea.com
Air Jordan LTD2 sneaker www.toptradea.com
Air-Max-Skyline sneaker www.toptradea.com
Air-Max-miniBMW sneaker www.toptradea.com
Air-Max-2009 sneaker www.toptradea.com
Air-Max180 sneaker www.toptradea.com
Air Max 95 sneaker www.toptradea.com
+Nike Shox sneaker www.toptradea.com
Nike-shox-TR sneaker www.toptradea.com
Nike-shox-TL3 sneaker www.toptradea.com
Nike-shox-R3 sneaker www.toptradea.com
Nike-air-Plata sneaker www.toptradea.com
Nike-shox-new sneaker www.toptradea.com
Nike-shox-87 sneaker www.toptradea.com
Nike-shox-97 sneaker www.toptradea.com
Nike-shox-NZ sneaker www.toptradea.com
Nike-shox-R5 sneaker www.toptradea.com
Nike-shox-R4 sneaker www.toptradea.com
Nike-shox-TL1 sneaker www.toptradea.com
Nike-shox-OZ sneaker www.toptradea.com
Nike-shox-TZ sneaker www.toptradea.com
Nike-shox-torch sneaker www.toptradea.com
+Air Force 1 sneaker www.toptradea.com
Air-Force-1 sneaker www.toptradea.com
AF1-low-shoes sneaker www.toptradea.com
AF1-Supreme-TZ-man sneaker www.toptradea.com
+Nike Rift sneaker www.toptradea.com
Nike-Air-zenyth sneaker www.toptradea.com
Nike-Rift sneaker www.toptradea.com
"
"Asics causal shoes www.toptradea.com ,
Creative Recreation causal shoes www.toptradea.com ,
Coogi causal shoes www.toptradea.com ,
Clarks causal shoes www.toptradea.com ,
Dkny causal shoes www.toptradea.com ,
Hogan causal shoes www.toptradea.com ,
Supra causal shoes www.toptradea.com ,
DG causal shoes www.toptradea.com ,
Edhardy causal shoes www.toptradea.com ,
Lacoste causal shoes www.toptradea.com ,
Puma causal shoes www.toptradea.com ,
Coach causal shoes www.toptradea.com "
==============================================================================
TOPIC: ★NO.1 Quality★Wholesale Levis,True Religion,Gucci,Coogi,Evisu,Edhardy,
BBC,Affliction,Christina Audigier,Bape Jeans
http://groups.google.com/group/comp.lang.c++/t/b57ad0fbeaf460f6?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 28 2009 4:57 am
From: "www.toptradea.com"
★NO.1 Quality★Wholesale Levis,True
Religion,Gucci,Coogi,Evisu,Edhardy,BBC,Affliction,Christina
Audigier,Bape Jeans
"Jeans Series<www.toptradea.com
Evisu Jeans Series<www.toptradea.com
Christina Audigier Jeans Series<www.toptradea.com
ZEN Jeans Series<www.toptradea.com
Levis Jeans Series<www.toptradea.com
Iceberg Jeans Series<www.toptradea.com
Black-Lable Jeans Series<www.toptradea.com
True Religion Jeans Series<www.toptradea.com
Laguna Jeans Series<www.toptradea.com
G-star Jeans Series<www.toptradea.com
Diesel Jeans Series<www.toptradea.com
Bape Jeans Series<www.toptradea.com
LV Jeans Series<www.toptradea.com
D&G Jeans Series<www.toptradea.com
Coogi Jeans Series<www.toptradea.com
Cavalli Jeans Series<www.toptradea.com
Artful-Dodger-Jeans Jeans Series<www.toptradea.com
RMC Jeans Series<www.toptradea.com
Gucci Jeans Series<www.toptradea.com
Ed hardy Jeans Series<www.toptradea.com
Armani Jeans Series<www.toptradea.com
BBC Jeans Series<www.toptradea.com
Prada Jeans Series<www.toptradea.com
"
"T-shirt www.toptradea.com
D&G T-shirt www.toptradea.com
Bape T-shirt www.toptradea.com
Smet T-shirt www.toptradea.com
LV T-shirt www.toptradea.com
Jungle T-shirt www.toptradea.com
Gucci T-shirt www.toptradea.com
Burberry T-shirt www.toptradea.com
Ed hardy T-shirt www.toptradea.com
Christina Audigier T-shirt www.toptradea.com
Adidas T-shirt www.toptradea.com
Polo T-shirt www.toptradea.com
Lacoste T-shirt www.toptradea.com
Juicy T-shirt www.toptradea.com
G-star T-shirt www.toptradea.com
BBC T-shirt www.toptradea.com
Affliction T-shirt www.toptradea.com
Armani T-shirt www.toptradea.com "
"Sunglasses http://www.toptradea.com/
Okely Sunglasses http://www.toptradea.com
Adidas Sunglasses http://www.toptradea.com/
Armani Sunglasses http://www.toptradea.com/
Burberry Sunglasses http://www.toptradea.com/
Coach Sunglasses http://www.toptradea.com/
Chanel Sunglasses http://www.toptradea.com/
Dior Sunglasses http://www.toptradea.com/
D&G Sunglasses http://www.toptradea.com/
Gucci Sunglasses http://www.toptradea.com/
Edhardy Sunglasses http://www.toptradea.com/
LV Sunglasses http://www.toptradea.com/
Police Sunglasses http://www.toptradea.com/
Nike Sunglasses http://www.toptradea.com/
Prada Sunglasses http://www.toptradea.com/
Versace Sunglasses http://www.toptradea.com/
"
"Handbag {www.toptradea.com }
Burberrys Handbag {www.toptradea.com }
Prada Handbag {www.toptradea.com }
Juicy Handbag {www.toptradea.com
Ed hardy Handbag {www.toptradea.com }
DB Handbag {www.toptradea.com }
Chloe Handbag {www.toptradea.com }
LV Handbag {www.toptradea.com }
Jimmy Hoo Handbag {www.toptradea.com }
Fendi Handbag {www.toptradea.com }
Coach Handbag {www.toptradea.com }
Gucci Handbag {www.toptradea.com }
Chanel Handbag {www.toptradea.com }
D&G Handbag {www.toptradea.com }
"
"Suite [www.toptradea.com ]
Adidas-suits[www.toptradea.com ]
Bape-suit[www.toptradea.com ]
Juicy-suits[www.toptradea.com ]
Nike-suit[www.toptradea.com ]
"
"Sandal {www.toptradea.com}
D&G-Sandals {www.toptradea.com}
Dior-Sandals {www.toptradea.com}
EdHardy-slipper {www.toptradea.com}
Gucci-sandal {www.toptradea.com}
LV-Sandals {www.toptradea.com}
"
"Jacket www.toptradea.com
Adidas-Jacket www.toptradea.com
Bape-Jacket www.toptradea.com
BBC-Jacket www.toptradea.com
Burberrry-Jacket www.toptradea.com
EdHardy-Jacket www.toptradea.com
CA-Jacket www.toptradea.com
Gstar-Jackets www.toptradea.com
Gucci-Jacket www.toptradea.com
Lacost-Jacket www.toptradea.com"
==============================================================================
TOPIC: Subclassing std::string confusion?
http://groups.google.com/group/comp.lang.c++/t/fb74aed8c35e761f?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 28 2009 5:03 am
From: petertwocakes
On 28 Nov, 12:28, "Balog Pal" <p...@lib.hu> wrote:
> "petertwocakes" <petertwoca...@googlemail.com>
>
> > But, if I have them both I get the error:
> > ambiguous overload for 'operator=' in 'sub = "abc"'
>
> so make another overload of = to take const char *.
Many thanks Balog, this works now.
class StringSub : public string
{
public:
// Constructors
StringSub();
StringSub(const char* ch) : string(ch) {}
StringSub(const string& str) : string(str) {}
virtual ~StringSub(){};
//-- Operator"="
StringSub& operator=(const string& str) { return (StringSub&)this-
>assign(str); }
StringSub& operator=(const char* ch) { return (StringSub&)this->assign
(ch); }
...
}
==============================================================================
TOPIC: Picking a random element from STL multimap
http://groups.google.com/group/comp.lang.c++/t/9a043af7369be26e?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Nov 28 2009 5:51 am
From: Steve
Hello,
when a multimap has multiple elements for a certain key, I want to
pick any random one of them.
I use equal_range to get the bounds iterators, and then try to add a
random number to the lower iterator, but the compiler complains that
there is no operator+.
map<char, int> myMap;
(... fill map with elements)
pair<multimap<char,int>::iterator,multimap<char,int>::iterator> ret =
myMap.equal_range('a');
multimap<char,int>::iterator firstIter = ret.first;
long numMatches = myMap.count('a');
int r = (random number between 0 and numMatches);
multimap<char,int>::iterator randomIter = firstIter +r;
I'm sure I've used +/- on iterators before, but maybe they only work
on other containers?
Is there a way to achieve this? I'm happy to go a completely different
route if there's a more efficient way.
Thanks
Steve
== 2 of 4 ==
Date: Sat, Nov 28 2009 5:57 am
From: Steve
(P.S. changed my nickname to 'Steve', was formerly 'petertwocakes')
== 3 of 4 ==
Date: Sat, Nov 28 2009 6:46 am
From: joseph cook
On Nov 28, 8:51 am, Steve <petertwoca...@googlemail.com> wrote:
> Hello,
>
> when a multimap has multiple elements for a certain key, I want to
> pick any random one of them.
> I use equal_range to get the bounds iterators, and then try to add a
> random number to the lower iterator, but the compiler complains that
> there is no operator+.
>
> map<char, int> myMap;
>
> (... fill map with elements)
>
> pair<multimap<char,int>::iterator,multimap<char,int>::iterator> ret =
> myMap.equal_range('a');
> multimap<char,int>::iterator firstIter = ret.first;
> long numMatches = myMap.count('a');
> int r = (random number between 0 and numMatches);
> multimap<char,int>::iterator randomIter = firstIter +r;
>
> I'm sure I've used +/- on iterators before, but maybe they only work
> on other containers?
>
> Is there a way to achieve this? I'm happy to go a completely different
> route if there's a more efficient way.
OK,
I'm not going to comment on your "radom" method, because I'll assume
that it is meeting your purposes.
However, as for the iterators, look at std::advance(InputIterator&
i, Distance d) which generically advances an iterator "i", 'd'
steps.
You cannot advance all iterators with operator+/-, just Random
Access Iterators
Hope that helps,
Joe Cook
== 4 of 4 ==
Date: Sat, Nov 28 2009 6:51 am
From: Steve
On 28 Nov, 14:46, joseph cook <joec...@gmail.com> wrote:
> On Nov 28, 8:51 am, Steve <petertwoca...@googlemail.com> wrote:
>
>
>
>
>
> > Hello,
>
> > when a multimap has multiple elements for a certain key, I want to
> > pick any random one of them.
> > I use equal_range to get the bounds iterators, and then try to add a
> > random number to the lower iterator, but the compiler complains that
> > there is no operator+.
>
> > map<char, int> myMap;
>
> > (... fill map with elements)
>
> > pair<multimap<char,int>::iterator,multimap<char,int>::iterator> ret =
> > myMap.equal_range('a');
> > multimap<char,int>::iterator firstIter = ret.first;
> > long numMatches = myMap.count('a');
> > int r = (random number between 0 and numMatches);
> > multimap<char,int>::iterator randomIter = firstIter +r;
>
> > I'm sure I've used +/- on iterators before, but maybe they only work
> > on other containers?
>
> > Is there a way to achieve this? I'm happy to go a completely different
> > route if there's a more efficient way.
>
> OK,
> I'm not going to comment on your "radom" method, because I'll assume
> that it is meeting your purposes.
> However, as for the iterators, look at std::advance(InputIterator&
> i, Distance d) which generically advances an iterator "i", 'd'
> steps.
> You cannot advance all iterators with operator+/-, just Random
> Access Iterators
>
> Hope that helps,
> Joe Cook
Thanks Joe, that's exactly what I needed.
Steve
==============================================================================
TOPIC: Disabling selected boost unit tests?
http://groups.google.com/group/comp.lang.c++/t/87a8fa20c5e6da69?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Nov 28 2009 6:35 am
From: "carl"
I have made a few boost unit-tests.
#define BOOST_AUTO_TEST_MAIN
#include <boost/test/auto_unit_test.hpp>
// Boost Test declaration and Checking macros
#include <boost/test/unit_test_suite.hpp>
#include <boost/test/test_tools.hpp>
#include <boost/test/floating_point_comparison.hpp>
BOOST_AUTO_TEST_SUITE(my_tests);
BOOST_AUTO_TEST_SUITE();
BOOST_AUTO_TEST_CASE(test_1)
{
}
BOOST_AUTO_TEST_CASE(test_2)
{
}
BOOST_AUTO_TEST_CASE(test_3)
{
}
Now when I run the unit-test all 3 test are executed. But is it possible
somehow to specify that only test 2 should be run?
== 2 of 2 ==
Date: Sat, Nov 28 2009 7:34 am
From: Gert-Jan de Vos
On Nov 28, 3:35 pm, "carl" <carl@.com> wrote:
> I have made a few boost unit-tests.
>
> #define BOOST_AUTO_TEST_MAIN
> #include <boost/test/auto_unit_test.hpp>
>
> // Boost Test declaration and Checking macros
> #include <boost/test/unit_test_suite.hpp>
> #include <boost/test/test_tools.hpp>
> #include <boost/test/floating_point_comparison.hpp>
>
> BOOST_AUTO_TEST_SUITE(my_tests);
> BOOST_AUTO_TEST_SUITE();
>
> BOOST_AUTO_TEST_CASE(test_1)
> {
>
> }
>
> BOOST_AUTO_TEST_CASE(test_2)
> {
>
> }
>
> BOOST_AUTO_TEST_CASE(test_3)
> {
>
> }
>
> Now when I run the unit-test all 3 test are executed. But is it possible
> somehow to specify that only test 2 should be run?
Run your test executable like this:
test --run_test=test_2
It is in "User's Guide" -> "Runtime configuration" -> "Run by name" in
the documentation.
==============================================================================
TOPIC: casting int's to an enum
http://groups.google.com/group/comp.lang.c++/t/c1c282ce004187e6?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Nov 28 2009 7:06 am
From: Jonathan Lee
On Nov 28, 6:00 am, Gert-Jan de Vos <gert-
jan.de....@onsneteindhoven.nl> wrote:
> You want runtime validation of a large range of values (ints) to a
> small range and make a well defined mapping. Like this:
>
> testenum get_testenum(int value)
> {
> switch (value)
> {
> case in: return in;
> case out: return out;
> case append: return append;
> }
> throw std::runtime_error("bad enum conversion");
>
> }
Agreed. Only change I would (possibly) make would be to return an
"enumInvalid" value instead of throwing. Usually I define this to
be -1. But that's only if you _expect_ or are going to handle the
invalid conversions.
--Jonathan
== 2 of 2 ==
Date: Sat, Nov 28 2009 3:22 pm
From: Angus
On 28 Nov, 15:06, Jonathan Lee <cho...@shaw.ca> wrote:
> On Nov 28, 6:00 am, Gert-Jan de Vos <gert-
>
> jan.de....@onsneteindhoven.nl> wrote:
> > You want runtime validation of a large range of values (ints) to a
> > small range and make a well defined mapping. Like this:
>
> > testenum get_testenum(int value)
> > {
> > switch (value)
> > {
> > case in: return in;
> > case out: return out;
> > case append: return append;
> > }
> > throw std::runtime_error("bad enum conversion");
>
> > }
>
> Agreed. Only change I would (possibly) make would be to return an
> "enumInvalid" value instead of throwing. Usually I define this to
> be -1. But that's only if you _expect_ or are going to handle the
> invalid conversions.
>
> --Jonathan
Or just call it unknown type if invalid type found.
==============================================================================
TOPIC: cheap wholesale nike max TN shoes,jordan wholesale,air force one,
wholesale jordan,nike shox wholesale
http://groups.google.com/group/comp.lang.c++/t/3d561e76c3edb406?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 28 2009 7:14 am
From: "www.vipshoeshop.com"
vipshoeshop Co.,Ltd( www.vipshoeshop.com ) wholesale cheap jordan
shoes,buy New arrival nike jordan sneakers,discount nike kids series
shoes,mix jordan sneakers,custom nike sb dunks,gucci tennis shoes for
discount, sell jordan sneakers for men's women's kids,cheap nike
trainers retro shoes,nike dunks premium sb,cheap nike zoom kobe 4
sneakers free shipping wholesale nike dunk sb shoes,Jordan
spiz"ikes,nike factory for authentic brand name sneakers,jordan
spiz'ikes,jordan mixed with air force ones,cheap nike shox
oz,nz,R3,R4,R5,TL2,TL3,TL4,TL5,cheap air force ones outlet,nike
sneakers for sale,discount air max 87,max 90,max 91,max 95,max 97,max
180,max 360,max TN,max LTD,discount nike women sneakers free
shipping,cheap D&G gucci prada chanel shoes timberland boot ugg
kick,discount bape stat shoes for sale.
==============================================================================
TOPIC: wholesale Nike Signature Shoes, LeBron James 6 sneakers,sell nike zoom
kobe snekaers collection
http://groups.google.com/group/comp.lang.c++/t/827911e3656a3a5d?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 28 2009 7:16 am
From: "www.vipshoeshop.com"
vipshoeshop Co.,Ltd(www.vipshoeshop.com) wholesale nike jordan
sneakers big cheap air jordan sneakers for sale.discount china nike
dunk sb shoes,nike exclusive jordan sneakers,custom nike air force one
sneakers,nike dunk cheap,nike jordan sneakers wholesale,discount supra
shoes wholesale new balance shoes puma shoes,cheap adidas
shoes,authentic jordan sneakers,wholesale nike max 90 sheos,china
supplier nike max 87 max 2009 max 360 shoes,hot max 95 shoes,free
shipping prada shoes,nike retro jordan snekaers,other nike running
shoes,wholesale nike lebron james 6 sneakers,cheap nike zoom kobe 4
sneakers free shipping, kids jordan sneakers wholesale, nike air force
one 1 fusion jordan sneakers,buy sneaker for cheap,nike air max
premium leather sneakers,gucci tennis shoes for discount,high quality
gucci shoes,wholesale jordan fusion sneakers from china supply,cheap
air bape sneakers, China Nike product manufacturer,gucci shoes,supply
puma sneakers timberland shoes,discounts Jordans kicks shoes Cheap
Discount Basketball Sneakers on Sale, Nike Retro Air Jordan Melo M5,
United States Christian Audigier T-Shirt Wholesale Christian Audigier
T-Shirt New cheap Christian Audigier T-Shirt Manufacturers
Suppliers,Wholesale Ed hardy AF T-Shirt, Discounted Louis Vuitton
Designer Handbags Clothes,Chanel and Coach Designer Handbag Wallets
Purse,Replica Louis Vuitton Handbag Accessories,Cheap Gucci handbags
Designer handbags by Gucci leather Purses Belt sunglasses,nike air
zoom signature basketball shoes,
==============================================================================
TOPIC: Order of destruction of static members and static objects
http://groups.google.com/group/comp.lang.c++/t/8c6c8d00ec467068?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Nov 28 2009 7:26 am
From: Juha Nieminen
Victor Bazarov wrote:
> Apparently you need 'A::container' to be a singleton. See any of the
> existing implementations of that pattern. Most simple ones actually
> create the singleton on demand (in freestore) and never destroy it.
You mean that if you want to make sure that a static member is never
accessed after it has been destroyed, you have to allocate it
dynamically and purposefully leak it?
Doesn't that make static members a bit useless?
== 2 of 2 ==
Date: Sat, Nov 28 2009 7:36 am
From: Juha Nieminen
James Kanze wrote:
> That's often the simplest and most appropriate solution. If
> Container is a more general class (e.g. an std::vector), then
> you can wrap it in a simple function to ensure the same
> behavior. Another solution is to ensure that Container has a
> trivial destructor.
How can you implement safely something like this?
// Header file
// -----------
class A
{
static std::vector<int> sharedContainer;
A(const A&);
A& operator=(const A&);
public:
A();
~A();
};
// Source file
// -----------
std::vector<int> A::sharedContainer;
A::A() { sharedContainer.push_back(0); }
A::~A() { sharedContainer.pop_back(); }
If somewhere else you have something like:
namespace { A a; }
then the constructor might be accessing an unconstructed std::vector,
and the destructor might be accessing a destroyed std::vector.
Construction safety could be ensured by changing the container to:
namespace
{
std::vector<int>& sharedContainer()
{
static std::vector<int> container;
return container;
}
}
But does that ensure that it's not accessed after it has been
destroyed? If not, how do you make sure it's not?
==============================================================================
TOPIC: ❤～❤～❤ 2009 Discount BBC Coat, ED Hardy Coat, Bape Man Coat ect at www.
fjrjtrade.com <Paypal Payment>
http://groups.google.com/group/comp.lang.c++/t/b392451e1c6d1682?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 28 2009 8:22 am
From: "www.fjrjtrade.com"
❤～❤～❤ 2009 Discount BBC Coat, ED Hardy Coat, Bape Man Coat ect at
www.fjrjtrade.com <Paypal Payment>
Discount Coat
http://www.fjrjtrade.com/804-Coat.html
Discount 999 Coat
http://www.fjrjtrade.com/1901-999-Coat.html
Discount A Coat
http://www.fjrjtrade.com/1904-A-Coat.html
Discount Adidas Coat
http://www.fjrjtrade.com/1906-Adidas-Coat.html
Discount Coogi Coat
http://www.fjrjtrade.com/2068-Coogi-Coat.html
Discount Gino Green Global Coat
http://www.fjrjtrade.com/2069-Gino-Green-Global-Coat.html
Discount Gndigo Coat
http://www.fjrjtrade.com/1909-Gndigo-Coat.html
Discount Gucci Coat
http://www.fjrjtrade.com/1911-Gucci-Coat.html
Discount KA Coat
http://www.fjrjtrade.com/1900-KA-Coat.html
Discount Lacoste Coat
http://www.fjrjtrade.com/1902-Lacoste-Coat.html
Discount Parish Coat
http://www.fjrjtrade.com/1903-Parish-Coat.html
Discount Pjmark Coat
http://www.fjrjtrade.com/1905-Pjmark-Coat.html
Discount POLO Coat
http://www.fjrjtrade.com/1907-POLO-Coat.html
Discount Rogawpar Coat
http://www.fjrjtrade.com/1908-Rogawpar-Coat.html
Discount Sean And Joh Coat
http://www.fjrjtrade.com/1910-Sean-And-Joh-Coat.html
Discount 10DEEP Man Coat
http://www.fjrjtrade.com/805-10DEEP-Man-Coat.html
Discount Bape Man Coat
http://www.fjrjtrade.com/808-Bape-Man-Coat.html
Discount BBC Man Coat
http://www.fjrjtrade.com/809-BBC-Man-Coat.html
Discount Christan Audigier Coat
http://www.fjrjtrade.com/810-Christan-Audigier-Coat.html
Discount Christan Audigier Man Coat
http://www.fjrjtrade.com/818-Christan-Audigier-Man-Coat.html
Discount ED Hardy Coat
http://www.fjrjtrade.com/813-ED-Hardy-Coat.html
Discount ED Hardy Coat Kid's
http://www.fjrjtrade.com/1912-ED-Hardy-Coat-Kids.html
Discount ED Hardy Man Coat
http://www.fjrjtrade.com/820-ED-Hardy-Man-Coat.html
Discount ED hardy Women Coat
http://www.fjrjtrade.com/821-ED-hardy-Women-Coat.html
Discount Evisu Man Coat
http://www.fjrjtrade.com/814-Evisu-Man-Coat.html
Discount LRG Man Coat
http://www.fjrjtrade.com/817-LRG-Man-Coat.html
More models at website:
http://www.fjrjtrade.com
==============================================================================
TOPIC: Why do some code bases don't use exceptions?
http://groups.google.com/group/comp.lang.c++/t/c255001068888229?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Nov 28 2009 8:56 am
From: "Thomas J. Gritzan"
Joshua Maurice schrieb:
> On Nov 27, 11:48 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> However, on half of all of the unix-
>> like environments available for me to test on, including Solaris, AIX,
>> HPUX, Linux, and for the common windows platforms, win32, win64,
>> exceptions add overhead even when not thrown, some worse than others.
>
> That should read "I have done tests on X platforms, and of those X,
> roughly half implement exceptions the slow aka bad aka not table way",
> not "The listed platforms are all bad." Some of the listed platforms
> implement exceptions the good way. See earlier posts. Sorry for the
> confusion.
You only have Win32 in your list, but not Win64 on either IA64 nor AMD64.
Do you have numbers for those, too?
--
Thomas
== 2 of 2 ==
Date: Sat, Nov 28 2009 10:02 am
From: Joshua Maurice
On Nov 28, 8:56 am, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
wrote:
> Joshua Maurice schrieb:
>
> > On Nov 27, 11:48 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> > However, on half of all of the unix-
> >> like environments available for me to test on, including Solaris, AIX,
> >> HPUX, Linux, and for the common windows platforms, win32, win64,
> >> exceptions add overhead even when not thrown, some worse than others.
>
> > That should read "I have done tests on X platforms, and of those X,
> > roughly half implement exceptions the slow aka bad aka not table way",
> > not "The listed platforms are all bad." Some of the listed platforms
> > implement exceptions the good way. See earlier posts. Sorry for the
> > confusion.
>
> You only have Win32 in your list, but not Win64 on either IA64 nor AMD64.
>
> Do you have numbers for those, too?
Not offhand. I could run tests for them potentially when I get some
spare time. I have been told or read that the win64 platform has a
different ABI which handles exceptions different, the correct way,
unlike win32. I know nothing of win IA 64 or win AMD 64. .
==============================================================================
TOPIC: Multiple inheritance and pointer equivalence
http://groups.google.com/group/comp.lang.c++/t/6ce10e4cd7c07869?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 28 2009 9:04 am
From: "Thomas J. Gritzan"
io_x schrieb:
> "io_x" <a@b.c.invalid> ha scritto nel messaggio
> news:4b0f84ec$0$10444$4fafbaef@reader2.news.tin.it...
>> #include <stdio.h>
>> #include <stdlib.h>
>> #define P printf
>> #define i8 signed char
Avoid macros in C++. Better would be:
typedef signed char i8;
Still better would be not to confuse the reader by hiding types and
functions behind 1- or 2-character names.
>> class A{
>> public:
>> A(){ Aarr= (i8*) malloc(1024); }
Avoid malloc/free in C++. std::vector<signed char> would be the C++ way.
>> virtual ~A()
>> {P("~A(); this=%p\n", this);
>> free(Aarr);
>> Aarr= (i8*) -1;
Any reason for this sentinel value? Why don't you use a NULL pointer
instead?
>> }
>> i8* Aarr;
>> };
>>
>> class B{
>> public:
>> B(){ Barr= (i8*) malloc(1024); }
>> virtual ~B()
>> {P("~B(); this=%p\n", this);
>> free(Barr);
>> Barr= (i8*) -1;
>> }
>> i8* Barr;
>> };
>>
>> class C : public A, public B{
>> public:
>> virtual ~C(){ P("~C(); this=%p\n", this); }
>> };
>>
>> int main(void)
>> { C *c = new C;
>> A *a = c;
>> B *b = c;
>>
>> if(c->Aarr==0||c->Barr==0)
>> {P("No memory\n");
>> goto end;
>> }
>> printf("c: %p; a: %p; b: %p\n", c, a, b);
>> end:;
>> delete c;
>
> here seems that both each of "delete a" and "delete c"
> is like "delete c"
Of course. The destructors are virtual. You can delete the object
through any pointer to a base class whose destructor is virtual.
--
Thomas
==============================================================================
TOPIC: Looking for a good memory and CPU profiler
http://groups.google.com/group/comp.lang.c++/t/ac40d4006ea2c71c?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 28 2009 10:05 am
From: Andy Champ
Johnson wrote:
> Thanks for the info, Ian. This project is developed under Microsoft
> Visual C++ 2008. Do you have any recommendation for trhe profiler?
> BTW, can you recommend me a few relevant forum?
Microsoft Visual C++ 2008 has a profiler built in. Or at least, it did
last week when I was profiling madly...
Look for Analyze [sic] on the menus.
Which edition do you have?
Andy
==============================================================================
TOPIC: I don't have to tell you...
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Nov 28 2009 11:12 am
From: Pavel
Alf P. Steinbach wrote:
> * Pavel:
>> Alf P. Steinbach wrote:
>>> * Pavel:
>>>> Bo Persson wrote:
>>>>> Balog Pal wrote:
>>>>>> "Alf P. Steinbach"<alfps@start.no>
>>>>>>>>>>>> http://www.artima.com/cppsource/nevercall.html
>>>>>>>>>>>> - "Never Call Virtual Functions during Construction or
>>>>>>>>>>>> Destruction"
>>>>>>>>>>>
>>>>>>>>>>> This, however, is total bullshit.
>>>>>>>>>>
>>>>>>>>>> It isn't. It's Item#9 form EC++,
>>>>>>>>>
>>>>>>>>> I don't care about the messenger. The message is bullshit.
>>>>>>>>> Really bad advice. FUD. Even in the context of programming for
>>>>>>>>> constrained embedded systems (there's no connection).
>>>>>>>>
>>>>>>>> I'm confused. Please quote me the part of the message which fits
>>>>>>>> the description, or elaborate.
>>>>>>>
>>>>>>> Every part of the quoted part is meaningless FUD.
>>>>>>>
>>>>>>> So, I haven't looked at the rest. :-)
>>>>>>
>>>>>> And doing so you flushed the baby with the bathwater. FUD is
>>>>>> something that puts down a claim and either not include rationale
>>>>>> at all or creates a phony one. You shouldn't address content such
>>>>>> without reading it.
>>>>>>> The point is that you don't have to care whether the methods are
>>>>>>> virtual or not.
>>>>>>> In C++ it's safe to call them anyway.
>>>>>> ...
>>>>>>> But as an abstract example, if a base class has a non-virtual
>>>>>>> method foo(), that calls a virtual method bar(), and your derived
>>>>>>> class T overrides bar(), then in your T constructor you can call
>>>>>>> foo and foo's call of bar() ends up in T::bar.
>>>>>>>
>>>>>>> It's a not uncommon scenario. The mentioned bugs in Java programs
>>>>>>> are mainly due to this scenario occurring often in actual code. In
>>>>>>> C++ it's no problem. :-)
>>>>>>
>>>>>> It *IS* a problem. One you appear to miss entirely, or turn a
>>>>>> blind eye.
>>>>>> The problem is not of the nature you argue against. Technically
>>>>>> the call works, and what it does is fully defined. And what
>>>>>> happens (IMO) makes more sense too, than say in java.
>>>>>>
>>>>>> The problem is a human one -- when calls to virtuals are done,
>>>>>> directly or indirectly, the expectation is they end up in the most
>>>>>> derived object. In the real-life and not the technical sense.
>>>>>> People are (appear) just not aware that in ctor and dtor different
>>>>>> rules apply, and expect the code just work by magic -- as it does
>>>>>> in every other context.
>>>>>
>>>>> Why, oh why, should the base class constructor be bothered to call
>>>>> code in the derived class?
>>>> Because
>>>>
>>>> 1. It is what the user wants and the compiler has enough information
>>>> to generate this code and thereby satisfy the user (the information
>>>> about object of which most derived class is actually being created is
>>>> known at compile time). Note: if what the user wants is to call the
>>>> base class's virtual function, s/he can always force it by explicit
>>>> qualification.
>>>
>>> Incorrect.
>>>
>>> Consider in class T construtor a call to a base class' foo which calls
>>> virtual bar which is overridden in T.
>> I am not sure I am following your sentence above. Did you mean this?
>>
>> class BT { public:
>> void foo() { bar(); }
>> virtual void bar() { cout << "BT::bar()\n"; }
>> };
>>
>> class T {
>> T() { foo(); }
>> };
>>
>> This does not present a problem in either specs (existing or desired)
>> as the derived class' bar() is called in both cases. If you meant
>> anything different could you please show sample code?
>
> class BT
> {
> private:
> virtual void bar() { say( "BT" ); }
> public:
> void foo() { bar(); }
> };
>
> class T
> : public BT
> {
> private:
> virtual void bar() { say( "T" ); }
> public:
> T() { foo(); }
> };
>
> class D
> : public T
> {
> private:
> std::string myPavelonian;
> virtual void bar() { say( myPavelonian.c_str(); }
> public:
> D(): myPavelonian( "D" ) {}
> };
>
> int main() { D(); }
>
> Works well with C++ rules, calling T::bar as the T programmer intended.
>
> Undefined behavior with Pavel/Howard rules.
>
> Contrary to your claim there's no way to use explicit qualification in
> class T or in class BT to make it call T::bar with Pavel/Howard rules.
T::T() { T::bar(); } /* "no way" puzzle solved in a one-liner; the
desired behavior achieved. BTW what was the purpose of foo() (other than
obscuring the question)? Reading or re-reading this
http://chalain.livejournal.com/39332.html may help you map requirements
to source code in a more straightforward way. */
BTW. If you believe your way of selecting variable names is funny, you
are fooling yourself. In me personally, it raises a doubt about a
possibility of impersonal technical conversation with you. I am not sure
know how much longer I will want to answer to posts obeying the like
"coding standard" or other personal references so don't get surprised or
too pleased by yourself for writing a smart post if you find it left
without a reply from me.
>>>> 2. It allows more efficient implementation (the known-to-me C++
>>>> implementations first write a pointer to virtual table of the base
>>>> class to the object; then override it with the pointer to derived
>>>> class's table; this is unnecessary and unjustified overhead breaking
>>>> the promise of C++ to be as efficient as possible)
>>>
>>> Yes, efficiency can be improved.
>>>
>>>
>>>> 3. The promise of C++ to be as powerful and dangerous to allow the
>>>> programmer to blow up his/her entire leg is broken.
>>>
>>> No, you can do whatever you want.
>> Thanks! I guess I did not know that before.
>>
>>> But if you want to do nonsensical
>>> initialization you'll have to do it yourself. Not via the language's
>>> mechanisms.
>> You can do whatever you want, too, in particular boldly business
>> requirements "nonsensical".
>
> Yes, it would be bold to require undefined behavior.
Business requirements are well defined. The behavior of my code above is
well defined under the current Standard. It would be well defined under
the more reasonable standard that Howard and myself would like to see,
too. Your code's behavior would be undefined under such a Standard. This
would be your code's issue. Under the current Standard, it is possible
to write a lot of code with undefined behavior. Everybody knows this and
C++ is not judged by how easy it is to write code with undefined
behavior. Everyone would agree it is very easy to do. C++ is judged by
how easy it is to write the code that solves a particular problem and
how easy it is to read and understand the code.
Try to make the following code (that means to track the creation of
objects of classes derived from Object and that would work under "our"
rules), work under the current Standard's rules. Try to fairly estimate
the difference in the cost/complexity of the resulting code:
void say(const char *msg) { cout << msg << '\n'; }
class Object {
public:
Object() { say(name()); }
virtual const char *name() {return "Object";}
};
class Foo : public Object {
public:
const char *name() { return "Foo"; }
};
class Bar : public Object {
public:
const char *name() { return "Bar"; }
};
int main() { Foo o; Bar o1; return 0; }
>
>
> Hth.,
>
> - Alf
Cheers,
-Pavel
== 2 of 4 ==
Date: Sat, Nov 28 2009 12:29 pm
From: Pavel
Bo Persson wrote:
> Pavel wrote:
>> Bo Persson wrote:
>>> Balog Pal wrote:
>>>> "Alf P. Steinbach"<alfps@start.no>
>>>>>>>>>> http://www.artima.com/cppsource/nevercall.html
>>>>>>>>>> - "Never Call Virtual Functions during Construction or
>>>>>>>>>> Destruction"
>>>>>>>>>
>>>>>>>>> This, however, is total bullshit.
>>>>>>>>
>>>>>>>> It isn't. It's Item#9 form EC++,
>>>>>>>
>>>>>>> I don't care about the messenger. The message is bullshit.
>>>>>>> Really bad advice. FUD. Even in the context of programming for
>>>>>>> constrained embedded systems (there's no connection).
>>>>>>
>>>>>> I'm confused. Please quote me the part of the message which
>>>>>> fits the description, or elaborate.
>>>>>
>>>>> Every part of the quoted part is meaningless FUD.
>>>>>
>>>>> So, I haven't looked at the rest. :-)
>>>>
>>>> And doing so you flushed the baby with the bathwater. FUD is
>>>> something that puts down a claim and either not include rationale
>>>> at all or creates a phony one. You shouldn't address content such
>>>> without reading it.
>>>>> The point is that you don't have to care whether the methods are
>>>>> virtual or not.
>>>>> In C++ it's safe to call them anyway.
>>>> ...
>>>>> But as an abstract example, if a base class has a non-virtual
>>>>> method foo(), that calls a virtual method bar(), and your derived
>>>>> class T overrides bar(), then in your T constructor you can call
>>>>> foo and foo's call of bar() ends up in T::bar.
>>>>>
>>>>> It's a not uncommon scenario. The mentioned bugs in Java programs
>>>>> are mainly due to this scenario occurring often in actual code.
>>>>> In C++ it's no problem. :-)
>>>>
>>>> It *IS* a problem. One you appear to miss entirely, or turn a
>>>> blind eye.
>>>> The problem is not of the nature you argue against. Technically
>>>> the call works, and what it does is fully defined. And what
>>>> happens (IMO) makes more sense too, than say in java.
>>>>
>>>> The problem is a human one -- when calls to virtuals are done,
>>>> directly or indirectly, the expectation is they end up in the most
>>>> derived object. In the real-life and not the technical sense.
>>>> People are (appear) just not aware that in ctor and dtor different
>>>> rules apply, and expect the code just work by magic -- as it does
>>>> in every other context.
>>>
>>> Why, oh why, should the base class constructor be bothered to call
>>> code in the derived class?
>> Because
>>
>> 1. It is what the user wants and the compiler has enough
>> information to generate this code and thereby satisfy the user (the
>> information about object of which most derived class is actually
>> being created is known at compile time). Note: if what the user
>> wants is to call the base class's virtual function, s/he can always
>> force it by explicit qualification.
>
> You shouldn't always give people what they believe they want. :-)
>
> Calling a virtual function on a non-existing object is one of those
> things. Here C++ avoids undefined behavior by defining that you can
> only call the function for the object that actually exists at that
> point.
Are we being completely honest here referring to the object as
"non-existing"? Under the current rules it does not exist but we are
discussing the quality of this very rules, aren't we? Under the proposed
(and time-tested) changed rules it would be existing, just not fully
initialized. Calling functions (virtual or not) on a
not-fully-initialized object is nothing new: a member function called
from the constructor is called on a not-fully-initialized object. What
is a point of discussing the conceptual correctness of letting people
call functions on a not-fully-initialized object when they already can
do it?
>> 3. The promise of C++ to be as powerful and dangerous to allow the
>> programmer to blow up his/her entire leg is broken.
>
> My impression is that C++ tries to avoid the shoot-in-the-foot
Not to avoid, but make it harder:
"In C++ it's harder to shoot yourself in the foot, but when you do, you
blow off your whole leg." — Bjarne Stroustrup.
It did not mean to make legitimate work harder, though. And the ability
to express useful ideas always comes at cost of danger. Remember
standard Pascal? It was clearly as safe as a language can get; so safe
that it was impossible to write anything useful in it (useful varieties
like Turbo Pascal introduced external modules, so they became useful but
lost the ability to statically proof the correctness). Certainly it is a
matter of personal choice where to draw the line and that's to try to
throw in some objectivity I refer to Java: From both my experience and
the prevalent opinion, Java is much safer language than C++ (and
respectively slightly less universal and capable). Therefore a litmus
test to me is: if something is safe enough for allowing it in Java, not
including that same capability in C++ for safety reasons is probably not
a good idea.
> situation whenever possible (and without a run-time cost :-). This
> does leave some opportunities for blowing a leg off, for the
> adventurous programmer.
>
>>
>> 4. It is proven to work (by Java for example).
>
> For some definition of work. I'm no Java expert, but from what I
> understand the cost you want to avoid in 2) now moves to a test for a
> fully constructed object in every call to the function.
Nah, it just lets you slip (Java!); see
http://en.wikipedia.org/wiki/Virtual_function#Java_2.
BTW, I just found the reference to this article of Scott Meyers ibid in
Wikipedia: http://www.artima.com/cppsource/nevercall.html. I think
logically those who agree with this his opinion should agree to us
(Howard and myself) as well: what a point in having a "safety feature"
that is recommended to be used .. never?
I say "logically" because Scott himself would apparently disagree:
"... That's how every part of C++ will treat it, and the treatment makes
sense: the BuyTransaction-specific parts of the object haven't been
initialized yet, so it's safest to treat them as if they didn't exist".
I, on the other hand, cannot see a big difference between calling any
function within a constructor (where some parts of an object may not
have been initialized yet) and calling a virtual function ibid. I
believe that treating the derived-class object as "non-existing" before
entering its construction function is an arbitrary and not very useful
choice of the Standard.
>
>>>
>>> That is the responsiblity of the derived class' constructor, which
>>> will no doubt be executed a microsecond later.
>>>
>
> My point is that the derived object should fully construct itself, and
> not depend on the base object calling some function during its
> construction. It is about the distribution of responsibilities.
See, if only purpose why constructors are used were the initialization
of the parts of the constructor's specific class I could agree to that.
In practice, however, there are other tasks that are hooked to the
constructors (because there is no other hooks in C++ for doing that in
general case). For example (the list is certainly incomplete):
1. To track creation of all objects in hierarchy where class-specific
information is necessary for tracking.
2. To complete the initialization of parallel bases.
3. To Register all created objects from hierarchy somewhere where the
registration data, registrar or registration algorithm is
derived-class-specific (that is, specific to static members of the
derived class or its state-independent behavior).
If C++ allowed an easy and inexpensive way of hooking in these (I am
aware of a wrapper/handler-based method but do not consider it easy
enough of inexpensive), a lion share of the current needs may have been
eliminated (I am not sure about all of them). As it is now, I see Java
behavior more beneficial.
-Pavel
>
>
> Bo Persson
>
>
== 3 of 4 ==
Date: Sat, Nov 28 2009 12:38 pm
From: "Alf P. Steinbach"
* Pavel:
> Alf P. Steinbach wrote:
>> * Pavel:
>>> Alf P. Steinbach wrote:
>>>> * Pavel:
>>>>> Bo Persson wrote:
>>>>>> Balog Pal wrote:
>>>>>>> "Alf P. Steinbach"<alfps@start.no>
>>>>>>>>>>>>> http://www.artima.com/cppsource/nevercall.html
>>>>>>>>>>>>> - "Never Call Virtual Functions during Construction or
>>>>>>>>>>>>> Destruction"
>>>>>>>>>>>>
>>>>>>>>>>>> This, however, is total bullshit.
>>>>>>>>>>>
>>>>>>>>>>> It isn't. It's Item#9 form EC++,
>>>>>>>>>>
>>>>>>>>>> I don't care about the messenger. The message is bullshit.
>>>>>>>>>> Really bad advice. FUD. Even in the context of programming for
>>>>>>>>>> constrained embedded systems (there's no connection).
>>>>>>>>>
>>>>>>>>> I'm confused. Please quote me the part of the message which fits
>>>>>>>>> the description, or elaborate.
>>>>>>>>
>>>>>>>> Every part of the quoted part is meaningless FUD.
>>>>>>>>
>>>>>>>> So, I haven't looked at the rest. :-)
>>>>>>>
>>>>>>> And doing so you flushed the baby with the bathwater. FUD is
>>>>>>> something that puts down a claim and either not include rationale
>>>>>>> at all or creates a phony one. You shouldn't address content such
>>>>>>> without reading it.
>>>>>>>> The point is that you don't have to care whether the methods are
>>>>>>>> virtual or not.
>>>>>>>> In C++ it's safe to call them anyway.
>>>>>>> ...
>>>>>>>> But as an abstract example, if a base class has a non-virtual
>>>>>>>> method foo(), that calls a virtual method bar(), and your derived
>>>>>>>> class T overrides bar(), then in your T constructor you can call
>>>>>>>> foo and foo's call of bar() ends up in T::bar.
>>>>>>>>
>>>>>>>> It's a not uncommon scenario. The mentioned bugs in Java programs
>>>>>>>> are mainly due to this scenario occurring often in actual code. In
>>>>>>>> C++ it's no problem. :-)
>>>>>>>
>>>>>>> It *IS* a problem. One you appear to miss entirely, or turn a
>>>>>>> blind eye.
>>>>>>> The problem is not of the nature you argue against. Technically
>>>>>>> the call works, and what it does is fully defined. And what
>>>>>>> happens (IMO) makes more sense too, than say in java.
>>>>>>>
>>>>>>> The problem is a human one -- when calls to virtuals are done,
>>>>>>> directly or indirectly, the expectation is they end up in the most
>>>>>>> derived object. In the real-life and not the technical sense.
>>>>>>> People are (appear) just not aware that in ctor and dtor different
>>>>>>> rules apply, and expect the code just work by magic -- as it does
>>>>>>> in every other context.
>>>>>>
>>>>>> Why, oh why, should the base class constructor be bothered to call
>>>>>> code in the derived class?
>>>>> Because
>>>>>
>>>>> 1. It is what the user wants and the compiler has enough information
>>>>> to generate this code and thereby satisfy the user (the information
>>>>> about object of which most derived class is actually being created is
>>>>> known at compile time). Note: if what the user wants is to call the
>>>>> base class's virtual function, s/he can always force it by explicit
>>>>> qualification.
>>>>
>>>> Incorrect.
>>>>
>>>> Consider in class T construtor a call to a base class' foo which calls
>>>> virtual bar which is overridden in T.
>>> I am not sure I am following your sentence above. Did you mean this?
>>>
>>> class BT { public:
>>> void foo() { bar(); }
>>> virtual void bar() { cout << "BT::bar()\n"; }
>>> };
>>>
>>> class T {
>>> T() { foo(); }
>>> };
>>>
>>> This does not present a problem in either specs (existing or desired)
>>> as the derived class' bar() is called in both cases. If you meant
>>> anything different could you please show sample code?
>>
>> class BT
>> {
>> private:
>> virtual void bar() { say( "BT" ); }
>> public:
>> void foo() { bar(); }
>> };
>>
>> class T
>> : public BT
>> {
>> private:
>> virtual void bar() { say( "T" ); }
>> public:
>> T() { foo(); }
>> };
>>
>> class D
>> : public T
>> {
>> private:
>> std::string myPavelonian;
>> virtual void bar() { say( myPavelonian.c_str(); }
>> public:
>> D(): myPavelonian( "D" ) {}
>> };
>>
>> int main() { D(); }
>>
>> Works well with C++ rules, calling T::bar as the T programmer intended.
>>
>> Undefined behavior with Pavel/Howard rules.
>>
>> Contrary to your claim there's no way to use explicit qualification in
>> class T or in class BT to make it call T::bar with Pavel/Howard rules.
> T::T() { T::bar(); } /* "no way" puzzle solved in a one-liner; the
> desired behavior achieved. BTW what was the purpose of foo() (other than
> obscuring the question)?
Assume that foo performs an essential function.
Or, if one is meant to take your "solution" seriously, are you really advocating
wholesale duplication of code?
Jeez.
>Reading or re-reading this
> http://chalain.livejournal.com/39332.html may help you map requirements
> to source code in a more straightforward way. */
There was no requirement other than calling foo(), and any more
straightforwarding mapping than calling it is impossible.
So your comment is meaningless.
Or just trolling.
> BTW. If you believe your way of selecting variable names is funny, you
> are fooling yourself. In me personally, it raises a doubt about a
> possibility of impersonal technical conversation with you. I am not sure
> know how much longer I will want to answer to posts obeying the like
> "coding standard" or other personal references so don't get surprised or
> too pleased by yourself for writing a smart post if you find it left
> without a reply from me.
You're trolling.
I hope...
Cheers & hth.,
- Alf
== 4 of 4 ==
Date: Sat, Nov 28 2009 3:21 pm
From: Paavo Helde
Howard Beale <none@none.none> wrote in news:Xns9CD072BE1CB51nonenonenone@
69.16.186.8:
> Balog Pal wrote:
>
>>> If you don't want that, fine.
>>
>> Life rarely considers what we want. :-o We have what we have. A
>> circle-under-counstruction is NOT a circle-complete. Same goes for
>> circle-being-destroyed. If it is drawn on paper, you can see the same
>> thing.
>
> Good point. We're talking about a problem with OOP in general. And
> maybe the answer is that OOP isn't "what we want." We're talking about
> defining a programming language -- made by us, made for us, so "what we
> want" really does matter in this case. You're basically saying "we
> invented C++ and it didn't pan out as well as we might have hoped, so
> we're stuck with it."
>
>
>> But really, what would be the alternative of construction? I observed
>> it as a fundamental approach. SICP suggests the same.
>
> There are plenty of languages (paradigms) that don't invlove
> constructors. C, which is where this discussion started, is a great
> example.
>
>
>> Ok, we all dislike it. Really. But what should be the alternative?
>> Which solution we would NOT dislike?
>
> Well, that's why we all come to usenet. To battle trolls and once in a
> blue moon, answer a worthwhile question like the one you just re-asked.
If I understood correctly, then your aim is to be able to call virtual
methods at construction and destruction time and expect them to wind up
in the most derived object, presumably assuming that those virtual
functions of the most derived object are careful enough to not touch
invalid data. This seems quite error-prone to me and I'm happy that such
behavior is not in the language by default. Maybe in some circumstances
it would be justified, but I'm not sure it would be supported by the core
language.
If it were supported, then such functions should be declared with an
additional keyword, maybe "static virtual" or whatever (though people
talking about static virtual functions usually want something else). In
any case, the implementation requires some extra data besides vtable
pointer in the base class object, as vtable pointer only cannot be used
for such behavior by the current language rules (as you have found out by
the hard way I guess). So I have sketched an example having an additional
member function pointer in the base class. To avoid undefined behavior,
the functions cannot have access to derived class B, as they are called
on an object which is not of type B at the moment. This rules out using
standard member functions, instead I'm using static member functions
here, to maintain an illusion of derivation. The "static virtual"
functions can call functions of the base class and other "static
virtual" functions (which would be technically also functions of the base
class).
#include <iostream>
class A;
typedef void (*func_t)(A&);
class A {
public:
A(func_t f=NULL): f_(f? f: &A::f) {
std::cout << "Entering A ctor body\n";
static_virtual_f();
std::cout << "Leaving A ctor\n";
}
virtual ~A() {
std::cout << "Entering A dtor body\n";
static_virtual_f();
std::cout << "Leaving A dtor\n";
}
void static_virtual_f() {
(*f_)(*this);
}
protected:
static void f(A& a) {
std::cout << "In A::f()\n";
}
private:
func_t f_;
};
class B: public A {
public:
B(func_t f=NULL): A(f? f: &B::f) {
std::cout << "Entering B ctor body\n";
static_virtual_f();
std::cout << "Leaving B ctor\n";
}
~B() {
std::cout << "Entering B dtor body\n";
static_virtual_f();
std::cout << "Leaving B dtor\n";
}
protected:
static void f(A& a) {
std::cout << "In B::f()\n";
}
};
int main() {
{
std::cout << "Creating A\n";
A a1;
std::cout << "Using A\n";
a1.static_virtual_f();
std::cout << "Deleting A\n";
}
std::cout << "\n";
{
std::cout << "Creating B\n";
B b1;
std::cout << "Using B\n";
b1.static_virtual_f();
std::cout << "Deleting B\n";
}
}
Output is:
Creating A
Entering A ctor body
In A::f()
Leaving A ctor
Using A
In A::f()
Deleting A
Entering A dtor body
In A::f()
Leaving A dtor
Creating B
Entering A ctor body
In B::f()
Leaving A ctor
Entering B ctor body
In B::f()
Leaving B ctor
Using B
In B::f()
Deleting B
Entering B dtor body
In B::f()
Leaving B dtor
Entering A dtor body
In B::f()
Leaving A dtor
==============================================================================
TOPIC: HashTable
http://groups.google.com/group/comp.lang.c++/t/5a6dd10761e736f9?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Nov 28 2009 2:05 pm
From: "carl"
I have found various hash_table implementation in c++ on the net. But I have
not found any that returns the chain of objects associated with a hased
index.
When more that one object hash to the same index it gets added to a chain of
elements. Are there any implmentations that returns the whole chain based on
a hashed index?
Its pretty much the functionality of a std::map that for each key contains a
list (or std::vector) of the stored objects. But I would like the constant
time lookup of the hash-table instead of the lg n time of a map.
==============================================================================
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:
Post a Comment