char * memory leak

[Alf P. Steinbach]

* Default User:

The reasoning was that which followed in my next paragraph of my
previous message. The requirement is that void* have the representation
of char*, so it is char* that is the determining factor. Do you feel
that is not the case?

It's not a valid inference. First, "same as" is not a one-way
correspondence: it works both ways, so that your reasoning would work
just as well for the opposite conclusion. Second, since void* must
accomodate all data pointers, there is more involved.

That doesn't mean that I disagree strongly with the conclusion as such,
but it's like concluding that of two sisters A and B sister A is the
older (first) one because sister B is just like her in many respects.

So I wrote "probably", and with quite different reasoning.


Cheers, & hth.,

- Alf

 

[Kai-Uwe Bux]

* Default User:

It's not a valid inference. First, "same as" is not a one-way
correspondence: it works both ways, so that your reasoning would work
just as well for the opposite conclusion. Second, since void* must
accomodate all data pointers, there is more involved.

That doesn't mean that I disagree strongly with the conclusion as such,
but it's like concluding that of two sisters A and B sister A is the
older (first) one because sister B is just like her in many respects.

So I wrote "probably", and with quite different reasoning.

What about a completely different reasoning based in [3.9.2/4]:

[...] A cv-qualified or cv-unqualified (3.9.3) void* shall have the same
representation and alignment requirements as a cv-qualified or
cv-unqualified char*.


Best

Kai-Uwe Bux

 

[Alf P. Steinbach]

* Kai-Uwe Bux:

* Default User:
It's not a valid inference. First, "same as" is not a one-way
correspondence: it works both ways, so that your reasoning would work
just as well for the opposite conclusion. Second, since void* must
accomodate all data pointers, there is more involved.

That doesn't mean that I disagree strongly with the conclusion as such,
but it's like concluding that of two sisters A and B sister A is the
older (first) one because sister B is just like her in many respects.

So I wrote "probably", and with quite different reasoning.

What about a completely different reasoning based in [3.9.2/4]:

[...] A cv-qualified or cv-unqualified (3.9.3) void* shall have the same
representation and alignment requirements as a cv-qualified or
cv-unqualified char*.

I learned over in [microsoft.public.vc.language] that that's called
"taking a George".

2 minutes after someone's has mentioned how odd it is that it's snowing
in mid-summer, George will exclaim with nearly but not quite the same
wording, and referring to the same subject matter, "hey, isn't it odd
that it's snowing now in mid-summer"?

The item you quote is or was the item under discussion, referred to
earlier up the thread (originally by me), and you fail to provide any
reasoning whatsoever -- quoting the item under discussion is not
reasoning -- much less reasoning that would be completely different,
unless lack of reasoning qualifies as completely different reasoning.


Cheers, & hth.,

- Alf

 

[Kai-Uwe Bux]

* Kai-Uwe Bux:

* Default User:
Alf P. Steinbach wrote:

* Default User:
Alf P. Steinbach wrote:

* Travis:
Quick question, how is a char * different than any other
pointer? I've never had this really elaborated.
That's not a quick question.

'char' is the smallest addressable unit of memory in C and C++.

First, this means a char* pointer may on some architectures need
to be larger than other data pointers (excluding member data
pointers), and in effect it probably determines the size of
void*, which must be large enough for any data pointer.
Not probably.
Well I fail to find any hard information on what determines what.

If you have, then that would be nice. Do you?
The reasoning was that which followed in my next paragraph of my
previous message. The requirement is that void* have the representation
of char*, so it is char* that is the determining factor. Do you feel
that is not the case?
It's not a valid inference. First, "same as" is not a one-way
correspondence: it works both ways, so that your reasoning would work
just as well for the opposite conclusion. Second, since void* must
accomodate all data pointers, there is more involved.

That doesn't mean that I disagree strongly with the conclusion as such,
but it's like concluding that of two sisters A and B sister A is the
older (first) one because sister B is just like her in many respects.

So I wrote "probably", and with quite different reasoning.

What about a completely different reasoning based in [3.9.2/4]:

[...] A cv-qualified or cv-unqualified (3.9.3) void* shall have the
[same
representation and alignment requirements as a cv-qualified or
cv-unqualified char*.

I learned over in [microsoft.public.vc.language] that that's called
"taking a George".

2 minutes after someone's has mentioned how odd it is that it's snowing
in mid-summer, George will exclaim with nearly but not quite the same
wording, and referring to the same subject matter, "hey, isn't it odd
that it's snowing now in mid-summer"?

The item you quote is or was the item under discussion, referred to
earlier up the thread (originally by me), and you fail to provide any
reasoning whatsoever -- quoting the item under discussion is not
reasoning -- much less reasoning that would be completely different,
unless lack of reasoning qualifies as completely different reasoning.

Well, you can avoid such confusion by not snipping away relevant context.
The provision I quoted is clearly reasoning different from the one that was
before me in my newsreader. From what I saw, I wasn't able to tell that the
underlying issue had been addressed already.


Best

Kai-Uwe Bux

 

[Gerry Ford]

Lustig, zwar.

Wie waer das auf deutsch? sich georgieren?

--
Gerry Ford
"Er hat sich Georgiert." Der Spiegel, 2008, sich auf George bezuegend.

* Kai-Uwe Bux:

Alf P. Steinbach wrote:

* Default User:
Alf P. Steinbach wrote:

* Default User:
Alf P. Steinbach wrote:

* Travis:
Quick question, how is a char * different than any other
pointer? I've never had this really elaborated.
That's not a quick question.

'char' is the smallest addressable unit of memory in C and C++.

First, this means a char* pointer may on some architectures need
to be larger than other data pointers (excluding member data
pointers), and in effect it probably determines the size of
void*, which must be large enough for any data pointer.
Not probably.
Well I fail to find any hard information on what determines what.

If you have, then that would be nice. Do you?
The reasoning was that which followed in my next paragraph of my
previous message. The requirement is that void* have the
representation
of char*, so it is char* that is the determining factor. Do you feel
that is not the case?
It's not a valid inference. First, "same as" is not a one-way
correspondence: it works both ways, so that your reasoning would work
just as well for the opposite conclusion. Second, since void* must
accomodate all data pointers, there is more involved.

That doesn't mean that I disagree strongly with the conclusion as such,
but it's like concluding that of two sisters A and B sister A is the
older (first) one because sister B is just like her in many respects.

So I wrote "probably", and with quite different reasoning.

What about a completely different reasoning based in [3.9.2/4]:

[...] A cv-qualified or cv-unqualified (3.9.3) void* shall have the
[same
representation and alignment requirements as a cv-qualified or
cv-unqualified char*.

I learned over in [microsoft.public.vc.language] that that's called
"taking a George".

2 minutes after someone's has mentioned how odd it is that it's snowing
in mid-summer, George will exclaim with nearly but not quite the same
wording, and referring to the same subject matter, "hey, isn't it odd
that it's snowing now in mid-summer"?

The item you quote is or was the item under discussion, referred to
earlier up the thread (originally by me), and you fail to provide any
reasoning whatsoever -- quoting the item under discussion is not
reasoning -- much less reasoning that would be completely different,
unless lack of reasoning qualifies as completely different reasoning.

Well, you can avoid such confusion by not snipping away relevant context.
The provision I quoted is clearly reasoning different from the one that
was
before me in my newsreader. From what I saw, I wasn't able to tell that
the
underlying issue had been addressed already.


Best

Kai-Uwe Bux

 

[Tobias]

/* Yesterday, I did miss something. You also need to define your own
copy constructor and assignment constructor in order to do the deep
copy.
*/


MyClass::MyClass(const MyClass& m) {
if( m.name ) {
size_t len = strlen(m.name);
if( len < maxLen ) {
name = new char [ len+1 ];
if(name) {
strcpy(name,m.name);
}
}
else {
name = new char [ sizeof(defaultName) ];
if(name) {
strcpy(name,defaultName);
}
}
}
SetToDefault = false;
}

MyClass& MyClass:perator = (const MyClass& m) {
SetToDefault = false;
SetName(m.name);
SetToDefault = m.SetToDefault;
return *this;
}

 

[Alf P. Steinbach]

* Tobias:

/* Yesterday, I did miss something. You also need to define your own
copy constructor and assignment constructor in order to do the deep
copy.
*/

I understand this code is meant to show what to do when using raw
character arrays directly instead of std::string.

MyClass::MyClass(const MyClass& m) {
if( m.name ) {
size_t len = strlen(m.name);
if( len < maxLen ) {
name = new char [ len+1 ];
if(name) {
strcpy(name,m.name);

With a standard-conforming compiler name will always be non-zero,
because if new fails you get an exception.

}
}
else {
name = new char [ sizeof(defaultName) ];
if(name) {
strcpy(name,defaultName);
}
}
}
SetToDefault = false;
}

MyClass& MyClass:perator = (const MyClass& m) {
SetToDefault = false;
SetName(m.name);
SetToDefault = m.SetToDefault;
return *this;
}

The usual idiom for operator= is to express it in terms of copy
construction and a swap operation,

void MyClass::swap( MyClass& other )
{
std::swap( name, other.name );
std::swap( SetToDefault, other.SetToDefault );
}

MyClass& MyClass:perator=( MyClass other )
{
swap( other );
return *this;
}

It simpler and more safe, especially with respect to exceptions, and
avoids redundancy (same code duplicated in copy constructor and
assignment operator or functions called from assignment operator).

Usually there's no reason to not use this idiom when an assignment
operator is required, but of course by having class type data members,
such as e.g. std::string instead of a pointer to array, you can avoid
the whole problem and simply let the compiler provide assignment.


Cheers, & hth.,

- Alf

 

[Default User]

* Default User:

It's not a valid inference.

I disagree (obviously).

First, "same as" is not a one-way
correspondence: it works both ways, so that your reasoning would work
just as well for the opposite conclusion. Second, since void* must
accomodate all data pointers, there is more involved.

If they wanted that, they could have said, "void* and char* shall have
the same representation". They very specifically said that void* is the
same a char*.

As others have pointed out, there may be other factors driving char*
requirements. void* has to pick those up.

That doesn't mean that I disagree strongly with the conclusion as
such, but it's like concluding that of two sisters A and B sister A
is the older (first) one because sister B is just like her in many
respects.

So I wrote "probably", and with quite different reasoning.

You're free to go with that, of course. I'll respectfully disagree.



Brian

 

[Alf P. Steinbach]

* Default User:

I disagree (obviously).

Validity of logical inference isn't open to agreement or disagreement.

Logic is not a matter of feeling.

If they wanted that, they could have said, "void* and char* shall have
the same representation". They very specifically said that void* is the
same a char*.

If "they" didn't want that paragraph to mean "Pascal is really better",
then "they" wouldn't have used that blindingly-obvious code phrase
"cv-qualified or cv-unqualified", but simply said nothing about that.
So it's obvious that the sentence means "Pascal is really better".

As others have pointed out, there may be other factors driving char*
requirements. void* has to pick those up.

I think you mean me, not "others".


Perplexed,

- Alf

 

[Default User]

* Default User:

If "they" didn't want that paragraph to mean "Pascal is really
better", then "they" wouldn't have used that blindingly-obvious code
phrase "cv-qualified or cv-unqualified", but simply said nothing
about that. So it's obvious that the sentence means "Pascal is really
better".

I don't see how that follows. However, you're obviously determined to
be stubborn about it. I don't agree, and won't agree, that there is any
sort of commutative property expressed. You are free to hold a
differing opinion.




Brian

 

[Alf P. Steinbach]

* Default User:

I don't see how that follows. However, you're obviously determined to
be stubborn about it. I don't agree, and won't agree, that there is any
sort of commutative property expressed.

"same as" is commutative.

To prove your point about non-communitativity of "same as" you have to
demonstrate that void* can have the same representation as char*, while
simultanously, char* does not have the same representation as void*.

More generally, you have to prove that A can be the same as B, while
simultanously B isn't the same as A.

You are free to hold a differing opinion.

There is no opinion involved.


Cheers, & hth.,

- Alf

 

[Default User]

* Default User:

"same as" is commutative.

To prove your point about non-communitativity of "same as" you have
to demonstrate that void* can have the same representation as char*,
while simultanously, char* does not have the same representation as
void*.

More generally, you have to prove that A can be the same as B, while
simultanously B isn't the same as A.

No. We're discussing English.

There is no opinion involved.

Oh, I think there's ample evidence to the contrary.



Brian

 

[Daniel T.]

No. We're discussing English.


Oh, I think there's ample evidence to the contrary.

Brian, are you really arguing that "'A' shall be the same as 'B'" has a
different meaning than "'A' and 'B' shall be the same"? Can you give a
context, any context, where one of the phrases is true, while the other
is false?

From the quote I read, I expect the following assert to never fire:

assert( sizeof( void* ) == sizeof( char* ) );

How do you interpret it?

 

[Default User]

Daniel T. wrote:

Brian, are you really arguing that "'A' shall be the same as 'B'" has
a different meaning than "'A' and 'B' shall be the same"? Can you
give a context, any context, where one of the phrases is true, while
the other is false?

Very Weird Company came out with new rule. Each day, John Robertson is
required to wear a hat that is the same size and color as that of
Robert Johnson. So each day, they have a hat the same size and color.

Now, is it reciprocal? Is Robert required to wear a hat the same size
and color as John?

From the quote I read, I expect the following assert to never fire:

assert( sizeof( void* ) == sizeof( char* ) );

Yes, that's because void* is required to be the same representation as
char*.



Brian

 

[Alf P. Steinbach]

* Default User:

Daniel T. wrote:



Very Weird Company came out with new rule. Each day, John Robertson is
required to wear a hat that is the same size and color as that of
Robert Johnson. So each day, they have a hat the same size and color.

Now, is it reciprocal? Is Robert required to wear a hat the same size
and color as John?

True, but the analogy is flawed, because (1), most important, it
introduces the possibility of non-conformance, where you don't have "is
guaranteed to be the same" but "might be the same, depending on personal
whim", which is due to a much weaker meaning of "shall" in this context,
and (2) it introduces the idea of selective punishment of only void*
pointers when void* and char* differ in representation. If instead it's
a decree from the omnipotent arch-angels of Allah that John shall and
will always wear a hat identical to Robert's, then Robert has no say in
the matter. Whatever he does, the arch-angels have ensured that he will
end up wearing a hat identical to John's, and the punishment for
non-conformance, if any, is therefore not meted out to John or Robert,
but to the arch-angels' sub-contractors, i.e. to the compiler vendor.

In C++, char* is required to have the same representation as void*.

If they're different, it's not just char* that's non-comforming, and
it's also not just void*, it's the compiler as a whole: you simply can't
say that for this compiler char* is conforming but void* is not, and
conversely, if the compiler vendor increases sizeof(void*) in order to
anticipate some future need, then that necessitates changing also char*.

Yes, that's because void* is required to be the same representation as
char*.

You mean, it's because char* is required to be the same representation
as void*.


Cheers, & hth.,

- Alf

 

[Daniel T.]

Daniel T. wrote:

Very Weird Company came out with new rule. Each day, John Robertson is
required to wear a hat that is the same size and color as that of
Robert Johnson. So each day, they have a hat the same size and color.

Now, is it reciprocal? Is Robert required to wear a hat the same size
and color as John?

But can you give a context where one of the phrases is true, while the
other is false? The above doesn't do that. "John's hat shall be the
same as Robert's hat", and "John's hat and Robert's hat shall be the
same." are both always true.

Yes, that's because void* is required to be the same representation as
char*.

Is char* required to be the same representation as void*, or may char*
have a different representation than void*?

 

[Default User]

True, but the analogy is flawed, because (1), most important, it
introduces the possibility of non-conformance, where you don't have
"is guaranteed to be the same" but "might be the same, depending on
personal whim"

No, that just makes it a non-conforming day. But that's irrelevant,
because the hat John wears levies no requirements on the one Robert
wears.

In C++, char* is required to have the same representation as void*.

If they're different, it's not just char* that's non-comforming, and
it's also not just void*, it's the compiler as a whole: you simply
can't say that for this compiler char* is conforming but void* is
not, and conversely, if the compiler vendor increases sizeof(void*)
in order to anticipate some future need, then that necessitates
changing also char*.

True, but again irrelevant. It's still char* that's the driver for
void*. No probably about it.




Brian

 

[Kai-Uwe Bux]

No, that just makes it a non-conforming day. But that's irrelevant,
because the hat John wears levies no requirements on the one Robert
wears.


True, but again irrelevant. It's still char* that's the driver for
void*. No probably about it.

I have a very hard time understanding what you are trying to say. Suppose
the committee changed the wording to:

A cv-qualified or cv-unqualified (3.9.3) char* shall have the same
representation and alignment requirements as a cv-qualified or
cv-unqualified void*.

No compiler vendor would have to issue a fix. The language would not change.
The two standards would be equivalent and the above requirement is
fullfilled by any conforming implementation.

It's just like some describing the knights move in chess as: "two fields in
horizontal or vertical direction followed by one field in a perpendicular
direction" and another says "one field in horizontal or vertical direction
followed by two fields in a perpendicular direction".


As for the particular wording "it's still char* that's the driver for
void*", I wouldn't think that this follows from the standard. In fact, the
standard places some additional burdens on void* (e.g., that it must be
capable of representing any pointer-to-object). Those requirements then
turn into requirements for char* by means of [3.9.2/4] despite the wording
being reversed. In your metaphor: it's like company regulations read as
follows:
a) Personell shall ensure that John wears a hat of the
same color as Robert.
b) Personell shall ensure that John wears a white hat.


Best

Kai-Uwe Bux