Board index » cppbuilder » BDS2006 C++ Properties and STL

BDS2006 C++ Properties and STL


2006-04-21 02:05:06 PM
cppbuilder18
I am testing a class in BDS2006. It has some properties. I want to put
it in a std::vector, but when I compile I get en error
[C++ Error] xutility(1515): E2328 Classes with properties cannot be
copied by value
#include <vcl.h>
#pragma hdrstop
#include <vector>
#include <iostream>
#include <algorithm>
class TLegendSectionItem
{
private:
AnsiString caption;
int other;
public:
TLegendSectionItem(const AnsiString &name, int value)
: caption(name)
, other(value)
{
}
/* TLegendSectionItem(const TLegendSectionItem &rhs)
: caption(rhs.caption)
, other(rhs.other)
{
}
TLegendSectionItem &operator =(const TLegendSectionItem &rhs)
{
caption = rhs.caption;
other = rhs.other;
return *this;
}
*/
__property AnsiString Caption = { read = caption, write = caption };
};
#pragma argsused
int main(int argc, char* argv[])
{
std::vector<TLegendSectionItem>items;
items.push_back(TLegendSectionItem("Apples", 1));
return 0;
}
If I uncomment the assignment operator and copy constructor I don't get
the error. The same code compiles without error in BCB6. Is this a
feature or a bug. Can I disable this error?
John.
 
 

Re:BDS2006 C++ Properties and STL

On Fri, 21 Apr 2006 18:05:06 +1200, John Grabner < XXXX@XXXXX.COM >wrote:
Quote
I am testing a class in BDS2006. It has some properties. I want to put
it in a std::vector, but when I compile I get en error

[C++ Error] xutility(1515): E2328 Classes with properties cannot be
copied by value
This "feature" is present even in previous versions of BCC.
As far as I know, you have to live with such BCC's behaviour.
Giuliano
 

Re:BDS2006 C++ Properties and STL

John Grabner wrote:
Quote
I am testing a class in BDS2006. It has some properties. I want to put
it in a std::vector, but when I compile I get en error

[C++ Error] xutility(1515): E2328 Classes with properties cannot be
copied by value
Best put the pointer of the object into the vector.
std::vector<TLegendSectionItem*>items;
items.push_back(new TLegendSectionItem("Apples", 1));
regards
Martin
 

{smallsort}

Re:BDS2006 C++ Properties and STL

Martin Kaul < XXXX@XXXXX.COM >wrote:
Quote
John Grabner wrote:
>I am testing a class in BDS2006. It has some properties. I want to put
>it in a std::vector, but when I compile I get en error
>
>[C++ Error] xutility(1515): E2328 Classes with properties cannot be
>copied by value
Why are you using properties? They're non-standard, and really meant for
VCL's UI elements. If you don't intend to have them accessed by the form
designer, then properties aren't a very good idea.
Quote
Best put the pointer of the object into the vector.

std::vector<TLegendSectionItem*>items;
items.push_back(new TLegendSectionItem("Apples", 1));
*COUGH*
A smart pointer to it, yes. A raw pointer? Ouch!
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
 

Re:BDS2006 C++ Properties and STL

John Grabner < XXXX@XXXXX.COM >writes:
Quote
I am testing a class in BDS2006. It has some properties. I want to put
it in a std::vector, but when I compile I get en error

[C++ Error] xutility(1515): E2328 Classes with properties cannot be
copied by value
They are not supposed to be copied by value, and that means the vcl
object is expected to be allocated from the heap. You'd do well to
use a vector of smart pointers to hold the dynamically allocated
objects.
--
Chris (TeamB);
 

Re:BDS2006 C++ Properties and STL

"John Grabner" < XXXX@XXXXX.COM >wrote in message
Quote
I am testing a class in BDS2006. It has some properties. I want to put
it in a std::vector, but when I compile I get en error

[C++ Error] xutility(1515): E2328 Classes with properties cannot be
copied by value
<code snipped>
Quote
If I uncomment the assignment operator and copy constructor I don't get
the error. The same code compiles without error in BCB6. Is this a
feature or a bug. Can I disable this error?
It should not compile in BCB6 either (are you sure it compiles in BCB6?).
Some have suggested that you use a smart pointer here -- whether you do that
or not may depend on your preferences. Personally, I oftentimes prefer to
create objects on the stack because it can be faster than dynamic
allocation, reduces memory fragmentation over time, and gives you the same
benefit that a smart pointer does with respect to exception safety. So what
I do is simply create an assignment operator and copy-constructor (and a
destructor, of course) just as you have done.
- Dennis
 

Re:BDS2006 C++ Properties and STL

Alan Bellingham wrote:
Quote
Martin Kaul < XXXX@XXXXX.COM >wrote:


>John Grabner wrote:
>
>>I am testing a class in BDS2006. It has some properties. I want to put
>>it in a std::vector, but when I compile I get en error
>>
>>[C++ Error] xutility(1515): E2328 Classes with properties cannot be
>>copied by value


Why are you using properties? They're non-standard, and really meant for
VCL's UI elements. If you don't intend to have them accessed by the form
designer, then properties aren't a very good idea.

It is someone's else class. It is used in conduction with a VCL
component (TChart). The person feels that having all the objects in this
area use a VCL style interface causes less confusion.
Quote

>Best put the pointer of the object into the vector.
>
>std::vector<TLegendSectionItem*>items;
>items.push_back(new TLegendSectionItem("Apples", 1));


*COUGH*

A smart pointer to it, yes. A raw pointer? Ouch!

Alan Bellingham
 

Re:BDS2006 C++ Properties and STL

Giuliano wrote:
Quote
On Fri, 21 Apr 2006 18:05:06 +1200, John Grabner < XXXX@XXXXX.COM >wrote:


>I am testing a class in BDS2006. It has some properties. I want to put
>it in a std::vector, but when I compile I get en error
>
>[C++ Error] xutility(1515): E2328 Classes with properties cannot be
>copied by value


This "feature" is present even in previous versions of BCC.
As far as I know, you have to live with such BCC's behaviour.

Giuliano
It compiles in BCB6.
John.
 

Re:BDS2006 C++ Properties and STL

Alan Bellingham wrote:
Quote
>std::vector<TLegendSectionItem*>items;
>items.push_back(new TLegendSectionItem("Apples", 1));


*COUGH*

A smart pointer to it, yes. A raw pointer? Ouch!
Why not a raw pointer?
best regards
Martin
 

Re:BDS2006 C++ Properties and STL

Martin Kaul < XXXX@XXXXX.COM >wrote:
Quote
Why not a raw pointer?
Because raw pointers in vectors - or at least raw ownership pointers -
are a recipe for leaks.
Alan Bellingham
--
Team Thai Kingdom
<url:www.borland.com/newsgroups/>Borland newsgroup descriptions
<url:www.borland.com/newsgroups/netiquette.html>netiquette
 

Re:BDS2006 C++ Properties and STL

On Mon, 24 Apr 2006 09:01:01 +1200, John Grabner < XXXX@XXXXX.COM >wrote:
Quote
It compiles in BCB6.
I've the same error on a BCB6 projects.
 

Re:BDS2006 C++ Properties and STL

Alan Bellingham wrote:
Quote
Martin Kaul < XXXX@XXXXX.COM >wrote:


>Why not a raw pointer?


Because raw pointers in vectors - or at least raw ownership pointers -
are a recipe for leaks.
You are right with local vectors - normaly I use vectors with pointers
mostly as attributes of classes. In the destructor I delete all objects
the vector contains.
Hmm, I think I must take a look at smart-pointers. I have no problems
with raw-pointers cause I know the pitfalls but possibly smart-pointers
make live easier.
What kind of smart-pointer do you use? auto_ptr?
best regards
Martin
 

Re:BDS2006 C++ Properties and STL

Martin Kaul < XXXX@XXXXX.COM >wrote:
Quote
Hmm, I think I must take a look at smart-pointers. I have no problems
with raw-pointers cause I know the pitfalls but possibly smart-pointers
make live easier.
If you ever copy a vector of pointers, who actually owns the contents
gets ... interesting.
Quote
What kind of smart-pointer do you use? auto_ptr?
Well, std::auto_ptr<>is actually incompatible with std::vector<>,
deliberately so, since std::auto_ptr<>has very non-standard copy
semantics.
I'd go for boost::shared_ptr<>. It also solves the
multiple-pointer-ownership problem.
Alan Bellingham
--
ACCU Conference 2006 - 19-22 April, Randolph Hotel, Oxford, UK
 

Re:BDS2006 C++ Properties and STL

Alan Bellingham wrote:
Quote
Martin Kaul < XXXX@XXXXX.COM >wrote:


>Hmm, I think I must take a look at smart-pointers. I have no problems
>with raw-pointers cause I know the pitfalls but possibly smart-pointers
>make live easier.


If you ever copy a vector of pointers, who actually owns the contents
gets ... interesting.
Mostly of my classes that holds data/objects in containers are Managers
or VCL Forms. Copying VCL-Forms is not possible and my Managers are
singletons.
When I create a classes that works as a manager the first thing I do is
makeing the copy-constructor and the assignment-operator private without
body to avoid using the default copy-constructor and assignment-operator.
Quote


>What kind of smart-pointer do you use? auto_ptr?


Well, std::auto_ptr<>is actually incompatible with std::vector<>,
deliberately so, since std::auto_ptr<>has very non-standard copy
semantics.

I'd go for boost::shared_ptr<>. It also solves the
multiple-pointer-ownership problem.
OK then I must take a look at the boost-library.
best regards
Martin
 

Re:BDS2006 C++ Properties and STL

Martin Kaul < XXXX@XXXXX.COM >wrote:
Quote
OK then I must take a look at the boost-library.
That's strongly recommended, anyway.
Alan Bellingham
--
ACCU Conference 2007 - venue to be determined.