Templates, Structs and Invalid Pointers - where did it go wrong

[DaveJ]

Recently I was working on a project where I came across an issue where
the program cored and reported "free(): invalid pointer".
I found a resolution for this, but don't fully understand why the
issue occurred in the first place.

The project uses a simple template class that acts as a buffer.
Initially it has a fixed length, but it's append methods will extend
the size of the buffer if necessary.

Another class defines a struct, that contains this template class as a
member. In one function the struct is created, but when it goes out
of scope the program cores.

Examining the core it appears a call to free in the template classes
destructor caused the core. When I traced through the code with the
debugger I found that after the template class constructor exits, the
address that one of its member's points to changes.

Anyway I've included a cut down and simplified version of the code
below. I found the resolution was to modify the struct so that it
takes a reference to the template class.
------ VarBuf Class <VarBuf.h------
#ifndef __TVARBUF_H__
#define __TVARBUF_H__

#include <stddef.h>
#include <string.h>
#include <stdlib.h>

template<size_t Nclass TVarBuf
{
public:
TVarBuf (const char *initStr);
~TVarBuf ();
private:
char m_Buf[N + 1];
char* m_Str;
size_t m_Capacity;
size_t m_Length;
};
#endif

template<size_t N>
TVarBuf<N>::TVarBuf(const char *initStr) :
m_Str(NULL),
m_Capacity(N),
m_Length(0)
{
m_Str = m_Buf;
m_Str[0] = '\0';
}

template<size_t N>
TVarBuf<N>::~TVarBuf()
{
if(m_Str != m_Buf)
{
free(m_Str);
}
}

---------------------------------

---- Main App <main.cpp-----

1 #include "VarBuf.h"
2 #include "stdio.h"
3 #include "time.h"

4 typedef TVarBuf<6ProfKey; // Create a typedef for our template
class

5 typedef struct
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 } Prof;
12
13 int main(int argc, char** argv)
14 {
15 {
16 time_t now = time(NULL);
17 Prof profile = {now, 0, 0, NULL};
18 } // Application cores after it leaves here and the profile
object goes out of scope
19 return 0;
20 }

------------------------------------------

Compiling the above code with the following command
g++ -g -Wall -omain main.cpp

and running the main binary results in:
free(): invalid pointer 0xbfffd66c!

I modified the code slightly so that line 10 of main reads:
-----------------------------------------------
ProfKey& m_OldestProfUrl; //take a reference to ProfKey
-----------------------------------------------
and line 17 now reads
------------------------------------------------
ProfKey key(NULL);
Prof profile = {now, 0, 0, key}
------------------------------------------------

Any explanation of whats going on here would be good.

[anon]

DaveJ wrote:
[...]

>
Another class defines a struct, that contains this template class as a
member. In one function the struct is created, but when it goes out
of scope the program cores.

It doesn't core for me (unfortunately)

Examining the core it appears a call to free in the template classes
destructor caused the core. When I traced through the code with the

Here is even smaller example producing exactly what you are doing:

int main()
{
int a = 5;
int *b = &a;
free( b );
}

debugger I found that after the template class constructor exits, the
address that one of its member's points to changes.

Anyway I've included a cut down and simplified version of the code
below. I found the resolution was to modify the struct so that it
takes a reference to the template class.

I guess you are out of luck. What you are doing is not allowed.

>
------ VarBuf Class <VarBuf.h------
#ifndef __TVARBUF_H__
#define __TVARBUF_H__

#include <stddef.h>
#include <string.h>
#include <stdlib.h>

These are c headers. Should be:
#include <cstddef>
#include <cstring>
#include <cstdlib>

>
template<size_t Nclass TVarBuf
{
public:
TVarBuf (const char *initStr);
~TVarBuf ();
private:
char m_Buf[N + 1];
char* m_Str;
size_t m_Capacity;
size_t m_Length;
};
#endif

template<size_t N>
TVarBuf<N>::TVarBuf(const char *initStr) :

initStr is not used

m_Str(NULL),
m_Capacity(N),
m_Length(0)
{
m_Str = m_Buf;
m_Str[0] = '\0';
}

template<size_t N>
TVarBuf<N>::~TVarBuf()
{
if(m_Str != m_Buf)

should be
if (m_Str != &m_Buf[0])

{
free(m_Str);

Where do you allocate this memory?

}
}

---------------------------------

---- Main App <main.cpp-----

1 #include "VarBuf.h"
2 #include "stdio.h"
3 #include "time.h"

Do not use c headers in a c++ program

>
4 typedef TVarBuf<6ProfKey; // Create a typedef for our template
class

This typedef looks very C-ish

5 typedef struct
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 } Prof;
12
13 int main(int argc, char** argv)
14 {
15 {
16 time_t now = time(NULL);
17 Prof profile = {now, 0, 0, NULL};
18 } // Application cores after it leaves here and the profile
object goes out of scope
19 return 0;
20 }

------------------------------------------

Compiling the above code with the following command
g++ -g -Wall -omain main.cpp

and running the main binary results in:
free(): invalid pointer 0xbfffd66c!

I modified the code slightly so that line 10 of main reads:
-----------------------------------------------
ProfKey& m_OldestProfUrl; //take a reference to ProfKey
-----------------------------------------------
and line 17 now reads
------------------------------------------------
ProfKey key(NULL);
Prof profile = {now, 0, 0, key}
------------------------------------------------

This doesn't solve your problem, which is in the TVarBuf class

[DaveJ]

On Aug 28, 10:36 am, anon <[e-mail]:

DaveJ wrote:

initStr is not used

I've reduced the size of VarBuf.h as the actual class is fairly
large. The real class does use the initStr, but in my case it should
always be NULL.

m_Str(NULL),
m_Capacity(N),
m_Length(0)
{
m_Str = m_Buf;
m_Str[0] = '\0';
}

I think the issue lies around the re-assignment of m_Str.

In the constructor m_Str = m_Buf; seems fine.
After the constructor exists the address that m_Str points to suddenly
changes.

5 typedef struct
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 } Prof;
12

This only occurs if I create the VarBuf from within a struct (with or
without the typedef). If I create it directly in the method there is
no problem.

It's interesting that you say it didn't core for you. Initially this
was in a program which ran on RedHat3 for years without issue. When
we moved it to RH5 the core started occurring (although I have now
been able to replicate it on some RH3 machines).

[anon]

DaveJ wrote:

>> m_Str(NULL),
m_Capacity(N),
m_Length(0)
{
m_Str = m_Buf;

should be:
m_Str = &m_Buf[0];

>> m_Str[0] = '\0';
}

I think the issue lies around the re-assignment of m_Str.

In the constructor m_Str = m_Buf; seems fine.
After the constructor exists the address that m_Str points to suddenly
changes.

Sorry I missed that somehow. Anyway, like that it should work fine.

>

>>5 typedef struct
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 } Prof;
12

This only occurs if I create the VarBuf from within a struct (with or
without the typedef). If I create it directly in the method there is
no problem.

It's interesting that you say it didn't core for you. Initially this
was in a program which ran on RedHat3 for years without issue. When
we moved it to RH5 the core started occurring (although I have now
been able to replicate it on some RH3 machines).

RH3?? wow what compiler are you using?
I compiled your example on RH8, with gcc 4.1.3 and it works fine.

Try running your real program (or your example) with valgrind and see
what is the problem

[Pete Becker]

On 2008-08-28 05:36:48 -0400, anon <an**@no.nosaid:

>>
#include <stddef.h>
#include <string.h>
#include <stdlib.h>

These are c headers. Should be:

They're also C++ headers.

#include <cstddef>
#include <cstring>
#include <cstdlib>

>2 #include "stdio.h"
3 #include "time.h"

Do not use c headers in a c++ program

What problems do you think this will cause? Other than requiring the
addition of lots of std:: qualifiers, that is.

>

>>
4 typedef TVarBuf<6ProfKey; // Create a typedef for our template
class

This typedef looks very C-ish

Hmm, I didn't know that C had templates. <gSeriously, typedefs can
simplify code. What, specifically, do you object to here?

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

[Pete Becker]

On 2008-08-28 04:35:13 -0400, DaveJ <da*******@gmail.comsaid:

>
template<size_t Nclass TVarBuf
{
public:
TVarBuf (const char *initStr);
~TVarBuf ();
private:
char m_Buf[N + 1];
char* m_Str;
size_t m_Capacity;
size_t m_Length;
};

Just guessing, but the problem probably comes up because this template
doesn't have a copy constructor and assignment operator. When an object
of this type gets copied (by the default copy operations), the new
address of m_Buf is different from the old one, but m_Str still points
to the old one. So the destructor for the new one will see that they're
different, and try to delete m_Str.

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

[DaveJ]

On Aug 28, 12:25*pm, Pete Becker <[e-mail]:

On 2008-08-28 04:35:13 -0400, DaveJ <[e-mail]:

template<size_t Nclass TVarBuf
{
public:
* * * * * * TVarBuf *(const char *initStr);
* * * * * * ~TVarBuf ();
private:
* * char * *m_Buf[N + 1];
* * char* * m_Str;
* * size_t *m_Capacity;
* * size_t *m_Length;
};

Just guessing, but the problem probably comes up because this template
doesn't have a copy constructor and assignment operator. When an object
of this type gets copied (by the default copy operations), the new
address of m_Buf is different from the old one, but m_Str still points
to the old one. So the destructor for the new one will see that they're
different, and try to delete m_Str.

It's a good suggestion, I had left this out of the original post, but
the code does
already have a copy constructor
template<size_t N>
TVarBuf<N>::TVarBuf(const TVarBuf<N&that) :
m_Capacity(that.m_Capacity),
m_Length(that.m_Length)
{
printf("Im called\n");
m_Str = (that.m_Str == that.m_Buf) ? m_Buf
: (char *) malloc(m_Capacity +
1);

// Copy including the terminating NULL.
memcpy(m_Str, that.m_Str, m_Length + 1);
}

[anon]

Pete Becker wrote:

On 2008-08-28 05:36:48 -0400, anon <an**@no.nosaid:

>>>
#include <stddef.h>
#include <string.h>
#include <stdlib.h>

These are c headers. Should be:

They're also C++ headers.

>#include <cstddef>
#include <cstring>
#include <cstdlib>

>>2 #include "stdio.h"
3 #include "time.h"

Do not use c headers in a c++ program

What problems do you think this will cause? Other than requiring the
addition of lots of std:: qualifiers, that is.

Once you start including stdio.h, time.h, etc. you might start including
iostream.h

>>

>>>
4 typedef TVarBuf<6ProfKey; // Create a typedef for our template
class

This typedef looks very C-ish

Hmm, I didn't know that C had templates. <gSeriously, typedefs can
simplify code. What, specifically, do you object to here?

I suggested to change this:

5 typedef struct
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 } Prof;

into this:

5 struct Prof
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 };

not that is going to fix whatever problem he is experiencing

[Pete Becker]

On 2008-08-28 07:42:46 -0400, anon <an**@no.nosaid:

Pete Becker wrote:

>On 2008-08-28 05:36:48 -0400, anon <an**@no.nosaid:

>>>>
#include <stddef.h>
#include <string.h>
#include <stdlib.h>

These are c headers. Should be:

They're also C++ headers.

>>#include <cstddef>
#include <cstring>
#include <cstdlib>

>>>2 #include "stdio.h"
3 #include "time.h"

Do not use c headers in a c++ program

What problems do you think this will cause? Other than requiring the
addition of lots of std:: qualifiers, that is.

Once you start including stdio.h, time.h, etc. you might start
including iostream.h

But your objection was to using C headers, not to using non-standard headers.

>

>>>

4 typedef TVarBuf<6ProfKey; // Create a typedef for our template
class
This typedef looks very C-ish

Hmm, I didn't know that C had templates. <gSeriously, typedefs can
simplify code. What, specifically, do you object to here?

I suggested to change this:

5 typedef struct
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 } Prof;

into this:

5 struct Prof
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 };

not that is going to fix whatever problem he is experiencing

That still uses the typedef that you objected to. I agree that the
typedef that you changed in this code isn't appropriate in C++.

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

[Pete Becker]

On 2008-08-28 07:40:55 -0400, DaveJ <da*******@gmail.comsaid:

On Aug 28, 12:25Â*pm, Pete Becker <[e-mail]:

>On 2008-08-28 04:35:13 -0400, DaveJ <[e-mail]:

>>template<size_t Nclass TVarBuf
{
public:
Â* Â* Â* Â* Â* Â* TVarBuf Â*(const char *initStr);
Â* Â* Â* Â* Â* Â* ~TVarBuf ();
private:
Â* Â* char Â* Â*m_Buf[N + 1];
Â* Â* char* Â* m_Str;
Â* Â* size_t Â*m_Capacity;
Â* Â* size_t Â*m_Length;
};

Just guessing, but the problem probably comes up because this template
doesn't have a copy constructor and assignment operator. When an object
of this type gets copied (by the default copy operations), the new
address of m_Buf is different from the old one, but m_Str still points
to the old one. So the destructor for the new one will see that they're
different, and try to delete m_Str.

It's a good suggestion, I had left this out of the original post, but
the code does
already have a copy constructor

What else did you leave out that's critical to diagnosing the problem?
(Don't answer: that's rhetorical)

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

[Krice]

On 28 elo, 14:40, DaveJ <[e-mail]:

It's a good suggestion

I have a better one: Don't use malloc/free, use new and delete.

[anon]

Pete Becker wrote:

On 2008-08-28 07:42:46 -0400, anon <an**@no.nosaid:

>Pete Becker wrote:

>>On 2008-08-28 05:36:48 -0400, anon <an**@no.nosaid:

>
#include <stddef.h>
#include <string.h>
#include <stdlib.h>

These are c headers. Should be:

They're also C++ headers.

#include <cstddef>
#include <cstring>
#include <cstdlib>

2 #include "stdio.h"
3 #include "time.h"

Do not use c headers in a c++ program

What problems do you think this will cause? Other than requiring the
addition of lots of std:: qualifiers, that is.

Once you start including stdio.h, time.h, etc. you might start
including iostream.h

But your objection was to using C headers, not to using non-standard
headers.

C headers in c++ program

>>

>>>>
>
4 typedef TVarBuf<6ProfKey; // Create a typedef for our template
class
>

This typedef looks very C-ish

Hmm, I didn't know that C had templates. <gSeriously, typedefs can
simplify code. What, specifically, do you object to here?

I suggested to change this:

5 typedef struct
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 } Prof;

into this:

5 struct Prof
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 };

not that is going to fix whatever problem he is experiencing

That still uses the typedef that you objected to. I agree that the
typedef that you changed in this code isn't appropriate in C++.

I guess both issues are matter of personal preferences. You can program
like this if you like: http://www.ioccc.org/2004/anonymous.c and it will
still be a valid c++ program
I can not reproduce the core dump he is getting, therefore it can be the
compiler he is using.

[DaveJ]

On Aug 28, 12:52*pm, Pete Becker <[e-mail]:

On 2008-08-28 07:40:55 -0400, DaveJ <[e-mail]:

On Aug 28, 12:25*pm, Pete Becker <[e-mail]:

On 2008-08-28 04:35:13 -0400, DaveJ <[e-mail]:

>template<size_t Nclass TVarBuf
{
public:
* * * * * * TVarBuf *(const char *initStr);
* * * * * * ~TVarBuf ();
private:
* * char * *m_Buf[N + 1];
* * char* * m_Str;
* * size_t *m_Capacity;
* * size_t *m_Length;
};

Just guessing, but the problem probably comes up because this template
doesn't have a copy constructor and assignment operator. When an object
of this type gets copied (by the default copy operations), the new
address of m_Buf is different from the old one, but m_Str still points
to the old one. So the destructor for the new one will see that they're
different, and try to delete m_Str.

It's a good suggestion, I had left this out of the original post, but
the code does
already have a copy constructor

What else did you leave out that's critical to diagnosing the problem?
(Don't answer: that's rhetorical)

I thought it was best to leave out the copy constructor as it's not
actually called in this occurrence of the program.
Infact I stripped out everything that is not used, so that only the
critical bits of code can be examined.

[acehreli]

On Aug 28, 4:40*am, DaveJ <[e-mail]:

Just guessing, but the problem probably comes up because this template
doesn't have a copy constructor and assignment operator.

[...]

It's a good suggestion, I had left this out of the original post, but
the code does
already have a copy constructor

I assume that you took care of the assignment as well.

You may be seeing a g++ bug that was fixed at some version but then
resurfaced at a later version. We had a similar issue when we
initialized arrays of such self-referencing types. g++ would
incorrectly do a memberwise copy as if the type did not have a user-
specified copy constructor:

SelfRef a[] = { SelfRef("one"), SelfRef("two") };

The arrays would be initialized with incorrectly-copied copies of the
temporaries. As a result, the objects' members would not be pointing
to their own members.

Ali

[Pete Becker]

On 2008-08-28 08:47:33 -0400, anon <an**@no.nosaid:

Pete Becker wrote:

>On 2008-08-28 07:42:46 -0400, anon <an**@no.nosaid:

>>Pete Becker wrote:
On 2008-08-28 05:36:48 -0400, anon <an**@no.nosaid:

>>
>#include <stddef.h>
>#include <string.h>
>#include <stdlib.h>
>
These are c headers. Should be:

They're also C++ headers.

#include <cstddef>
#include <cstring>
#include <cstdlib>

>2 #include "stdio.h"
>3 #include "time.h"
>
Do not use c headers in a c++ program

What problems do you think this will cause? Other than requiring the
addition of lots of std:: qualifiers, that is.
Once you start including stdio.h, time.h, etc. you might start
including iostream.h

But your objection was to using C headers, not to using non-standard headers.

C headers in c++ program

Huh? Of course we were talking about C++ programs. The standard C
headers, slightly modified, are standard headers in C++, too.

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

[zaimoni]

On Aug 28, 3:35 am, DaveJ <[e-mail]:

Recently I was working on a project where I came across an issue where
the program cored and reported "free(): invalid pointer".
I found a resolution for this, but don't fully understand why the
issue occurred in the first place.

The project uses a simple template class that acts as a buffer.
Initially it has a fixed length, but it's append methods will extend
the size of the buffer if necessary.

...

Anyway I've included a cut down and simplified version of the code
below. I found the resolution was to modify the struct so that it
takes a reference to the template class.

------ VarBuf Class <VarBuf.h------
#ifndef __TVARBUF_H__
#define __TVARBUF_H__

#include <stddef.h>
#include <string.h>
#include <stdlib.h>

template<size_t Nclass TVarBuf
{
public:
TVarBuf (const char *initStr);
~TVarBuf ();
private:
char m_Buf[N + 1];
char* m_Str;
size_t m_Capacity;
size_t m_Length;};

#endif

template<size_t N>
TVarBuf<N>::TVarBuf(const char *initStr) :
m_Str(NULL),
m_Capacity(N),
m_Length(0)
{
m_Str = m_Buf;
m_Str[0] = '\0';

.....

}

template<size_t N>
TVarBuf<N>::~TVarBuf()
{
if(m_Str != m_Buf)
{
free(m_Str);
}

}

Destructor frees invalid pointer eventually if object was created by
memmove, default-copy, or default-assignment. Evidently you already
noticed this.

---------------------------------

---- Main App <main.cpp-----

1 #include "VarBuf.h"
2 #include "stdio.h"
3 #include "time.h"

4 typedef TVarBuf<6ProfKey; // Create a typedef for our template
class

5 typedef struct
6 {
7 time_t m_CurrTime;
8 int m_Docs;
9 int m_OldDocs;
10 ProfKey m_OldestProfUrl; // this is the template class
11 } Prof;

This should be an aggregate non-POD-struct, so there is no reason to
try to be both C and C++. It would be typical style both to rewrite
as a non-typedef'd struct as mentioned in an earlier post, and use the
C++-specific standard headers.

You'll miss some archaic C++ compiler bugs by sacrificing aggregate
initialization and rewriting (modulo style guidelines) as

class Prof
{
public:
time_t m_CurrTime;
int m_Docs;
int m_OldDocs;
ProfKey m_OldestProfUrl; // this is the template class

Prof(time_t _m_CurrTime, int _m_Docs, int _m_OldDocs, const char*
InitStr)
: m_CurrTime(_m_CurrTime),
m_Docs(_m_Docs),
m_OldDocs(_m_OldDocs),
m_OldestProfUrl(InitStr) {};
};

Default assignment/copy-construction/destruction should work if your
template class' overrides of these work.

....
------------------------------------------

Compiling the above code with the following command
g++ -g -Wall -omain main.cpp

Exact version?

and running the main binary results in:
free(): invalid pointer 0xbfffd66c!

I modified the code slightly so that line 10 of main reads:
-----------------------------------------------
ProfKey& m_OldestProfUrl; //take a reference to ProfKey
-----------------------------------------------
and line 17 now reads
------------------------------------------------
ProfKey key(NULL);
Prof profile = {now, 0, 0, key}
------------------------------------------------

Any explanation of whats going on here would be good.

I'd try ruling out bugs (aggregate initializer or getting confused by
non-POD-struct) first, especially since your target RH versions are
archaic. Rewrite Prof as a proper class (and use constructor rather
than aggregate initialization) to bypass these.

[anon]

Pete Becker wrote:

On 2008-08-28 08:47:33 -0400, anon <an**@no.nosaid:

>Pete Becker wrote:

>>On 2008-08-28 07:42:46 -0400, anon <an**@no.nosaid:

Pete Becker wrote:
On 2008-08-28 05:36:48 -0400, anon <an**@no.nosaid:
>
>>>
>>#include <stddef.h>
>>#include <string.h>
>>#include <stdlib.h>
>>
>These are c headers. Should be:
>
They're also C++ headers.
>
>#include <cstddef>
>#include <cstring>
>#include <cstdlib>
>
>>2 #include "stdio.h"
>>3 #include "time.h"
>>
>Do not use c headers in a c++ program
>
What problems do you think this will cause? Other than requiring
the addition of lots of std:: qualifiers, that is.
>

Once you start including stdio.h, time.h, etc. you might start
including iostream.h

But your objection was to using C headers, not to using non-standard
headers.

C headers in c++ program

Huh? Of course we were talking about C++ programs. The standard C
headers, slightly modified, are standard headers in C++, too.

That was my objection: do not use C headers in C++ programs.

[acehreli]

On Aug 28, 10:23*am, anon <[e-mail]:

That was my objection: do not use C headers in C++ programs.

You say that probably because you think e.g. <stdio.his not a C++
header. That is wrong. Please accept that e.g. <stdio.his a standard
C++ header.

Ali

[Pete Becker]

On 2008-08-28 13:23:22 -0400, anon <an**@no.nosaid:

Pete Becker wrote:

>On 2008-08-28 08:47:33 -0400, anon <an**@no.nosaid:

>>Pete Becker wrote:
On 2008-08-28 07:42:46 -0400, anon <an**@no.nosaid:

Pete Becker wrote:
>On 2008-08-28 05:36:48 -0400, anon <an**@no.nosaid:
>>
>>>>
>>>#include <stddef.h>
>>>#include <string.h>
>>>#include <stdlib.h>
>>>
>>These are c headers. Should be:
>>
>They're also C++ headers.
>>
>>#include <cstddef>
>>#include <cstring>
>>#include <cstdlib>
>>
>>>2 #include "stdio.h"
>>>3 #include "time.h"
>>>
>>Do not use c headers in a c++ program
>>
>What problems do you think this will cause? Other than requiring the
>addition of lots of std:: qualifiers, that is.
>>
>
Once you start including stdio.h, time.h, etc. you might start
including iostream.h

But your objection was to using C headers, not to using non-standard headers.
C headers in c++ program

Huh? Of course we were talking about C++ programs. The standard C
headers, slightly modified, are standard headers in C++, too.

That was my objection: do not use C headers in C++ programs.

Sigh. They're C++ headers, too. That's what the standard says. There's
no good reason not to use them.

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

[Default User]

anon wrote:

DaveJ wrote:

if(m_Str != m_Buf)

should be
if (m_Str != &m_Buf[0])

Why?


Brian

[courpron]

On 28 août, 20:14, Pete Becker <[e-mail]:

[...]

That was my objection: do not use C headers in C++ programs.

Sigh. They're C++ headers, too. That's what the standard says. There's
no good reason not to use them.

No.

<stdio.his a C header.
<cstdiois a C++ header.

The use of C headers in a C++ program is possible but deprecated.
It should only be used when the program needs to be compatible with C.

Alexandre Courpron.

[Pete Becker]

On 2008-08-28 14:46:15 -0400, co******@gmail.com said:

On 28 août, 20:14, Pete Becker <[e-mail]:

[...]

>>That was my objection: do not use C headers in C++ programs.

Sigh. They're C++ headers, too. That's what the standard says. There's
no good reason not to use them.

No.

<stdio.his a C header.
<cstdiois a C++ header.

No, <stdio.his a C header and a C++ header. Look at the standard.

>
The use of C headers in a C++ program is possible but deprecated.

Yes, there was a great deal of wishful thinking in the original
standard, including that. Although they're deprecated, they're not
going to go away. They work just fine.

It should only be used when the program needs to be compatible with C.

I see. You're applying the well-known design principle: never give a
logical reason when you can recite a slogan.

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

[courpron]

On 28 août, 20:58, Pete Becker <[e-mail]:

On 2008-08-28 14:46:15 -0400, [e-mail] said:

On 28 août, 20:14, Pete Becker <[e-mail]:

[...]

>That was my objection: do not use C headers in C++ programs.

Sigh. They're C++ headers, too. That's what the standard says. There's
no good reason not to use them.

No.

<stdio.his a C header.
<cstdiois a C++ header.

No, <stdio.his a C header and a C++ header. Look at the standard.

No, and I'll assume that this is just wrong unless you tell me where
the standard says this explicitly.

There are 3 kinds of headers that can be used in a C++ program :
- C++ headers
- C++ headers for C functionnalities
- C headers

and each of these categories are distinct.

The use of C headers in a C++ program is possible but deprecated.

Yes, there was a great deal of wishful thinking in the original
standard, including that. Although they're deprecated, they're not
going to go away. They work just fine.

This is not a long-term "future proof" statement.

It should only be used when the program needs to be compatible with C.

I see. You're applying the well-known design principle: never give a
logical reason when you can recite a slogan.

This is not a slogan, this is recommandation ( also made by the C++
standard (17.4.1.2 : footnote 160) ).

C headers should not be used by a C++ program because they are
deprecated. But, anyway, this is also bad practice, because using a C
header should denote (to every programmer reading the program) that
the program must be compatible with C.

Alexandre Courpron.

[Pete Becker]

On 2008-08-28 15:40:54 -0400, co******@gmail.com said:

On 28 août, 20:58, Pete Becker <[e-mail]:

>On 2008-08-28 14:46:15 -0400, [e-mail] said:

>>On 28 août, 20:14, Pete Becker <[e-mail]:

>>[...]

>>>>That was my objection: do not use C headers in C++ programs.

>>>Sigh. They're C++ headers, too. That's what the standard says. There's
no good reason not to use them.

>>No.

>><stdio.his a C header.
<cstdiois a C++ header.

No, <stdio.his a C header and a C++ header. Look at the standard.

No, and I'll assume that this is just wrong unless you tell me where
the standard says this explicitly.

Assume whatever you like.

>
There are 3 kinds of headers that can be used in a C++ program :
- C++ headers
- C++ headers for C functionnalities
- C headers

and each of these categories are distinct.

Ah, you're playing word games. Sorry I missed that earlier.

>

>>The use of C headers in a C++ program is possible but deprecated.

Yes, there was a great deal of wishful thinking in the original
standard, including that. Although they're deprecated, they're not
going to go away. They work just fine.

This is not a long-term "future proof" statement.

Nor is any other statement about programming, I suppose. Nevertheless,
the C headers are not going to be removed from the C++ standard.

>

>>It should only be used when the program needs to be compatible with C.

I see. You're applying the well-known design principle: never give a
logical reason when you can recite a slogan.

This is not a slogan, this is recommandation ( also made by the C++
standard (17.4.1.2 : footnote 160) ).

C headers should not be used by a C++ program because they are
deprecated.

As I said, thre's a great deal of wishful thinking in the original
standard. They're not going away.

But, anyway, this is also bad practice, because using a C
header should denote (to every programmer reading the program) that
the program must be compatible with C.

Nice circular argument.

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

[blargg]

In article
<12**********************************@26g2000hsk.g ooglegroups.com>,
co******@gmail.com wrote:

On 28 ao=FBt, 20:14, Pete Becker <[e-mail]:

[...]

That was my objection: do not use C headers in C++ programs.

Sigh. They're C++ headers, too. That's what the standard says. There's
no good reason not to use them.

No.

<stdio.his a C header.
<cstdiois a C++ header.

Everything an ISO C++ program has access to is in the ISO C++ standard;
nothing is automatically included unless the standard includes it,
therefore everything accessible is part of ISO C++. An ISO C++ program can
use <stdio.h>, therefore it's part of ISO C++.

Here's the relevant section from the standard. Note how it states that the
C++ standard library provides these headers, and that while deprecated,
they are part of the current standard, therefore part of the language:

Annex D
Compatibility features

1 This clause describes features of the C + + Standard that are
specified for compatibility with existing implementations.

2 These are deprecated features, where deprecated is defined as:
Normative for the current edition of the Standard, but not
guaranteed to be part of the Standard in future revisions.

[...]

D.5 Standard C library headers

1 For compatibility with the Standard C library, the C++ Standard
library provides the 18 C headers, as shown in Table 100:

Table 100‹C Headers

<assert.h<iso646.h<setjmp.h<stdio.h<wchar.h>
<ctype.h<limits.h<signal.h<stdlib.h<wctype.h>
<errno.h<locale.h<stdarg.h<string.h>
<float.h<math.h<stddef.h<time.h>

2 Every C header, each of which has a name of the form name.h,
behaves as if each name placed in the Standard library namespace by
the corresponding cname header is also placed within the namespace
scope of the namespace std and is followed by an explicit
using-declaration (7.3.3).

[courpron]

On 29 août, 01:31, Pete Becker <[e-mail]:

On 2008-08-28 15:40:54 -0400, [e-mail] said:

[...]

>>Sigh. They're C++ headers, too. That's what the standard says. There's
no good reason not to use them.

>No.

><stdio.his a C header.
<cstdiois a C++ header.

No, <stdio.his a C header and a C++ header. Look at the standard.

No, and I'll assume that this is just wrong unless you tell me where
the standard says this explicitly.

Assume whatever you like.

Where's the reference to the appropriate section of the C++ standard ?
If you don't provide one, I guess there is none.

Your statement "<stdio.his a C header and a C++ header." is just
wrong.
The funny thing is that you said "Look at the standard".

I guess you should apply to yourself your own advices.

:o)

There are 3 kinds of headers that can be used in a C++ program :
- C++ headers
- C++ headers for C functionnalities
- C headers

and each of these categories are distinct.

Ah, you're playing word games. Sorry I missed that earlier.

Don't be sorry for something that doesn't exist.

Those are the actual categories from the C++ standard.
- C++ header : <iostream>
- C++ header from C : <cstdio>
- C header : <stdio.h>

<stdio.his not a C++ header. No word game.

>The use of C headers in a C++ program is possible but deprecated.

Yes, there was a great deal of wishful thinking in the original
standard, including that. Although they're deprecated, they're not
going to go away. They work just fine.

This is not a long-term "future proof" statement.

Nor is any other statement about programming, I suppose. Nevertheless,
the C headers are not going to be removed from the C++ standard.

Allowing yourself the use of a deprecated feature because you "bet" it
will never ever be removed is not good practice and also not the
consensus, especially when there is another clean and easy solution.

[...]

*But, anyway, this is also bad practice, because using a C
header should denote (to every programmer reading the program) that
the program must be compatible with C.

Nice circular argument.

How does it qualify as a circular argument ?

If I am reviewing / maintening / correcting someone's "C++ program"
that includes C headers (e.g. #include <stdio.h), then I'll
immediatly recognize a C compatibility (and I may adjust my review or
correction taking into account that fact). However, putting C headers
in a C++ program with C++ constructs (or which does not require a C
compatibility) is bad practice. As I said earlier, even the C++
standard does not recommend it.
Alexandre Courpron.

[Pete Becker]

On 2008-08-28 20:58:26 -0400, co******@gmail.com said:

>
Allowing yourself the use of a deprecated feature because you "bet" it
will never ever be removed is not good practice and also not the
consensus, especially when there is another clean and easy solution.

Understanding how standardization works and understanding the realities
of the compiler market enables one to make intelligent judgments rather
than vague assertions, without citing supporting evidence, about "good
practice" and "concensus".

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

[anon]

Pete Becker wrote:

On 2008-08-28 20:58:26 -0400, co******@gmail.com said:

>>
Allowing yourself the use of a deprecated feature because you "bet" it
will never ever be removed is not good practice and also not the
consensus, especially when there is another clean and easy solution.

Understanding how standardization works and understanding the realities
of the compiler market enables one to make intelligent judgments rather
than vague assertions, without citing supporting evidence, about "good
practice" and "concensus".

This is a comment from the cstdio file (gcc 4.1.2) :

/** @file cstdio
* This is a Standard C++ Library file. You should @c #include this file
* in your programs, rather than any of the "*.h" implementation files.
*
* This is the C++ version of the Standard C Library header @c stdio.h,
* and its contents are (mostly) the same as that header, but are all
* contained in the namespace @c std (except for names which are defined
* as macros in C).
*/
This:
http://www.parashift.com/c++-faq-lit....html#faq-32.2
tells that you can use c headers, but my understanding of the first
statement under the first example is that people should prefer c++ headers

I am sure you know all this, but I can not understand why are you
defending the statement to use C headers in C++ programs, when there are
C++ headers available

[anon]

Default User wrote:

anon wrote:

>DaveJ wrote:

>> if(m_Str != m_Buf)

should be
if (m_Str != &m_Buf[0])

Why?

m_Buf is an array

[DaveJ]

This should be an aggregate non-POD-struct, so there is no reason to
try to be both C and C++. *It would be typical style both to rewrite
as a non-typedef'd struct as mentioned in an earlier post, and use the
C++-specific standard headers.

You'll miss some archaic C++ compiler bugs by sacrificing aggregate
initialization and rewriting (modulo style guidelines) as

class Prof
{
public:
* time_t * m_CurrTime;
* int * * *m_Docs;
* int * * *m_OldDocs;
* ProfKey *m_OldestProfUrl; *// this is the template class

* Prof(time_t _m_CurrTime, int _m_Docs, int _m_OldDocs, const char*
InitStr)
* * : *m_CurrTime(_m_CurrTime),
* * * *m_Docs(_m_Docs),
* * * *m_OldDocs(_m_OldDocs),
* * * *m_OldestProfUrl(InitStr) {};

};

Default assignment/copy-construction/destruction should work if your
template class' overrides of these work.

Thanks Zaim - your response was helpful and solved the problem (unlike
the trolls who hi-jacked the thread to talk about C vs C++ and
completely ignored the question ;-) )

[courpron]

On 29 août, 03:38, Pete Becker <[e-mail]:

On 2008-08-28 20:58:26 -0400, [e-mail] said:

Allowing yourself the use of a deprecated feature because you "bet" it
will never ever be removed is not good practice and also not the
consensus, especially when there is another clean and easy solution.

Understanding how standardization works and understanding the realities
of the compiler market enables one to make intelligent judgments rather
than vague assertions, without citing supporting evidence, about "good
practice" and "concensus".

That has nothing to do with "Understanding how standardization works
and the realities of compiler market ".
The fact that C headers won't be removed any time *soon* depends more
on the fact that a lot of current systems (especially low level
systems) and their interfaces are coded in C ; if that was not the
case, I guess that every standard library (with C++ or C headers)
would have been included in the std namespace without any exception.

Good practice is following the standard and avoid features listed as
deprecated (if possible). This is a general good practice that applies
to any programming language, and should be evident to any programmer.
That good practice directly comes from the definition of "deprecated".
Your opinion is interesting but is not following the *current*
standard (and is not listed as a core issue).

Alexandre Courpron.

[Pete Becker]

On 2008-08-29 03:34:43 -0400, "Alf P. Steinbach" <al***@start.nosaid:

>
Pete Becker is secretary of the international C++ standardization
committee's library group.

Actually, that' s Project Editor for the C++ standard.

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

[courpron]

On 29 août, 09:34, "Alf P. Steinbach" <[e-mail]:

* anon:

[...]

I am sure you know all this,

Pete Becker is secretary of the international C++ standardization committee's
library group.

That doesn't prevent him to make wrong statements like "<stdio.his a
C header and a C++ header."
We are not robots. Errare humanum est.

>

but I can not understand why are you
defending the statement to use C headers in C++ programs, when there are
*C++ headers available

He's not.

He's just countering your misguided views, and extremely patiently.

"anon" is not misguided in this particular aspect of the C++03
language. Now you can tell him your opinion about the future evolution
of C headers. That does not mean he is currently wrong.

>
That said, with C++0x there will IMO not be much reason to use the <xinstead
of <x.hheaders: about the only reason would be where you absolutely want to
use a "std::" prefix. That's because C++0x will acknowledge the current reality
that an <xheader may introduce the names in the global namespace. So it's then
better, in my view, if the code says straight out that this does or may very
well introduce names in the global namespace, and besides, it's the simplest.

In a header file, including a C++ header ( <iostreamfor example )
and using right away "using namespace std;" is bad practice. But, in
an implementation file, it's a correct usage under certain
circumstances. The same thing can be applied to C headers, but there
is one difference :

#include <stdio.hmay denote a C compatibility, whereas using :

#include <cstdio>
using namespace std;

tells to the reader that this is a C++ program only.
Moreover, when you are developping a C++ library, limiting or even
avoiding any name to be inserted in the global namesapce is a
reasonnable goal. If you use a lot of C headers in your own headers,
you pollute the global namespace with countless names, and you have to
resort to tricks like wrapping the C headers inclusion in a namespace
region. You don't have this problem with C++ headers like <cstdio>.

So, yes, there are good reasons to keep C++ headers à la <cstdio>, and
to avoid the use of C headers if possible.
Alexandre Courpron.

[Pete Becker]

On 2008-08-29 05:49:49 -0400, DaveJ <da*******@gmail.comsaid:

>
Thanks Zaim - your response was helpful and solved the problem (unlike
the trolls who hi-jacked the thread to talk about C vs C++ and
completely ignored the question ;-) )

Gosh, and here I thought I gave you an answer, based on the code that
you posted. The fact that you were sandbagging doesn't make my response
illegitimate.

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

[courpron]

On 29 août, 13:28, "Alf P. Steinbach" <[e-mail]:

* [e-mail]:
[...]

That has nothing to do with "Understanding how standardization works
and the realities of compiler market ".
The fact that C headers won't be removed any time *soon* depends more
on the fact that a lot of current systems (especially low level
systems) and their interfaces are coded in C ; if that was not the
case, I guess that every standard library (with C++ or C headers)
would have been included in the std namespace without any exception.

Good practice is following the standard and avoid features listed as
deprecated (if possible). This is a general good practice that applies
to any programming language, and should be evident to any programmer.
That good practice directly comes from the definition of "deprecated".
Your opinion is interesting but is not following the *current*
standard (and is not listed as a core issue).

Alexandre Courpron.

If you wonder about the rationales etc. of the standard (which you shoulddo)
then Pete's the man.

The rationale behind "listing C headers as a deprecated feature" is
obviosuly not the one displayed by Pete Becker.
He has an opinion about C headers (which is different than the opinion
of the writters of this part of the language), and he has the right to
have such opinion. That's all.

>
In general.

Is that so darned difficult to understand, that you're talking to guy who's
writing the standard?

Take a look at your copy of the C++0x draft, first page.

For Pete's sake. <g>

If someone is part of the standard C++ comittee or afiliated with it,
that doesn't mean he participated to the redaction of the *whole
current* C++ standard. That also does not mean that he knows every bit
of the C++ standard.
Alexandre Courpron.

[Pete Becker]

On 2008-08-29 08:11:10 -0400, co******@gmail.com said:

>
If someone is part of the standard C++ comittee or afiliated with it,
that doesn't mean he participated to the redaction of the *whole
current* C++ standard. That also does not mean that he knows every bit
of the C++ standard.

Gosh, and here I thought my responsibility as Project Editor was the
redaction of the whole C++ standard. And, with all due modesty, I know
it far better than you do.

More to the point, though, is that standards are not absolutes; they
require interpretation, and sometimes even recognition that reality
differs from theory. Both of those require real-world experience and
careful analysis, something you don't get from detailed parsing of the
words in the standard.

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

[courpron]

On 29 août, 14:40, Pete Becker <[e-mail]:

On 2008-08-29 08:11:10 -0400, [e-mail] said:

If someone is part of the standard C++ comittee or afiliated with it,
that doesn't mean he participated to the redaction of the *whole
current* C++ standard. That also does not mean that he knows every bit
of the C++ standard.

Gosh, and here I thought my responsibility as Project Editor was the
redaction of the whole C++ standard.

The redaction (what I mean was more "elaboration and redaction",
instead of pure writing) is a matter of a team. And I am pretty sure
that each person of the team doesn't know equally well the standard,
and certainly doesn't know every bit of it.

And, with all due modesty, I know
it far better than you do.

That's why you were wrong about the denomination of "C headers", and I
was right. :-)

Well, that's a bold statement and you may find that I have a very
*precise* knowledge of the current C++ specification concerning its
core, so, it is probable that you can't surpass me on that aspect. On
the other hand, concerning 1) the functionnalities of the C++
libraries and 2) the design and evolution of C++, my knowledge is
probably more limited than yours.

However, I have a very wide knowledge of programming languages and
compilers writing (although both of these are not my speciality).

You are specialized in C++, but you should take into account the
opinion of someone who can judge objectively what the current C++
standard is [ Of course compared to other programming languages
standards (or references if the language is not standardized), the C++
standard is objectively a mess :), but it is inherent to its complex
nature, and is reflected by the difficulty to write a C++ compiler. ]

I can say that it is not a good practice to use a deprecated feature.
If that feature will be undeprecated then wait for the next version of
C++ before using the (un)deprecated feature.

Last but not least, a programmer should refer to the standard without
caring about possible future evolutions of the language (for example,
this is the reponsibility of any programming language to introduce new
keywords that won't enter in conflict with existing programs, not the
other way around).
When you say to "anon" that there's no good reason not to use C
headers, this is not coherent with what the *current* C++ standard
says.

But I can understand your view while you talk about the intention and
future of C++.

This reminds me a rather recent discussion here on a specific aspect
of the C++ language where W. M. Miller said that "upon strict reading"
I was right but "it was not the intent". Here the message that
includes the whole discussion to see that you are not alone:
http://groups.google.fr/group/comp.l...a19dd3b12485ac
Sorry I can't help it, I read a lot of technical specifications. I
said earlier "we are not robots", but I act like one when I read
them.

I guess the two positions( strict reading, and intent of the wording)
are complementary. After all , which of the following compilers is
standard-compliant ? the one that strictly follows the wording of the
standard or the one that follows the "intents" ?

Alexandre Courpron.

[Pete Becker]

On 2008-08-29 11:44:11 -0400, Pete Becker <pe**@versatilecoding.comsaid:

On 2008-08-29 11:15:29 -0400, co******@gmail.com said:

>>
I can say that it is not a good practice to use a deprecated feature.

Indeed; you've demonstrated that by saying it several times. Being able
to say it doesn't make it true.

Ignore this. Sometimes I overindulge in wordplay.

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

[Pete Becker]

On 2008-08-29 11:15:29 -0400, co******@gmail.com said:

>
Sorry I can't help it, I read a lot of technical specifications. I
said earlier "we are not robots", but I act like one when I read
them.

I've never done that. <g>

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

[Default User]

anon wrote:

Default User wrote:

anon wrote:

DaveJ wrote:

> if(m_Str != m_Buf)
should be
if (m_Str != &m_Buf[0])

Why?

m_Buf is an array

So? What happens when the name of an array is used in most contexts,
outside of the sizeof or address-of (&) operators?


Brian

[courpron]

On 29 août, 17:44, Pete Becker <[e-mail]:

On 2008-08-29 11:15:29 -0400, [e-mail] said:

On 29 août, 14:40, Pete Becker <[e-mail]:

On 2008-08-29 08:11:10 -0400, [e-mail] said:

>If someone is part of the standard C++ comittee or afiliated with it,
that doesn't mean he participated to the redaction of the *whole
current* C++ standard. That also does not mean that he knows every bit
of the C++ standard.

Gosh, and here I thought my responsibility as Project Editor was the
redaction of the whole C++ standard.

The redaction (what I mean was more "elaboration and redaction",
instead of pure writing) is a matter of a team. And I am pretty sure
that each person of the team doesn't know equally well the standard,
and certainly doesn't know every bit of it.

Um, you talked about "he", not "they".

I used the "team working" argument to emphasize that noone can have a
perfect knowledge of C++, because there is inevitable disparities of
knowledge amongst individuals of a team ( which is inherent to the
human nature ).

And, with all due modesty, I know
it far better than you do.

That's why you were wrong about the denomination of "C headers", and I
was right. :-)

No, because you switched context. When I mentioned C++ headers, I was
referring to the headers prescribed by the C++ standard. You
misinterpreted that to refer to the title of a section in the C++
standard.

As I said I am precise, and when you say "<stdio.his a C header and
a C++ header.", this is wrong, according to the C++ standard.
You should have said something like "<stdio.his a standard header in
C++", because "C header" and "C++ header" have precise meaning in the
standard. However, I think I could have been more diplomatic instead
of just saying this was wrong, and should have clarified that only the
"form" of your wording was wrong, not the underlying meaning.

[...]

Last but not least, a programmer should refer to the standard without
caring about possible future evolutions of the language (for example,
this is the reponsibility of any programming language to introduce new
keywords that won't enter in conflict with existing programs, not the
other way around).

But "deprecated" is precisely about possible future evolutions of the
language. If programmers shouldn't care about possible future
evolutions, they should not care about deprecated.

Deprecation means that you should not use the deprecated feature.
Following this guideline (and then not using the deprecated feature),
the programmer does not have to worry about possible future evolutions
of the language.
Alexandre Courpron.

[Pete Becker]

On 2008-08-29 12:40:33 -0400, co******@gmail.com said:

On 29 août, 17:44, Pete Becker <[e-mail]:

>On 2008-08-29 11:15:29 -0400, [e-mail] said:

>>That's why you were wrong about the denomination of "C headers", and I
was right. :-)

No, because you switched context. When I mentioned C++ headers, I was
referring to the headers prescribed by the C++ standard. You
misinterpreted that to refer to the title of a section in the C++
standard.

As I said I am precise, and when you say "<stdio.his a C header and
a C++ header.", this is wrong, according to the C++ standard.

Programming advice entails far more than intricately parsing the C++ standard.

You should have said something like "<stdio.his a standard header in
C++", because "C header" and "C++ header" have precise meaning in the
standard.

I'm not aware of any rule that every term used in discussions in this
forum must be used in precisely the sense in which it is defined by the
C++ standard.

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

[Kai-Uwe Bux]

co******@gmail.com wrote:
[snip]

Deprecation means that you should not use the deprecated feature.

That is not the technical definition given in the standard.

Following this guideline (and then not using the deprecated feature),
the programmer does not have to worry about possible future evolutions
of the language.

That seems overly optimistic: features not deprecated now can become
deprecated in the future. All that deprecated means is that the feature is
not guaranteed to be part of the next version of the standard. Conversely,
non-deprecated features can be assumed to be normative in the next version,
but they might be deprecated in that version and missing in the version
thereafter. E.g. std::auto_ptr could be deprecated in C++0X since
unique_ptr is considered a superior alternative. So a programmer using the
not-currently-deprecated std::auto_ptr still has to worry about future
evolutions of the language.

I think, the currently deprecated C-library headers are probably more stable
than the currently not deprecated std::auto_ptr.
Best

Kai-Uwe Bux

[courpron]

On 29 août, 19:46, Pete Becker <[e-mail]:

On 2008-08-29 12:40:33 -0400, [e-mail] said:

On 29 août, 17:44, Pete Becker <[e-mail]:

On 2008-08-29 11:15:29 -0400, [e-mail] said:

>That's why you were wrong about the denomination of "C headers", and I
was right. :-)

No, because you switched context. When I mentioned C++ headers, I was
referring to the headers prescribed by the C++ standard. You
misinterpreted that to refer to the title of a section in the C++
standard.

As I said I am precise, and when you say "<stdio.his a C header and
a C++ header.", this is wrong, according to the C++ standard.

Programming advice entails far more than intricately parsing the C++ standard.

Indeed but a precise terminology is nonetheless necessary.

You should have said something like "<stdio.his a standard header in
C++", because "C header" and "C++ header" have precise meaning in the
standard.

I'm not aware of any rule that every term used in discussions in this
forum must be used in precisely the sense in which it is defined by the
C++ standard.

I agree with this, but the wording "C headers" is special in C++, so
clarifying the precise meaning is never a bad thing I guess.
Kinda like someone that is using "defined" instead of "declared", I
know the intent but I could bring some precision.

But you are right that no rule forces you to employ a precise
terminology. and this is fortunate because I, for example, am not as
precise as what I would like to be, because of my limited vocabulary
in english.
Alexandre Courpron.

[courpron]

On 29 août, 19:53, Pete Becker <[e-mail]:

On 2008-08-29 12:40:33 -0400, [e-mail] said:

On 29 août, 17:44, Pete Becker <[e-mail]:

On 2008-08-29 11:15:29 -0400, [e-mail] said:

>On 29 août, 14:40, Pete Becker <[e-mail]:

>Last but not least, a programmer should refer to the standard without
caring about possible future evolutions of the language (for example,
this is the reponsibility of any programming language to introduce new
keywords that won't enter in conflict with existing programs, not the
other way around).

But "deprecated" is precisely about possible future evolutions of the
language. If programmers shouldn't care about possible future
evolutions, they should not care about deprecated.

Deprecation means that you should not use the deprecated feature.

Its definition is in Annex D, paragraph 2: "Normative for the current
edition of the Standard, but not guaranteed to be part of the Standard
in future revisions." Nothing more, nothing less.

Deprecation is implicitely accompanied with a recommandation. That is
the intention.

A very clear and precise definition of "deprecation" :
http://en.wikipedia.org/wiki/Deprecation

You may say : "now he is talking about the intention of the standard"
Well, deprecation is a common term used in many programming languages,
and I'm pretty sure that the intention of listing a feature as
deprecated invariably means that you should not use this feature
unless you are forced to, in some exceptionnal circumstances.

The intention behind listing C headers as a deprecated feature was to
discourage their uses, unless a C compatibility was desired. Maybe the
terms of the problem have changed now, but this was the original
intent ( that or I'm mad ).

Following this guideline (and then not using the deprecated feature),
the programmer does not have to worry about possible future evolutions
of the language.

There's no guarantee that a future revision *of a standard won't
deprecate some feature. So this programmer who does not have to worry
about possible future evolutions of the language now has to worry about
future evolutions of the language.

This problem concerns the standardization commitee (which should care
about compatibility issues when deprecating some features). Those
future evolutions should not concern the developer who is currently
writing a program.

To minimize disruption, it's far
easier to wait until something is removed to stop using it.

I disagree with this. In any programming language, I would recommend
to avoid the use of deprecated features whenever possible. We have
conflicting views on the subject , but since those are just
"recommandations", noone is absolutely wrong or right ( naturally, I
think my position is wiser ).

Alexandre Courpron.

[courpron]

On 29 août, 20:58, Kai-Uwe Bux <[e-mail]:

[e-mail] wrote:

[snip]

Deprecation means that you should not use the deprecated feature.

That is not the technical definition given in the standard.

Following this guideline (and then not using the deprecated feature),
the programmer does not have to worry about possible future evolutions
of the language.

That seems overly optimistic: features not deprecated now can become
deprecated in the future. All that deprecated means is that the feature is
not guaranteed to be part of the next version of the standard. Conversely,
non-deprecated features can be assumed to be normative in the next version,
but they might be deprecated in that version and missing in the version
thereafter. E.g. std::auto_ptr could be deprecated in C++0X since
unique_ptr is considered a superior alternative. So a programmer using the
not-currently-deprecated std::auto_ptr still has to worry about future
evolutions of the language.

I think, the currently deprecated C-library headers are probably more stable
than the currently not deprecated std::auto_ptr.

I answer to all of this in my previous reply to Pete becker.

I would like to add that in the discussion about deprecation (and the
concern of a programmer about the future evolutions of his programming
language), Pete Becker and you are focusing too much on your C++
language experience.

When I say that a deprecated feature should be avoided, this is based
on an experience in a wide range of languages with different
programming paradigm, and in all of them "deprecation" has a constant
meaning.

Of course, you are not forced to follow my recommandation, I just
share my views with you.

Alexandre Courpron.

[Pete Becker]

On 2008-08-29 15:32:30 -0400, co******@gmail.com said:

On 29 août, 19:53, Pete Becker <[e-mail]:

>On 2008-08-29 12:40:33 -0400, [e-mail] said:

>>On 29 août, 17:44, Pete Becker <[e-mail]:
On 2008-08-29 11:15:29 -0400, [e-mail] said:

>>>>On 29 août, 14:40, Pete Becker <[e-mail]:

>>>>Last but not least, a programmer should refer to the standard without
caring about possible future evolutions of the language (for example,
this is the reponsibility of any programming language to introduce ne

w

>>>>keywords that won't enter in conflict with existing programs, not the
other way around).

>>>But "deprecated" is precisely about possible future evolutions of the
language. If programmers shouldn't care about possible future
evolutions, they should not care about deprecated.

>>Deprecation means that you should not use the deprecated feature.

Its definition is in Annex D, paragraph 2: "Normative for the current
edition of the Standard, but not guaranteed to be part of the Standard
in future revisions." Nothing more, nothing less.

Deprecation is implicitely accompanied with a recommandation. That is
the intention.

Okay. The words in the standard don't mean what they say when they
don't fit your world view.

>
A very clear and precise definition of "deprecation" :
http://en.wikipedia.org/wiki/Deprecation

Okay. Now we should look to wikipedia to be precise, even when the
standard explicitly defines what "deprecate" means, because the
definition in the standard doesn't fit your world view.

>
You may say : "now he is talking about the intention of the standard"
Well, deprecation is a common term used in many programming languages,
and I'm pretty sure that the intention of listing a feature as
deprecated invariably means that you should not use this feature
unless you are forced to, in some exceptionnal circumstances.

Of course. We should ignore the clear words in the standard because
they don't match what you want "deprecation" to mean.

>
The intention behind listing C headers as a deprecated feature was to
discourage their uses, unless a C compatibility was desired.

Okay, if you say so. I must have missed it, despite actually being part
of the discussion.

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

[Pete Becker]

On 2008-08-29 16:03:54 -0400, co******@gmail.com said:

>
When I say that a deprecated feature should be avoided, this is based
on an experience in a wide range of languages with different
programming paradigm, and in all of them "deprecation" has a constant
meaning.

Of course. Actual experience with C++ and the C++ standard and the C++
standards committee doesn't count against your general experience in
other languages.

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

[courpron]

On 29 août, 22:33, Pete Becker <[e-mail]:

On 2008-08-29 15:32:30 -0400, [e-mail] said:

[...]

>Deprecation means that you should not use the deprecated feature.

Its definition is in Annex D, paragraph 2: "Normative for the current
edition of the Standard, but not guaranteed to be part of the Standard
in future revisions." Nothing more, nothing less.

Deprecation is implicitely accompanied with a recommandation. That is
the intention.

Okay. The words in the standard don't mean what they say when they
don't fit your world view.

A very clear and precise definition of "deprecation" :
http://en.wikipedia.org/wiki/Deprecation

Okay. Now we should look to wikipedia to be precise, even when the
standard explicitly defines what "deprecate" means, because the
definition in the standard doesn't fit your world view.

No I say that the C++ definition of deprecation necessarily should
imply a recommandation of not using them. If it is not, then your view
and the C++ standard committe view of what is "deprecation" is not
matching the standard definition of "deprecation" in other programming
languages.

That's what I'm saying, and that's why I provided the wikipedia link.

>

You may say : "now he is talking about the intention of the standard"
Well, deprecation is a common term used in many programming languages,
and I'm pretty sure that the intention of listing a feature as
deprecated invariably means that you should not use this feature
unless you are forced to, in some exceptionnal circumstances.

Of course. We should ignore the clear words in the standard because
they don't match what you want "deprecation" to mean.

The intention behind listing C headers as a deprecated feature was to
discourage their uses, unless a C compatibility was desired.

Okay, if you say so. I must have missed it, despite actually being part
of the discussion.

You said yourself that it was a wishful thinking made 10 years ago.
That was the original intention behind listing C headers in deprecated
features, even if today, the way of thinking have changed apparently.
Alexandre Courpron.

[courpron]

On 29 août, 22:35, Pete Becker <[e-mail]:

On 2008-08-29 16:03:54 -0400, [e-mail] said:

When I say that a deprecated feature should be avoided, this is based
on an experience in a wide range of languages with different
programming paradigm, and in all of them "deprecation" has a constant
meaning.

Of course. Actual experience with C++ and the C++ standard and the C++
standards committee doesn't count against your general experience in
other languages.

Relying on his C++ language experience to judge general programming
practices and common term definition is IMHO a bad idea. Using any
functionnal language background seems to be a better choice in that
aspect.

Saying that you can freely use a deprecated feature until it has been
actually removed in the standard is a overall bad practice. The good
practice is to avoid deprecated features when possible.

Alexandre Courpron.

Alexandre Courpron.