Is it bad style of coding ??

class Example has operator+= overloads.
Example Class keeps a private vector of std::vector<X*> type that it updates with several functions and operator overloads.

Code:

---

Example& operator+=(X* x);
Example& operator+=(X& x);

---

X is a Class that takes have constructor (not explicit) that takes int.

Code:

---

X* x1 = new X(1);
X* x2 = new X(2);
X x3(3);
X x4 = 4;
Example ex;
ex += x1;
ex += x2;
ex += x3;
ex += x4;

---

So all this works as expected. But What I want to do is.

Code:

---

ex += 5;

---

But it requires signature to be

Code:

---

Example& operator+=(const X& x);

---

But I am storing non-const pointers in the vector.

So What I did is I const_cast<X*>(x) it in operator+=(const X&)

Now Is that a design flaw ??
cause I am not maintaining the constness.

actually I dont use const_cast much thats why I am asking is what I am doing assumed as bad style of coding ??

In any case operator+= should not modify the right-hand argument.

It is hard to understand what you are doing (IMO, overloading the same operator for pointers and objects is strange too): are you taking the address of the object passed in and storing it somewhere? In which case are you sure that you aren't eventually storing pointers to objects that have a short lifetime?

Would this work?

Code:

---

Example ex;
for (int i = 0; i != 10; ++i) {
    X x(n);
    ex += x;
}

---

const_cast is bad... Why would you even want it? I assume that the operator+= does not modify it's argument. Could you paste the operator+= code, maybe there's something bad in there.

So yeah, make it const. If you call a function on the object, you'll want that function to be const to, like this:
int getSomething() const;

That is absolutely broken. You're storing a pointer to a temporary, and your program will crash or misbehave sooner or later.

My intension is to do ex += 5.

so what if I do accept const X& x as arguments and pass it as

X* __tmp = new X(x);
l.oush_back(__tmp);

I don't this these dangaling problems would appear.

True. Of course, then there's also no problem with the const.

However, unless you are writing a compiler or standard library implementation, it is a bad coding practice to use __tmp as a variable name since identifier names that contain consecutive underscores are reserved to the implementation for any use.

Ya I now that.

However one thing I would like to make sure

when an application exists does all Operating System cleans the garbage memory(e.g. new Objects on which delete has not been used) accuired by it automatically ??

Quote:

---

when an application exits does all Operating System cleans the garbage memory(e.g. new Objects on which delete has not been used) accuired by it automatically ??

---

No, but many of the modern ones do.

so any based on Linux kernal 2.6+ , Mac, windowx Xp+ offers this features ??

But If I code like this a different problem will appear if I do this. although the problem is not so critical or important.

it is when a pointer is supplied its the vector content is linked with the actual content when a reference is supplied the vector content is also linked with the original one.
But when a const reference is supplied its clone is there on vector content.

Yep. But how do you expect to link against the literal 5?

And yes, all Linux (even kernel 1.0), Mac and Windows NT and Windows 9x series OSs free an application's resources when it exits.

I dont expect a link against literal 5
but not only literals require const X& during += operator overload
But If somebody does like.

const X& y = SOMETHING;
Example ex;
ex += y;

then somebody e.g. the user of tsih Example Class might expect that internal vector holds a link to y.

Perhaps.

But this is the point where I start questioning your motive in writing this class, so it's hard for me to understand your envisioned usage problems.

Ok I think these few Lines of Code will explore What I am trying to do.

Code:

---

Js::Array ex;
ex += Js::Number(2);
ex += Js::String("Hello");
ex += "Hello World"
ex += 20;

---

+= is a testing operator I might be using the same technique on operator [] too.

Its a CGI Application where Js::Array will be commited to client side and write a Javascript Array.

**I belief that code for a CGI application should be easy and flexible so one of my target is syntactic ease and flexibility.

So you've basically got an object identity disconnect. You don't have a proper distinction between what is a by-value object and what is an object reference (pointer). And you just found out that this just doesn't work in C++. You always need to distinguish between having a value (copied when passed), a C++ reference (cannot be reassigned), and a pointer (can be reassigned).

The solution I recommend is making the by-reference holding explicit.

Code:

---

Js::Array ex;
Js::Object foo;
ex += ref(foo); // Array element references foo
ex += foo; // Array element doesn't reference foo

---