http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* What are the key differences between operator new and operator new[]? - 3
messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/0711f4e6de411900?hl=en
* On the Square-Rectangle Problem - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/17378f3e6e3294ba?hl=en
* ❤～❤～❤ Cheap wholesale BBC Coat, ED Hardy Coat, Bape Coat ect at www.rijing-
trade.com <Paypal Payment> - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3f1eaa2967e1864b?hl=en
* MySQL connector/driver behaviour with Visual C++ CLR/CLI project - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/738ca35dc8623177?hl=en
* （（（（ ۞））））wholesale cheap belts, shoes, handbags, purse and T-shirts
etc at www.ecyaya.com - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/34999ee5070dddcf?hl=en
* Static member vs global variable - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/39598a6a81930f50?hl=en
* Incomplete types and std::vector - 7 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/b0741c38fc15b5f7?hl=en
* ===Welcome to comp.lang.c++! Read this first. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/a801c2fa8f66c0a0?hl=en
* change function - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/98d241e38cad9662?hl=en
* want to learn stl - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/46c65272546dd209?hl=en
* opinions on "Walls and Mirrors" ? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/48e5157290f877dc?hl=en
* isspace - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/89ca303518428e34?hl=en
==============================================================================
TOPIC: What are the key differences between operator new and operator new[]?
http://groups.google.com/group/comp.lang.c++/t/0711f4e6de411900?hl=en
==============================================================================
== 1 of 3 ==
Date: Wed, Feb 3 2010 6:07 am
From: Victor Bazarov
xmllmx wrote:
> As we know, the C++ standard defines at least four special global
> functions as follows:
>
> 1) void* operator new(size_t);
>
> 2) void* operator new[](size_t);
>
> 3) void operator delete(void*);
>
> 4) void operator delete[](void*);
>
> In Visual C++, 2) and 4) simply forward their respective call to 1)
> and 3). Obviously, 1) and 3) are equivalents respectively to malloc
> and free in C. However, when and why should we call 2) and 4)?
*We* should *never* [have to] call them directly. They will be called
when you allocate an array of objects of some class type (if they are
overloaded for that class) or delete[] a pointer.
> Though 2) and 4) are not harmful, but I think them rather ugly.
> Because I can not find any necessity of them.
Have you ever tried overloading those? Read about custom allocators and
class-wide memory management, and you might find separating those useful.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
== 2 of 3 ==
Date: Wed, Feb 3 2010 7:48 am
From: "Fred Zwarts"
"Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote in message
news:r4vim59csp5qevcqksqe0l8milup439pi3@4ax.com
>> Normally, you don't call these operators explicitly, but you use
>> new and new [] to create new objects and delete and delete [] to
>> destroy objects. In these cases there is much more than just malloc
>> and free. In addition to allocating memory, new and new [] call
>> constructors to create objects and in addtion to freeing memory,
>> delete and delete[] call destructors to destroy objects.
>> 2) and 4) should be used for arrays. They call the constructors,
>> resp. destructors for all array elements, whereas new and delete
>> call only one constructor, resp. destructor.
>
> No they do not.
>
> You are not distinguishing between a new expression and operator new,
> The new expression does exactly what you describe above and you
> cannot alter its behaviour.
>
> But the OP is asking about operator new and all that does is aquire
> raw memory.
> operator new is called by the new expression to obtain memory.
I know I was talking about new and new [] expressions.
It was not clear to me that the OP knew that these expression do more than the corresponding operators.
As the expressions new and new [] are very different,
it is reasonable that they also use different operators.
As explained in another response by someone else,
this gives the flexibility to overload these two operators in a different way,
if the application needs a different approach to acquire memory
in these two diferent cases.
== 3 of 3 ==
Date: Wed, Feb 3 2010 8:11 am
From: xmllmx
On Feb 3, 11:48 pm, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
> "Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote in message
>
> news:r4vim59csp5qevcqksqe0l8milup439pi3@4ax.com
>
>
>
>
>
> >> Normally, you don't call these operators explicitly, but you use
> >> new and new [] to create new objects and delete and delete [] to
> >> destroy objects. In these cases there is much more than just malloc
> >> and free. In addition to allocating memory, new and new [] call
> >> constructors to create objects and in addtion to freeing memory,
> >> delete and delete[] call destructors to destroy objects.
> >> 2) and 4) should be used for arrays. They call the constructors,
> >> resp. destructors for all array elements, whereas new and delete
> >> call only one constructor, resp. destructor.
>
> > No they do not.
>
> > You are not distinguishing between a new expression and operator new,
> > The new expression does exactly what you describe above and you
> > cannot alter its behaviour.
>
> > But the OP is asking about operator new and all that does is aquire
> > raw memory.
> > operator new is called by the new expression to obtain memory.
>
> I know I was talking about new and new [] expressions.
> It was not clear to me that the OP knew that these expression do more than the corresponding operators.
> As the expressions new and new [] are very different,
> it is reasonable that they also use different operators.
> As explained in another response by someone else,
> this gives the flexibility to overload these two operators in a different way,
> if the application needs a different approach to acquire memory
> in these two diferent cases.
Thank you for your this answer. I think this answer is rather
convincing. Just now, I searched another C++ news group, and got some
useful story about the ancient history of C++. In graphics driver
development, it is common to dynamically allocate huge-size array. In
such cases, it becomes very crucial to handle different allocation/
deallocation situations in different ways.
Thank you again, Fred.
==============================================================================
TOPIC: On the Square-Rectangle Problem
http://groups.google.com/group/comp.lang.c++/t/17378f3e6e3294ba?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 6:34 am
From: Nilone
On Feb 3, 1:43 pm, Philip Potter <p...@doc.ic.ac.uk> wrote:
> On 03/02/2010 10:09, Nilone wrote:
>
>
>
>
>
> > On Feb 3, 11:31 am, Philip Potter <p...@doc.ic.ac.uk> wrote:
> >> My problem isn't that a rectangle store can't store a square -- it can
> >> -- it's that a rectangle store is able to store things other than a
> >> square, while a square store promises to only hold squares.
>
> >> Imagine a function 'void f (SquareStore &x)' which takes a reference to
> >> a square store, and expects that store to come preloaded with a square
> >> value. It will throw an exception if the store is empty, but it assumes
> >> that if the store is not empty then it contains a square value.
>
> >> Now, suppose I call that function with a rectangle store instead. That
> >> function now has a rectangle value where it was expecting a square value.
>
> >> These statements are contradictory, and one has to go:
>
> >> * A rectangle store makes every promise that a square store makes.
> >> * A square store will only ever hold a square.
> >> * A rectangle store can store non-square rectangles.
>
> > Since the parameter is in/out, arguments would have to comply with the
> > intersection of covariant inheritance of value properties and
> > contravariant inheritance of variable mutators, i.e. you could only
> > pass a square store and not a rectangle store.
>
> Which parameter is in/out? A slight variation, 'void f (const
> SquareStore &x)', has the same problem, but it's definitely not in/out
> wrt to the function.
I was describing an ideal subtyping language, not C++. My apologies
for not being explicit.
>
> If you're talking about in/out wrt the store itself, I'm afraid that any
> definition of "store" which doesn't let you put things in and take
> things out is not one I'm willing to accept.
I wouldn't accept such a store either. I was only talking about
restrictions on accessing a store polymorphically.
>
> > A pure in-parameter would be able to accept any square value including
> > values of subtypes of square.
>
> > A pure out-parameter would be able to accept any square store
> > including stores of supertypes of square.
>
> If this is the problem, how would you prevent a SquareStore being used
> as an in/out parameter?
It's not a problem, and in general, I wouldn't want to prevent any
store being used as an in/out parameter. I was just trying to express
what you described more clearly in the remainder of your post.
>
> > As for the contradictory statements, a rectangle store promises to
> > store square values, just like a square store does. Whether the value
> > in it is a square or a rectangle isn't a property of the store, but of
> > the value itself.
>
> What you say is true, but it leaves out the fact that a square store is
> guaranteed to give me a square out of it, while a rectangle store makes
> no such promise.
>
> Having read Stefan's comments elsethread, I think I finally get it.
>
> These are guaranteed:
>
> * A rectangle store can accept any square value
> * A square store will only emit rectangle values
>
> BUT these are not guaranteed:
>
> * A square store can accept any rectangle value
> * A rectangle store will only emit square values
>
> If the stores are write-only, a rectangle store is (substitutable for) a
> square store. Code that wants to stuff a square somewhere can use either.
>
> If the stores are read-only, a square store is (substitutable for) a
> rectangle store. Code that wants to get a rectangle value can use either.
I agree completely up to this point.
>
> But if (for some reason) you expect both behaviours, then there is no
> simple relationship between square store and rectangle store, and that
> is my problem with Stefan's original post.
If you want to do both, then the store must be exactly of the expected
type. Stefan's original post distinguished writing the store from
reading a value, whereas we're now talking both of writing and reading
the store.
The reason for the difference is to express the fact that properties
of the value relate to the value, not the store. I tend to prefer
that style myself.
>
> The key thing for me in the Square-Rectangle problem, and the thing that
> this analysis doesn't really cover, is Liskov substitutability. A
> derived class must keep all the promises a base class makes. The problem
> only arises if a Rectangle makes a promise a Square can't keep, or vice
> versa. If this is the case, then Rectangle and Square cannot be directly
> descended from each other, though they might be siblings.
I currently believe the inability of current OO languages to enforce
LSP is due to a broken inheritance model.
==============================================================================
TOPIC: ❤～❤～❤ Cheap wholesale BBC Coat, ED Hardy Coat, Bape Coat ect at www.
rijing-trade.com <Paypal Payment>
http://groups.google.com/group/comp.lang.c++/t/3f1eaa2967e1864b?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 7:20 am
From: "www.fjrjtrade.com"
❤～❤～❤ Cheap wholesale BBC Coat, ED Hardy Coat, Bape Coat ect at
www.rijing-trade.com <Paypal Payment>
Discount Coat
Discount 999 Coat
Discount A Coat
Discount Adidas Coat
Discount Coogi Coat
Discount Gino Green Global Coat
Discount Gndigo Coat
Discount Gucci Coat
Discount KA Coat
Discount Lacoste Coat
Discount Parish Coat
Discount Pjmark Coat
Discount POLO Coat
Discount Rogawpar Coat
Discount Sean And Joh Coat
Discount 10DEEP Man Coat
Discount Bape Man Coat
Discount BBC Man Coat
Discount Christan Audigier Coat
Discount Christan Audigier Man Coat
Discount ED Hardy Coat
Discount ED Hardy Coat Kid's
Discount ED Hardy Man Coat
Discount ED hardy Women Coat
Discount Evisu Man Coat
Discount LRG Man Coat
More models at website:
www.rijing-trade.com
== 2 of 2 ==
Date: Wed, Feb 3 2010 7:19 am
From: "www.fjrjtrade.com"
❤～❤～❤ Cheap wholesale BBC Coat, ED Hardy Coat, Bape Coat ect at
www.rijing-trade.com <Paypal Payment>
Discount Coat
Discount 999 Coat
Discount A Coat
Discount Adidas Coat
Discount Coogi Coat
Discount Gino Green Global Coat
Discount Gndigo Coat
Discount Gucci Coat
Discount KA Coat
Discount Lacoste Coat
Discount Parish Coat
Discount Pjmark Coat
Discount POLO Coat
Discount Rogawpar Coat
Discount Sean And Joh Coat
Discount 10DEEP Man Coat
Discount Bape Man Coat
Discount BBC Man Coat
Discount Christan Audigier Coat
Discount Christan Audigier Man Coat
Discount ED Hardy Coat
Discount ED Hardy Coat Kid's
Discount ED Hardy Man Coat
Discount ED hardy Women Coat
Discount Evisu Man Coat
Discount LRG Man Coat
More models at website:
www.rijing-trade.com
==============================================================================
TOPIC: MySQL connector/driver behaviour with Visual C++ CLR/CLI project
http://groups.google.com/group/comp.lang.c++/t/738ca35dc8623177?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 8:10 am
From: red floyd
On Feb 2, 8:48 pm, 0 <jeffrey.whites...@gmail.com> wrote:
> Hello. i'm having an issue getting the MySQL connector/driver to
> behave proberly with a Visual C++ CLR/CLI project.... my issue is
> best described by this screen capture:http://img97.imageshack.us/i/mysqlissue.jpg/
>
> The host name that MySQL is trying to resolve is a series of strange
> characters.... certainly not the "string" that is passed into the
> connector function. The exception handler is saying: Unknown MySQL
> server host 'U‹ìWVS ì ' (11004)... clearly it is not trying to
> connect to tcp://bluetech
>
> Has anyone see this? Could it have to do with language/character sets
> or something? I've already tried: this->con = this->driver->connect
> (L"tcp://bluetech:3306",L"SC",L"SC"); but, the connect function is
> looking for a std::string.
>
> Can someone please help me?
>
Your best bet is to go to a group with microsoft and/or VC in it's
name.
C++/CLI is not -- despite what MS wishes -- C++. It's off-topic here,
as
are O/S specific issues.
==============================================================================
TOPIC: （（（（ ۞））））wholesale cheap belts, shoes, handbags, purse and T-
shirts etc at www.ecyaya.com
http://groups.google.com/group/comp.lang.c++/t/34999ee5070dddcf?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 8:56 am
From: hero
（（（（ ۞））））wholesale cheap belts, shoes, handbags, purse and T-shirts
etc at www.ecyaya.com
cool belts
the hottest Afflirtion Belt with high quality and low price on www.ecyaya.com
the hottest Armani Belt with high quality and low price on www.ecyaya.com
the hottest Bape Belt with high quality and low price on www.ecyaya.com
the hottest Boss Belt with high quality and low price on www.ecyaya.com
the hottest Burberry Belt with high quality and low price on www.ecyaya.com
the hottest C.D Belt with high quality and low price on www.ecyaya.com
the hottest Chanel Belt with high quality and low price on www.ecyaya.com
the hottest CK Belt with high quality and low price on www.ecyaya.com
the hottest D&G Belt with high quality and low price on www.ecyaya.com
the hottest Diesel Belt with high quality and low price on www.ecyaya.com
the hottest DSQ Belt with high quality and low price on www.ecyaya.com
the hottest ED Belt with high quality and low price on www.ecyaya.com
the hottest Gucci Belt with high quality and low price on www.ecyaya.com
the hottest Hermes Belt with high quality and low price on www.ecyaya.com
the hottest Levfs Belt with high quality and low price on www.ecyaya.com
the hottest LV Belt with high quality and low price on www.ecyaya.com
the hottest Polo Belt with high quality and low price on www.ecyaya.com
the hottest Prada Belt with high quality and low price on www.ecyaya.com
the hottest Versace Belt with high quality and low price on www.ecyaya.com
== 2 of 2 ==
Date: Wed, Feb 3 2010 8:56 am
From: hero
（（（（ ۞））））wholesale cheap belts, shoes, handbags, purse and T-shirts
etc at www.ecyaya.com
cool belts
the hottest Afflirtion Belt with high quality and low price on www.ecyaya.com
the hottest Armani Belt with high quality and low price on www.ecyaya.com
the hottest Bape Belt with high quality and low price on www.ecyaya.com
the hottest Boss Belt with high quality and low price on www.ecyaya.com
the hottest Burberry Belt with high quality and low price on www.ecyaya.com
the hottest C.D Belt with high quality and low price on www.ecyaya.com
the hottest Chanel Belt with high quality and low price on www.ecyaya.com
the hottest CK Belt with high quality and low price on www.ecyaya.com
the hottest D&G Belt with high quality and low price on www.ecyaya.com
the hottest Diesel Belt with high quality and low price on www.ecyaya.com
the hottest DSQ Belt with high quality and low price on www.ecyaya.com
the hottest ED Belt with high quality and low price on www.ecyaya.com
the hottest Gucci Belt with high quality and low price on www.ecyaya.com
the hottest Hermes Belt with high quality and low price on www.ecyaya.com
the hottest Levfs Belt with high quality and low price on www.ecyaya.com
the hottest LV Belt with high quality and low price on www.ecyaya.com
the hottest Polo Belt with high quality and low price on www.ecyaya.com
the hottest Prada Belt with high quality and low price on www.ecyaya.com
the hottest Versace Belt with high quality and low price on www.ecyaya.com
==============================================================================
TOPIC: Static member vs global variable
http://groups.google.com/group/comp.lang.c++/t/39598a6a81930f50?hl=en
==============================================================================
== 1 of 3 ==
Date: Wed, Feb 3 2010 8:59 am
From: "Thomas J. Gritzan"
Am 03.02.2010 07:27, schrieb Suneel VLN:
> On Feb 3, 11:00 am, Rolf Magnus <ramag...@t-online.de> wrote:
>> Suneel VLN wrote:
>>> #include <iostream>
>>> using namespace std;
>>> int x = 100;
>>
>>> class WithStatic
>>> {
>>> static int x;
>>> static int y;
>>> public:
>>> void print() const
>>> {
>>> cout << "WithStatic::x = " << x << endl;
>>> cout << "WithStatic::y = " << y << endl;
>>> }
>>> };
>>
>>> int WithStatic::y = x + 1;
>>> int WithStatic::x = 51;
> static x is a private member inside a class. How come it was in
> closest scope at that line?
The standard says (§8.5/12, current draft N3000):
"An initializer for a static member is in the scope of the member's class."
Access levels and visibility are two different concepts. The compiler
first decides which variable or function is used, depending on scope and
-- when the function is overloaded -- the types of the parameters. After
that, the compiler checks if the code has the right to access this
variable or function.
>> For objects with static storage duration, there are two types of
>> initialization, static and dynamic. static initialization is done before
>> dynamic initialization
>
> in such case during static initialization will y be initialized to 0?
Yes. For variables with static storage duration and dynamic
initialization, the initialization is a two step process. They are
zero-initialized before any user written code runs.
From the standard (§8.5/9):
[ Note: Every object of static storage duration is zero-initialized at
program startup before any other initialization
takes place. In some cases, additional initialization is done later.
—end note ]
--
Thomas
== 2 of 3 ==
Date: Wed, Feb 3 2010 9:38 am
From: Suneel VLN
On Feb 3, 9:59 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wrote:
> Am 03.02.2010 07:27, schrieb Suneel VLN:
>
>
>
>
>
> > On Feb 3, 11:00 am, Rolf Magnus <ramag...@t-online.de> wrote:
> >> Suneel VLN wrote:
> >>> #include <iostream>
> >>> using namespace std;
> >>> int x = 100;
>
> >>> class WithStatic
> >>> {
> >>> static int x;
> >>> static int y;
> >>> public:
> >>> void print() const
> >>> {
> >>> cout << "WithStatic::x = " << x << endl;
> >>> cout << "WithStatic::y = " << y << endl;
> >>> }
> >>> };
>
> >>> int WithStatic::y = x + 1;
> >>> int WithStatic::x = 51;
> > static x is a private member inside a class. How come it was in
> > closest scope at that line?
>
> The standard says (§8.5/12, current draft N3000):
> "An initializer for a static member is in the scope of the member's class."
>
> Access levels and visibility are two different concepts. The compiler
> first decides which variable or function is used, depending on scope and
> -- when the function is overloaded -- the types of the parameters. After
> that, the compiler checks if the code has the right to access this
> variable or function.
>
> >> For objects with static storage duration, there are two types of
> >> initialization, static and dynamic. static initialization is done before
> >> dynamic initialization
>
> > in such case during static initialization will y be initialized to 0?
>
> Yes. For variables with static storage duration and dynamic
> initialization, the initialization is a two step process. They are
> zero-initialized before any user written code runs.
>
> From the standard (§8.5/9):
> [ Note: Every object of static storage duration is zero-initialized at
> program startup before any other initialization
> takes place. In some cases, additional initialization is done later.
> —end note ]
>
> --
> Thomas
Thanks Thomas. I am clear now.
Thanks,
-Suneel VLN.
== 3 of 3 ==
Date: Wed, Feb 3 2010 12:45 pm
From: James Kanze
On Feb 3, 6:43 am, tonydee <tony_in_da...@yahoo.co.uk> wrote:
> On Feb 3, 3:27 pm, Suneel VLN <suneelsuns...@gmail.com> wrote:
> > On Feb 3, 11:00 am, Rolf Magnus <ramag...@t-online.de> wrote:
> > > For objects with static storage duration, there are two
> > > types of initialization, static and dynamic. static
> > > initialization is done before dynamic initialization
> > in such case during static initialization will y be initialized to 0?
> I don't think the Standard guarantees that...
It does, and several frequently used programming idioms depend
on it.
> my recollection is compilers are free to use
> uninitialised/reclaimed memory for static variables that are
> to be dynamically initialised.
They certainly can't use reclaimed memory, since the object must
be present for the entire lifetime of the program.
> That would seem more efficient - why initialise something
> twice?
Maybe because the first initialization is for all intents and
purposes free. And because it might be useful to be able to
tell whether an object is initialized or not---objects with
static lifetime are about the only objects which can be accessed
normally before their constructor has run.
--
James Kanze
==============================================================================
TOPIC: Incomplete types and std::vector
http://groups.google.com/group/comp.lang.c++/t/b0741c38fc15b5f7?hl=en
==============================================================================
== 1 of 7 ==
Date: Wed, Feb 3 2010 9:16 am
From: Juha Nieminen
James Kanze wrote:
> That's not the issue, at least not formally. The standard
> clearly says that it is undefined behavior to instantiate any of
> the templates defined in the standard over an undefined type.
> Typically, auto_ptr will only need to know the complete type in
> the destructor, and you will get away with it if the destructor
> of the pimpl is not inlined. But that's just a case of
> undefined behavior happening to work, and you won't get away
> with it if the implementation uses concepts. (And the next
> version of the standard will, I think, require a diagnostic. At
> least if concepts make it in.)
boost::shared_ptr doesn't require for the type to be complete. Since
the new standard will include a similar smart pointer, will it lose that
feature?
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 2 of 7 ==
Date: Wed, Feb 3 2010 9:32 am
From: "Leigh Johnston"
"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:hkcb1e$hlc$1@adenine.netfront.net...
> James Kanze wrote:
>> That's not the issue, at least not formally. The standard
>> clearly says that it is undefined behavior to instantiate any of
>> the templates defined in the standard over an undefined type.
>> Typically, auto_ptr will only need to know the complete type in
>> the destructor, and you will get away with it if the destructor
>> of the pimpl is not inlined. But that's just a case of
>> undefined behavior happening to work, and you won't get away
>> with it if the implementation uses concepts. (And the next
>> version of the standard will, I think, require a diagnostic. At
>> least if concepts make it in.)
>
> boost::shared_ptr doesn't require for the type to be complete. Since
> the new standard will include a similar smart pointer, will it lose that
> feature?
>
Yeah C++0x shared_ptr and unique_ptr do not require type to be complete. I
asked a question elsewhere about the status of auto_ptr. It seems to be
quite common to use auto_ptr to implement the pimpl idiom.
/Leigh
== 3 of 7 ==
Date: Wed, Feb 3 2010 12:32 pm
From: James Kanze
On Feb 2, 11:25 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Feb 2, 2:30 pm, James Kanze <james.ka...@gmail.com> wrote:
> > On Feb 2, 9:34 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
[...]
> Could you explain this to me then? Why was it ever allowed to
> delete a pointer to an incomplete type?
No, I can't explain it. It seems as incongruous to me as it
does to you. IMHO, it should be an error, requiring a
diagnostic.
--
James Kanze
== 4 of 7 ==
Date: Wed, Feb 3 2010 12:35 pm
From: James Kanze
On Feb 3, 8:39 am, Vladimir Jovic <vladasp...@gmail.com> wrote:
> James Kanze wrote:
> > That's not the issue, at least not formally. The standard
> > clearly says that it is undefined behavior to instantiate
> > any of the templates defined in the standard over an
> > undefined type. Typically, auto_ptr will only need to know
> > the complete type in the destructor, and you will get away
> > with it if the destructor of the pimpl is not inlined. But
> > that's just a case of undefined behavior happening to work,
> > and you won't get away with it if the implementation uses
> > concepts. (And the next version of the standard will, I
> > think, require a diagnostic. At least if concepts make it
> > in.)
> I have no idea what are concepts, but does it mean that the
> compilation of the code using pimpl is going to fail with the
> c++0x?
Not if you do it right. (And concepts are simply a means of
getting improved compile time error checking from templates.
The standard says, for example, that a type used to instantiate
std::vector must be assignable and copiable: without concepts,
you don't get an error until you try to instantiate one of the
functions which actually assigns or copies; with concepts, you
can get an error any time you try to instantiate the vector.)
--
James Kanze
== 5 of 7 ==
Date: Wed, Feb 3 2010 12:37 pm
From: James Kanze
On Feb 3, 5:16 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> James Kanze wrote:
> > That's not the issue, at least not formally. The standard
> > clearly says that it is undefined behavior to instantiate
> > any of the templates defined in the standard over an
> > undefined type. Typically, auto_ptr will only need to know
> > the complete type in the destructor, and you will get away
> > with it if the destructor of the pimpl is not inlined. But
> > that's just a case of undefined behavior happening to work,
> > and you won't get away with it if the implementation uses
> > concepts. (And the next version of the standard will, I
> > think, require a diagnostic. At least if concepts make it
> > in.)
> boost::shared_ptr doesn't require for the type to be complete.
> Since the new standard will include a similar smart pointer,
> will it lose that feature?
I don't think so. IIRC, the wording in the latest draft I saw
said that this case was undefined, unless otherwise specified.
And the description of shared_ptr specified otherwise. (But I
think it's about the only template which did.)
--
James Kanze
== 6 of 7 ==
Date: Wed, Feb 3 2010 12:40 pm
From: James Kanze
On Feb 3, 5:32 pm, "Leigh Johnston" <le...@i42.co.uk> wrote:
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
[...]
> I
> asked a question elsewhere about the status of auto_ptr. It seems to be
> quite common to use auto_ptr to implement the pimpl idiom.
Does it? My thoughts here are: why bother. You still need an
out of line destructor, and if you have to write a destructor
anyway, what's the problem with putting a delete in it, and
using a raw pointer. The whole point of the compilation
firewall idiom is to reduce include file dependencies, and any
smart pointer will require at least one extra include file.
--
James Kanze
== 7 of 7 ==
Date: Wed, Feb 3 2010 12:51 pm
From: "Alf P. Steinbach"
* James Kanze:
> On Feb 2, 11:25 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>> On Feb 2, 2:30 pm, James Kanze <james.ka...@gmail.com> wrote:
>>> On Feb 2, 9:34 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> [...]
>> Could you explain this to me then? Why was it ever allowed to
>> delete a pointer to an incomplete type?
>
> No, I can't explain it. It seems as incongruous to me as it
> does to you. IMHO, it should be an error, requiring a
> diagnostic.
'delete p' where *p is of statically incomplete type T is Undefined Behavior if
T has a non-trivial destructor or deallocation function, by §5.3.5/5.
'delete p' where *p is of static type 'void' is Undefined Behavior by §5.3.5/3,
since there are no actual objects of type 'void'.
There's even a note explaning that particular consequence.
Cheers & hth.,
- Alf
==============================================================================
TOPIC: ===Welcome to comp.lang.c++! Read this first.
http://groups.google.com/group/comp.lang.c++/t/a801c2fa8f66c0a0?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 9:30 am
From: Shiva
Welcome to comp.lang.c++! Read this first.
This post is intended to give the new reader an introduction to reading
and posting in this newsgroup. We respectfully request that you read
all the way through this post, as it helps make for a more pleasant
and useful group for everyone.
First of all, please keep in mind that comp.lang.c++ is a group for discussion
of general issues of the C++ programming language, as defined by the ANSI/ISO
language standard. If you have a problem that is specific to a particular system
or compiler, you are much more likely to get complete and accurate answers in a
group that specializes in your platform. A listing of some newsgroups is given
at the end of this post.
The FAQ (Frequently Asked Question) list has a wealth of information for
both the new and veteran C++ programmer. No matter what your experience
level, you are encouraged to read the entire list, if only to familiarize
yourself with what answers are available to minimize redundant replies.
The comp.lang.c++ FAQ is available at http://www.parashift.com/c++-faq-lite/
If the FAQ list does not help, then many regular readers of this group
are happy to assist with problems of standard C++. We have only a few
requests that we ask be adhered to, for the benefit of all:
* Please put a short summary in the subject line. Descriptions such as
"HELP!!!!!!" are not helpful, and many regular posters ignore such
requests. A good example is, "Problem with Virtual Functions."
* State the question or the problem clearly and concisely. Describe what
you are trying to do, and the problem you are running into. Include all
relevant error messages.
* Include the smallest, complete and compilable program that exhibits your
problem. As a rule, posters in comp.lang.c++ will not do homework, but will
give helpful hints if you have shown some willingness to try a solution.
* comp.lang.c++ is forum for discussion, and as such some regular posters do
not give E-mail replies. Very often follow-ups to postings have corrections,
so plan on taking part in the discussion if you post a question. If you
do receive e-mail replies, it is considered polite to post a summary.
* Don't post in HTML format. Many readers of this newsgroup don't use
newsreaders which can handle HTML postings.
* If you have to include source code in your post, include the
source in the message body. Don't use attachments. A lot
of contributors to this newsgroup won't even notice the existence
of attachments or won't open them. You try to get any help
you can get, don't you?
Some netiquette topics which frequently crop up on comp.lang.c++ are
also answered in the FAQ.
* Should I post job advertisements and/or resumes on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.10
* What if I really need a job; should I post my resume on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.11
* What should I do to someone who posts something off-topic?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12
A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.
This is a very busy group, so these requests are designed to make it as
pleasant and efficient an experience as possible. We hope it proves
a valuable commodity to you.
A list of some Newsgroups :
Languages and Programming
-------------------------
comp.lang.c The C Programming Language
comp.lang.asm.x86 x86 assembly language programming
comp.programming Non-language specific programming
comp.graphics.algorithms Issues of computer graphics
Operating Systems
-----------------
comp.os.msdos.programmer DOS, BIOS, Memory Models, interrupts,
screen handling, hardware
comp.os.ms-windows.programmer.win32 MS/Windows: Mice, DLLs, hardware
comp.os.os2.programmer.misc OS/2 Programming
comp.sys.mac.programmer.misc Macintosh Programming
comp.unix.programmer General Unix: processes, pipes, POSIX,
curses, sockets
comp.unix.[vendor] Various Unix vendors
Microsoft VC++
-------------
microsoft.public.vc.language VC++ issues
microsoft.public.vc.mfc MFC Issues
microsoft.public.dotnet.languages.vc C++/CLR Issues
microsoft.public.dotnet.framework .Net Framework
Borland C++ Builder
-------------------
borland.public.cppbuilder.language Borland C++ Builder
borland.public.cpp.language
borland.public.cppbuilder
-Shiva
http://www.slack.net/~shiva/welcome.txt
Wed Feb 3 12:30:00 EST 2010
==============================================================================
TOPIC: change function
http://groups.google.com/group/comp.lang.c++/t/98d241e38cad9662?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 10:16 am
From: Jorgen Grahn
On Sat, 2010-01-30, Larry wrote:
> "Larry" <dontmewithme@got.it> ha scritto nel messaggio
> news:4b637617$0$820$4fafbaef@reader5.news.tin.it...
>
>> this is what I have figure out so far: (untested)
>
> #include <algorithm>
>
> int Socket::ReceiveBytes(char * buffer, int buffersize)
> {
> if(buffersize > 32768)
> buffersize = 32768;
>
> char temp[32768];
>
> u_long arg = 0;
>
> if (ioctlsocket(s_, FIONREAD, &arg) != 0)
> return -1;
>
> if (arg == 0)
> return 0;
>
> if (arg > buffersize)
> arg = buffersize;
>
> int rv = recv (s_, temp, arg, 0);
>
> if (rv <= 0)
> return -1;
>
> if (rv == 0)
> return 0;
>
> if (rv > 0)
> std::copy(temp, temp + rv, buffer);
>
> }
Try compiling it with full warnings enabled before posting -- I spot
at least one compile error. Also please indent with more that 1 space
-- 4 is rather universal.
> where FIONREAD:
>
> Determine the amount of data which can be read atomically from socket s.
> argp points to an unsigned long in which ioctlsocket stores the result. If s
> is stream oriented (for example, type SOCK_STREAM), FIONREAD returns an
> amount of data which can be read in a single recv; this may or may not be
> the same as the total amount of data queued on the socket. If s is message
> oriented (for example, type SOCK_DGRAM), FIONREAD returns the size of the
> first datagram (message) queued on the socket.
It's not clear if you expect your socket to be stream or datagram. Or
what you intend the function to do. It's unusual, I think, to user the
same high-level function for both.
Adding just a tiny bit of documentation would have helped when
discussing it, a lot.
I don't think it's very common for people to use FIONREAD, by the way.
I think there are better options ... but I don't remember exactly and
it's offtopic here anyway.
> So I basically I will recv according to ioctlsocket. if the latter is > then
> buffersize I will read buffersize (arg = buffersize) if it's
> less...well...be just happy with that...if it's 0 or less don't even bother
> copying the buffer and return accordingly.
>
> that's all
>
> what about my idea?
One thing I don't understand is the extra copying. You went from a
std::string to a char* of known length, but why not read straight into
it?
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: want to learn stl
http://groups.google.com/group/comp.lang.c++/t/46c65272546dd209?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 10:44 am
From: Jorgen Grahn
On Wed, 2010-01-27, osmium wrote:
> vicky wrote:
>
>> i want to learn stl, if anybody can guide
>
> That's a formidable task. Fortunately there is a superb book on the
> subject, _The C++ Standard Library_ by Nicolai Josutis. If you think
> "formidable" is an exaggeration, the book has 800 pages and I don't think
> there is any fat there.
I think it *is* an exaggeration. You don't learn *all* of it at once.
If we're talking STL, you learn std::vector, std::map, iterators and
some of the most common algorithms and the ideas behind them.
> I found it useful to create a personalized partial
> index for the book in a home brew text file on my computer.
For the STL part, I really like SGI's documentation even though it's
partially outdated.
> You will have to learn to love verylonganddescriptivetypenames. Or at least
> learn to copy them faithfully.
Huh? I can't recall any of those in the standard library (neither in
lenght nor lowercasenowhitespace format). I also don't understand the
reference to copying them.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: opinions on "Walls and Mirrors" ?
http://groups.google.com/group/comp.lang.c++/t/48e5157290f877dc?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 10:54 am
From: Jorgen Grahn
On Thu, 2010-01-28, Andrew Poelstra wrote:
...
> So I would say wait before you buy it. If you want to
> learn data structures try flipping through Knuth or [---]
I've never really read Knuth, but IMHO that's an unusual advice to
people who haven't touched algorithms and data structures before.
Like Barbie would say: "Knuth is hard".
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 2 of 2 ==
Date: Wed, Feb 3 2010 12:00 pm
From: Andrew Poelstra
On 2010-02-03, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Thu, 2010-01-28, Andrew Poelstra wrote:
> ...
>> So I would say wait before you buy it. If you want to
>> learn data structures try flipping through Knuth or [---]
>
> I've never really read Knuth, but IMHO that's an unusual advice to
> people who haven't touched algorithms and data structures before.
> Like Barbie would say: "Knuth is hard".
>
> /Jorgen
>
The first page or so of each data-structure-related section
gives a theoretical overview of the structure, and I've always
liked his diagrams.
It is true that understanding his MIX code and doing his
exercises are very difficult, though. :)
Andrew
==============================================================================
TOPIC: isspace
http://groups.google.com/group/comp.lang.c++/t/89ca303518428e34?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 1:02 pm
From: Paavo Helde
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote in
news:slrnhmiei6.1qf.grahn+nntp@frailea.sa.invalid:
> On Fri, 2010-01-29, Paavo Helde wrote:
> ...
>> Or I could keep the text in UTF-8 and use my own custom function for
>> checking for the whitespace, checking directly for all Unicode
>> whitespace characters as listed in
>> http://en.wikipedia.org/wiki/Whitespace_% 28computer_science%29, this
>> seems to me much less error-prone than worrying if Russian locale and
>> std::isspace are working correctly on all platforms.
>
> Worrying? "I don't support doing analysis of Russian text on a
> platform with broken Russian locales" sounds like something you can
> happily say.
Happily to who? My boss? Or the customer? (Happily I myself don't have any
of those problems, the only locale I have needed so far is "C", to override
strange formatting caused by default locales. Everything is just working in
UTF-8.).
BTW, Windows is supporting Russian locales quite well, I believe. The
problem is that it does not support locales with UTF-8 encodings (which are
the only ones which make sense in my (limited) experience).
Cheers
Paavo
==============================================================================
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