soft and program: comp.lang.c++ - 24 new messages in 9 topics

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

comp.lang.c++@googlegroups.com

Today's topics:

==============================================================================
TOPIC: a simple question
http://groups.google.com/group/comp.lang.c++/t/5024236a053d7dcc?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Dec 31 2008 11:29 pm
From: red floyd

hpsoar wrote:
> On 1月1日, 下午12时19分, Sam <s...@email-scan.com> wrote:
>> application_pgp-signature_part
>> < 1K查看下载
>>
>> hpsoar writes:
>>> Hello every one, I'm new here, and I'm also new to C++, I have just
>>> learned a C++ course, and I want to know what you usually do with C++.
>> I use it to earn a living.
> Can you give some details, such as what kind of project you do with C+
> +

I wrote missile avionics software, as well as missile defense algorithms.

== 2 of 2 ==
Date: Thurs, Jan 1 2009 2:28 am
From: hpsoar

On 1月1日, 下午3时29分, red floyd <no.spam.h...@example.com> wrote:
> hpsoar wrote:
> > On 1月1日, 下午12时19分, Sam <s...@email-scan.com> wrote:
> >> application_pgp-signature_part
> >> < 1K查看下载
>
> >> hpsoar writes:
> >>> Hello every one, I'm new here, and I'm also new to C++, I have just
> >>> learned a C++ course, and I want to know what you usually do with C++.
> >> I use it to earn a living.
> > Can you give some details, such as what kind of project you do with C+
> > +
>
> I wrote missile avionics software, as well as missile defense algorithms.

That's great! That must be a tough and challenge work, and you must be
a excellent programer. Can you give me some tips in learning C++ and
developing project in C++. I'm a 21 year old college student of grade
3, and found myself lack of knowledge. Know I decide to settle down to
learn C++ well.

==============================================================================
TOPIC: C++ vs. C#
http://groups.google.com/group/comp.lang.c++/t/a7db16921180bbce?hl=en
==============================================================================

== 1 of 9 ==
Date: Thurs, Jan 1 2009 2:50 am
From: James Kanze

On Dec 31 2008, 1:57 pm, SG <s.gesem...@gmail.com> wrote:
> On 31 Dez., 09:19, James Kanze <james.ka...@gmail.com> wrote:

> > On Dec 31, 3:01 am, SG <s.gesem...@gmail.com> wrote:
> > > In case you havn't noticed in C++ neither structs nor
> > > classes define types that behave like references and thus
> > > would qualify as being lightweight.
> > More or less. The categorical distinctions of C# don't
> > really apply to C++, since in C++, the programmer can more
> > or less do whatever he wants.

> Always nitpicking. :) Let me rephrase:
> "In C++ neither structs nor classes define types that behave
> like references UNLESS the programmer explicitly designs them
> to do so logically. Still, they are "value types" in C#
> terminology."

It's not really nitpicking this time. C++ and C# have radically
different object models, and trying apply the languages
supported distinctions made by C# to C++ doesn't apply. The
important point (which I do think you made), of course, is that
for all of the categories in C#, you can effectively do the same
thing with a class type in C++; C# doesn't support anything that
C++ doesn't.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

== 2 of 9 ==
Date: Thurs, Jan 1 2009 11:26 am
From: tonytech08

On Dec 31 2008, 2:51 am, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 31, 5:28 am, tonytech08 <tonytec...@gmail.com> wrote:
>
>
>
>
>
> > On Dec 30, 8:01 pm, SG <s.gesem...@gmail.com> wrote:
> > > I didn't find any definition of "lightweight". But the way
> > > this word is used suggests that Microsoft likes to call
> > > value types "lightweight":
> > > "The struct type is suitable for representing lightweight objects
> > > such as Point, Rectangle, and Color. Although it is possible to
> > > represent a point as a class, a struct is more efficient in some
> > > scenarios. For example, if you declare an array of 1000 Point
> > > objects, you will allocate additional memory for referencing each
> > > object. In this case, the struct is less expensive."
> > > "In C#, a struct is like a lightweight class; it is a stack-
> > > allocated type that can implement interfaces but does not support
> > > inheritance."
> > Yeah, you're on the correct pages on the MS site. That's what
> > I was reading a few days ago also. Again, the documentation is
> > just AKIN to what I was alluding to as being relevant and
> > important going forward. (I'm not gonna spoon feed anyone).
>
> You mean that you're not going to let anyone know what you mean.

Given the responses in this and other threads of similar nature, I'll
just hold on to the concepts as trade secrets.

>
> > > In case you havn't noticed in C++ neither structs nor
> > > classes define types that behave like references and thus
> > > would qualify as being lightweight.
> > You're free to make your own definition of "lightweight" if
> > you choose to. The above that you wrote does not match mine.
>
> So what is yours. You refuse to tell us (or you're incapable of
> telling us).

If everyone wasn't so (seemingly?) perplexed by it I might explain
further, but as it stands, I'd feel abused to, as it seems to be much
more esoteric than I thought. I'll continue to recognize the
differences between lightweight and heavyweight "classes" and even
evolve the distinction, but I won't be doing that here in public
forum. If someone prefers to recognize just one type of class, or a
diversity and voluminous amount of class "types" to where none "stick
out", rather than two with distinct applicability that fundamentally
partition the language's canvas of class design machinery, that's fine
with me. YMMV.

== 3 of 9 ==
Date: Thurs, Jan 1 2009 11:43 am
From: tonytech08

On Dec 31 2008, 2:51 am, James Kanze <james.ka...@gmail.com> wrote:

> C# allows explicit user defined layout. I'm not sure what the
> consequences are, however (except when used to simulate a
> union---and it's a very awkward way of simulating a union). The
> results certainly can't be portable; I suspect that the intent
> is only to be able to force compatibility with some legacy
> interface on a specific system.

The emulation of a union example they gave (at
http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx) was just
that: an (one) example that showed that layout can be controlled and
how.

== 4 of 9 ==
Date: Thurs, Jan 1 2009 11:49 am
From: tonytech08

On Jan 1, 4:50 am, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 31 2008, 1:57 pm, SG <s.gesem...@gmail.com> wrote:
>
> > On 31 Dez., 09:19, James Kanze <james.ka...@gmail.com> wrote:
> > > On Dec 31, 3:01 am, SG <s.gesem...@gmail.com> wrote:
> > > > In case you havn't noticed in C++ neither structs nor
> > > > classes define types that behave like references and thus
> > > > would qualify as being lightweight.
> > > More or less. The categorical distinctions of C# don't
> > > really apply to C++, since in C++, the programmer can more
> > > or less do whatever he wants.
> > Always nitpicking. :) Let me rephrase:
> > "In C++ neither structs nor classes define types that behave
> > like references UNLESS the programmer explicitly designs them
> > to do so logically. Still, they are "value types" in C#
> > terminology."
>
> It's not really nitpicking this time. C++ and C# have radically
> different object models, and trying apply the languages
> supported distinctions made by C# to C++ doesn't apply. The
> important point (which I do think you made), of course, is that
> for all of the categories in C#, you can effectively do the same
> thing with a class type in C++;

> C# doesn't support anything that C++ doesn't.

Explicit layout control.

== 5 of 9 ==
Date: Thurs, Jan 1 2009 11:56 am
From: tonytech08

On Dec 31 2008, 6:52 am, SG <s.gesem...@gmail.com> wrote:
> On 31 Dez., 05:28, tonytech08 <tonytec...@gmail.com> wrote:
>
> > On Dec 30, 8:01 pm, SG <s.gesem...@gmail.com> wrote:

> > > Can you provide more specific pointers?
>
> > Probably... hang on... Here's a good jumping off point:
> >http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx.
> > It's the tutorial on C# structs. Note the "StructLayoutAttribute
> > Class" under "Further Reading". I'm not promoting that as a suggested
> > implementation, but rather pointing out that layout control is
> > important sometimes and that C# recognizes (and is able to "exploit"
> > it) that also.
>
> [layout control] supposedly serves two purposes:
> - emulating C/C++ unions
> - interfacing with native code

Those were just 2 examples they gave. Surely they thought that the
obviousness didn't warrant any simpler examples.

== 6 of 9 ==
Date: Thurs, Jan 1 2009 12:01 pm
From: tonytech08

On Dec 31 2008, 2:19 am, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 31, 3:01 am, SG <s.gesem...@gmail.com> wrote:
>
>
>
>
>
> > On 31 Dez., 00:41, tonytech08 <tonytec...@gmail.com> wrote:
> > > On Dec 28, 2:28 am, SG <s.gesem...@gmail.com> wrote:
> > > > I obviously don't know what you are talking about and I'm guessing
> > > > I'm not the only one. So in case you want this thread to have any
> > > > responses that are worth reading you might want to reconsider
> > > > explaining yourself (w.r.t. lightweight concept) "again" or at least
> > > > point to some resource containing the definitions you use.
> > > At this point, after having read up on C#'s usage of the
> > > terminology, I'll refer the reader there. While it's not
> > > necessarily my take or whole take on the concept, it should
> > > suffice to introduce the unitiated. Look at the C#
> > > documentation for the definition that MS gives to 'struct',
> > > 'class' and note the use of the term 'lightweight'.
> > You have to do better than saying "look up the C#
> > documentation". I didn't find any definition of
> > "lightweight". But the way this word is used suggests that
> > Microsoft likes to call value types "lightweight":
>
> Unlike C++, C# very definitely divides what C++ calls "class
> types" into three categories: structs, which have value
> semantics and a language defined copy assignment operator,
> classes, which have reference semantics and do not support
> assignment, and interfaces, which can only be used as a base
> class for one of the other two. All three categories are easily
> emulated in C++, and a typical application will use all
> three---what C# calls [structs] are more often called entity types.
>

In C#, one can derive from an interface and still have a lightweight
class whereas doing the same derivation in C++ results in a
heavyweight class.

== 7 of 9 ==
Date: Thurs, Jan 1 2009 12:59 pm
From: "Bo Persson"

tonytech08 wrote:
> On Jan 1, 4:50 am, James Kanze <james.ka...@gmail.com> wrote:
>>
>> It's not really nitpicking this time. C++ and C# have radically
>> different object models, and trying apply the languages
>> supported distinctions made by C# to C++ doesn't apply. The
>> important point (which I do think you made), of course, is that
>> for all of the categories in C#, you can effectively do the same
>> thing with a class type in C++;
>
>> C# doesn't support anything that C++ doesn't.
>
> Explicit layout control.

Now we are back to the fact that C# only runs on the .NET platform,
and therefore can document the exact layout of the underlying data.
C++ wants to be more flexible, to allow implementations to target
other kinds of platforms.

Is this flexibility really an advantage or a disadvantage? :-)

A similar example is C99 which has a typedef int32_t for those
platforms where this is possible, and lacks this typedef for platforms
where it is not possible. C# only targets platforms where an int32_t
type is possible. Does that make it a better language?!

Bo Persson

== 8 of 9 ==
Date: Thurs, Jan 1 2009 1:41 pm
From: SG

On 1 Jan., 11:50, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 31 2008, 1:57 pm, SG <s.gesem...@gmail.com> wrote:
> > On 31 Dez., 09:19, James Kanze <james.ka...@gmail.com> wrote:
> > > On Dec 31, 3:01 am, SG <s.gesem...@gmail.com> wrote:
> > > > In case you havn't noticed in C++ neither structs nor
> > > > classes define types that behave like references and thus
> > > > would qualify as being lightweight.
> > > More or less. The categorical distinctions of C# don't
> > > really apply to C++, since in C++, the programmer can more
> > > or less do whatever he wants.
> > Always nitpicking. :) Let me rephrase:
> > "In C++ neither structs nor classes define types that behave
> > like references UNLESS the programmer explicitly designs them
> > to do so logically. Still, they are "value types" in C#
> > terminology."
> It's not really nitpicking this time. C++ and C# have radically
> different object models, and trying apply the languages
> supported distinctions made by C# to C++ doesn't apply.

I thought I made it clear that I'm only talking about the value/
reference semantics aspect.

Cheers!
SG

== 9 of 9 ==
Date: Thurs, Jan 1 2009 4:04 pm
From: Erik Wikström

On 2009-01-01 21:01, tonytech08 wrote:
> On Dec 31 2008, 2:19 am, James Kanze <james.ka...@gmail.com> wrote:
>> On Dec 31, 3:01 am, SG <s.gesem...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> > On 31 Dez., 00:41, tonytech08 <tonytec...@gmail.com> wrote:
>> > > On Dec 28, 2:28 am, SG <s.gesem...@gmail.com> wrote:
>> > > > I obviously don't know what you are talking about and I'm guessing
>> > > > I'm not the only one. So in case you want this thread to have any
>> > > > responses that are worth reading you might want to reconsider
>> > > > explaining yourself (w.r.t. lightweight concept) "again" or at least
>> > > > point to some resource containing the definitions you use.
>> > > At this point, after having read up on C#'s usage of the
>> > > terminology, I'll refer the reader there. While it's not
>> > > necessarily my take or whole take on the concept, it should
>> > > suffice to introduce the unitiated. Look at the C#
>> > > documentation for the definition that MS gives to 'struct',
>> > > 'class' and note the use of the term 'lightweight'.
>> > You have to do better than saying "look up the C#
>> > documentation". I didn't find any definition of
>> > "lightweight". But the way this word is used suggests that
>> > Microsoft likes to call value types "lightweight":
>>
>> Unlike C++, C# very definitely divides what C++ calls "class
>> types" into three categories: structs, which have value
>> semantics and a language defined copy assignment operator,
>> classes, which have reference semantics and do not support
>> assignment, and interfaces, which can only be used as a base
>> class for one of the other two. All three categories are easily
>> emulated in C++, and a typical application will use all
>> three---what C# calls [structs] are more often called entity types.
>>
>
> In C#, one can derive from an interface and still have a lightweight
> class whereas doing the same derivation in C++ results in a
> heavyweight class.

Of course, because either you have a variable of the struct-type in
which case you know at compile-time that the object supports the
interface derived from. Or you box the struct (allocate memory on the
heap, generate a vptr, and all that stuff) at which point it works just
like a C++ class with virtual functions.

While the struct might seem quite lightweight from a programming
perspective you should be aware that when boxing comes into play it is
quite heavyweight for the implementation/application. If you find
yourself in a situation where you need to do a lot of boxing/unboxing
you should probably use a class instead of a struct, it will make things
much faster.

--
Erik Wikström

==============================================================================
TOPIC: Is it possible to use custom allocator for boost::any in shared memory?
http://groups.google.com/group/comp.lang.c++/t/06440f0dbd033e5c?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 1 2009 2:58 am
From: James

I am trying to develop 'generic' property map in shared memory based
on boost::any and had some problem.

Boost::interprocess and related containers in shared memory are used.
The property map will look like as below (part code):
My question is: because boost::any use "new" directly in the
constructor to construct the object

template<typename ValueType>
any(const ValueType & value)
: content(new holder<ValueType>(value))
{
}

it fails to co-work with shared memory because the object is not in
the shared memory and will not be seen by other processes.
My quick-and-dirty modification to boost::any is to replace all "new"
with "placement new" like:

template<typename ValueType>
any(const ValueType & value) /// manager is global
variable of the shared memory manager
: content(new (manager->allocate(sizeof(ValueType)))
holder<ValueType>(value))
{
}

~any()
{
if (content)
content->~placeholder();
any_allocator::shared_allocator->deallocate(content);
}

virtual placeholder * clone() const
{
return new (manager->allocate(sizeof(ValueType)))
holder(held);
}

But when trying to get the content from another process, is still
cause segfault in
any(const any & other)
: content(other.content ? other.content->clone() : 0)
{
}
any idea about that?
Thanks a lot in advance.

------------------------------------------------------------------------------------------
below my testing code where "any" is the modified version

#include "boost/interprocess/managed_shared_memory.hpp"
#include "boost/interprocess/containers/map.hpp"
#include "boost/interprocess/allocators/allocator.hpp"
#include "boost/interprocess/containers/string.hpp"

using namespace boost::interprocess;
typedef managed_shared_memory::segment_manager
segment_manager_t;
typedef allocator<char, segment_manager_t> char_allocator;
typedef allocator<void, segment_manager_t> void_allocator;
typedef basic_string<char, std::char_traits<char>, char_allocator>
char_string;
typedef char_string options_key_type;
typedef any options_mapped_type; ///<-- the
mapped value
typedef std::pair<options_key_type, options_mapped_type>
options_value_type;
typedef allocator<options_value_type, segment_manager_t>
options_value_type_allocator;
typedef map<options_key_type, options_mapped_type,
std::less<options_key_type>, options_value_type_allocator>
options_type;

options_type* options;

options_value_type_allocator options_allocator_instance(segment-
>get_segment_manager());
options = segment->construct<options_type>("options")
(std::less<options_key_type>(), options_allocator_instance);
void_allocator string_allocator_instance(segment->get_segment_manager
());
any_allocator::shared_allocator = segment->get_segment_manager();
options->insert(options_value_type(char_string("key1",
string_allocator_instance), any(10.0)));
options->insert(options_value_type(char_string("key1",
string_allocator_instance), any(true)));
...

==============================================================================
TOPIC: taking arrays/containers as member function arguments of an API
http://groups.google.com/group/comp.lang.c++/t/90c051e4427d391f?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 1 2009 3:09 am
From: James Kanze

On Dec 31 2008, 5:24 pm, alfps <alf.p.steinb...@gmail.com> wrote:
> On 31 Des, 16:48, "Hicham Mouline" <hic...@mouline.org> wrote:

> > In the main class of the API of a library,

> "main class"?

I think he means "main" in the general sense of principle, and
not in the sense of the "main" function.

> > we have a function

> > class M {
> > public:
> > void Calculate( CalcStatus* status, double* result, int tag, Operation
> > operation );
> > };

> > this calculates 1 result, returns a status for 1 tag and 1 operation.

> This seems to mean the function returns a CalcStatus and a double.

> Using out-parameters is OK.

But not very idiomatic. In this case, I'd probably return a
Fallible (but my implementation of Fallible supports extended
status codes); returning status and using an out parameter for
result is also very common.

> However, unless the function supports null-pointers for those
> parameters, the possibility of incorrect usage (and
> possibility of time wasted on determining correct usage) is
> greatly reduced by using pass by reference.

> > We would like to extend this API with more functions to
> > calculate N
> > results/statues for N tags and 1 operation,
> > M results/statues for 1 tag for M operations
> > M*N results/statues for N tags and M operations for each tag.

> The question is, does such wrapping simplify or complicate the
> client code?

> In other words, what is the perceived advantage, the reason
> why this is deemed desirable?

> > M and N are runtime variables. M is of the order of 10. N is
> > of the order of up to 1000 The question is whether to native
> > arrays or std::vector. Performance is especially relevant

> For performance nothing beats a simple loop in the client
> code.

Not even a simple loop in a template function? The "idiomatic"
solution would probably be something like:

struct Result // More likely something more
// complicated, perhaps a Fallible.
// The standard likes std::pair for
// this, but that's really bad
// engineering.
{
CalcStatus status ;
double value ;
} ;

// Constraints:
//
// InputIterator1::value_type convertible to int
// InputIterator2::value_type can be called as a
// function with ... arguments, returning a Result
// OutputIterator supports assignment of a Result
// ---------------------------------------------------------
template< typename InputIterator1, typename InputIterator2,
typename OutputIterator >
void Calculate(
InputIterator1 beginTag,
InputIterator1 endTag,
InputIterator2 beginOperation,
InputIterator2 endOperation,
OutputIterator result )
{
while ( beginTag != endTag ) {
while ( beginOperation != endOperation ) {
*result ++ = (*beginOperation)( ... ) ;
++ beginOperation ;
}
++ beginTag ;
}
}

I'll not argue for or against such a solution; you make some
very good points below concerning usability in client code (and
I'm very far from being convinced that the STL is a model of
good software design). But it is the idiotmatic solution in
modern C++. And it probably won't have any performance
problems; at least no more than any other solution.

> That also provides the greatest flexibility.

> E.g., it may be that the client doesn't need all those data
> points stored anywhere, but just uses one pair of values at a
> time. For another example, error/failure handling may depend
> on which computation. And so on.

> :-)

Yes. All very good points, which should be considered at the
design level. In this case, the rule to apply is probably not
to bother with such a function until you find yourself having to
write the loops several times, in more or less the same format.
In which case, refactor. (Of course, if you're working on
library code and don't have access to the client code to see how
it really uses the functions, this is more difficult. But as
Alf more or less says, designing something which will handle all
of the possible use cases is far from obvious.)

==============================================================================
TOPIC: Custom STL in place allocator crashed
http://groups.google.com/group/comp.lang.c++/t/0a248a2e913ba6c1?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jan 1 2009 3:16 am
From: James Kanze

On Dec 31 2008, 4:04 pm, Pete Becker <p...@versatilecoding.com> wrote:
> On 2008-12-31 09:37:54 -0500, zr <zvir...@gmail.com> said:
> > On Dec 31, 4:20 am, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
> > wrote:
> >> Allen schrieb:

> >>> On 12月31日, 上午9时14分, Allen <Allen.Che...@g
> > mail.com> wrote:
> >>>> There is a custom STL in place allocator in Google codes.
> >>>> The InPlaceAlloc.h URL ishttp://www.google.com/codesearch/p?hl=en#HC
> > lD5fLW7P8/InPlaceAlloc.h&q...

> >>>> #include <vector>
> >>>> #include "InPlaceAlloc.h"

> >>>> int main()
> >>>> {
> >>>> char * buffer = new char[1024];

> >> Avoid new[]. Avoid delete[]. Except buried down in a class or library.
> >> You can use std::vector to allocate a buffer:

> >> std::vector<char> buffer(1024);

> > Why is using a vector to allocate better than using new[] and delete
> > []?

> Orthodoxy.

In the usual case where the lifetime is scoped, it's the
simplest way to ensure exception safety, and definitly to be
prefered. Any time the array is to be passed as a parameter, it
acts like a real type, with value semantics and no special ad
hoc rules about converting to a pointer to the first element,
and it carries its size around with it as well. Most
implementations will also bounds check, which is really, really
rare for built in arrays. (I think I've only heard of one
compiler which bounds checks built-in arrays, and I don't know
if it is even still around.)

In 20 years of programming C++, I've never used an operator
new[]. (I do still use C style arrays in certain cases, but
never dynamically allocated.)

== 2 of 3 ==
Date: Thurs, Jan 1 2009 3:28 am
From: James Kanze

On Dec 31 2008, 8:42 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
wrote:
> zr schrieb:
> > On Dec 31, 4:20 am, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
> > wrote:
> >> Allen schrieb:

> >>> On 12月31日, 上午9时14分, Allen <Allen.Che...@gmail.com> wrote:
> >>>> There is a custom STL in place allocator in Google codes.
> >>>> The InPlaceAlloc.h URL ishttp://www.google.com/codesearch/p?hl=en#HClD5fLW7P8/InPlaceAlloc.h&q...
> >>>> #include <vector>
> >>>> #include "InPlaceAlloc.h"
> >>>> int main()
> >>>> {
> >>>> char * buffer = new char[1024];
> >> Avoid new[]. Avoid delete[]. Except buried down in a class or library.
> >> You can use std::vector to allocate a buffer:

> >> std::vector<char> buffer(1024);

> > Why is using a vector to allocate better than using new[]
> > and delete []?

> In general, because it lessens the risk of memory leaks. With
> new[], you have to delete[] in every possible code path, which
> can be quite complicated in some functions, especially if you
> allocate multiple arrays. It is very hard to make it
> exception safe. Most people don't even try it and ignore that
> issue. With std::vector or any other smart-pointer or RAII
> construct, the objects will be destroyed even then.

That's true, but not really relevant here. Similarly, a much
more important reason for using std::vector is that in any
decent implementation, the operator[] will be bounds checked,
and the type in general behaves like a normal type, with value
semantics. And that the type carries its dimensions along with
it.

None of which are really relevant here, because the user isn't
allocating an array, in the classical sense, he's allocating raw
memory. And the problem with new char[] is that it says the
wrong thing; it says that he is allocating an array of char. I
know, the language allows an array of char to be used as raw
memory. But that doesn't mean that you can't write code which
says what you mean. In this case, I'd call the ::operator new
function directly, e.g.:

void* buffer = ::operator new( quantityNeeded ) ;
// ...
::operator delete( buffer ) ;

(I'd also maintain the pointer as a void* where ever possible,
since this is the conventional type for a pointer to raw
memory.)

With regards to his original code:

1. I'd also ensure that the allocator took not only a pointer,
but also the size, and verify that constantly. (Part of his
problem, at least, is that the array he's allocating isn't
big enough.)

2. I'd define some memory management strategy. The simplest,
here, is just to use the Boehm collector; another solution
I've found useful in many cases is to pass an additional
boolean argument to the client, telling it whether to delete
in the destructor or not---since allocator must support
copy, this would require some tricky reference counting
here. Or... Just a guess, but it wouldn't surprise me if in
all of the actual use cases for this class, the memory
doesn't really have to be deleted anyway. (But if he'd
posted code without the delete, a lot of people would have
screamed about that.)

== 3 of 3 ==
Date: Thurs, Jan 1 2009 4:04 am
From: Pete Becker

On 2009-01-01 06:16:07 -0500, James Kanze <james.kanze@gmail.com> said:

> On Dec 31 2008, 4:04 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> On 2008-12-31 09:37:54 -0500, zr <zvir...@gmail.com> said:
>>> On Dec 31, 4:20 am, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
>>> wrote:
>>>> Allen schrieb:
>
>>>>> On 12月31日, 上午9时14分, A
> llen <Allen.Che...@g
>>> mail.com> wrote:
>>>>>> There is a custom STL in place allocator in Google codes.
>>>>>> The InPlaceAlloc.h URL ishttp://www.google.com/codesearch/p?hl=en#
> HC
>>> lD5fLW7P8/InPlaceAlloc.h&q...
>
>>>>>> #include <vector>
>>>>>> #include "InPlaceAlloc.h"
>
>>>>>> int main()
>>>>>> {
>>>>>> char * buffer = new char[1024];
>
>>>> Avoid new[]. Avoid delete[]. Except buried down in a class or library.
>>>> You can use std::vector to allocate a buffer:
>
>>>> std::vector<char> buffer(1024);
>
>>> Why is using a vector to allocate better than using new[] and delete
>>> []?
>
>> Orthodoxy.
>
> In the usual case where the lifetime is scoped, it's the
> simplest way to ensure exception safety, and definitly to be
> prefered.

In the example code, it had nothing to do with the problem.

But I guess there's a difference in viewpoint here. I think it's
important to try to give a clear answer to the question that was asked.
Others like to pontificate on how the sample code didn't meet their
coding guidelines, with so much lecturing that the answer to the
question gets lost. Oddly enough, the original problem no longer
appears in the quoted text.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

==============================================================================
TOPIC: Returning a private nested class of a class template
http://groups.google.com/group/comp.lang.c++/t/324488f7f247fb0a?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 1 2009 3:34 am
From: James Kanze

On Jan 1, 1:15 am, red floyd <no.spam.h...@example.com> wrote:
> ym...@hotmail.com wrote:

> > I have a class with a friend function that returns an
> > instance of a private nested class:

> > //--------------------------------------------------
> > class A {
> > class B {};
> > friend B func(double x);
> > };

> > A::B func(double x) {return A::B();}

> > int main() {
> > func(1.2);
> > return 0;
> > }
> > //------------------------------------------------

> > This code compiles and runs on the MS Visual C++ 2008
> > compiler. However, if I use a class template instead:

> > //--------------------------------------------------
> > template<typename T> class A {
> > class B {};
> > friend B func(T x);
> > };

> > template<typename T> typename A<T>::B func(T x) {return A<T>::B();}

> > int main() {
> > func(1.2); // <-- error received here
> > return 0;
> > }
> > //------------------------------------------------

> > I get an error:
> > error C2248: 'A<T>::B' : cannot access private class declared in class
> > 'A<T>'.
> > Notice the error is in 'main', and not in the function
> > definition, so I don't think the problem is with the friend
> > declaration.

> > So is returning an instance of a private nested class legal
> > or not?

> No, it's not legal, because the destructor for the private
> class needs to run.

And the standard says explicitly that this is checked in the
context of the call.

Which doesn't explain whey the non-template version compiled.
It shouldn't, either.

==============================================================================
TOPIC: Weird Function Declaration
http://groups.google.com/group/comp.lang.c++/t/1976c4d0730bf7fd?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Jan 1 2009 3:51 am
From: Steve Chow

I recently saw this in some C++/OpenGL (it is apparently required)
code (and this is a C++ question, not OpenGL). And the relevant part
went something like this:

#ifndef CALLBACK
#define CALLBACK

soft and program

Thursday, January 1, 2009

comp.lang.c++ - 24 new messages in 9 topics - digest

No comments:

Blog Archive

About Me