Understanding char*

[Norm]

Could someone explain for me what is happening here?

char *string;
string = new char[5];
string = "This is the string";
cout << string << std::endl;

The output contains (This the string) even though I only allocated 5
characters in memory with new.

[Ron Natalie]

"Norm" <di******@myrealbox.com> wrote in message news:bj**********@terabinaries.xmission.com...

Could someone explain for me what is happening here?
char* is not a string type. It is a pointer to a single character.
At this point in your career you should stay clear ofit. Use the std::string type instead.
char *string;
string = new char[5];
Allocates an array of 5 char and puts the pointer to the first one in string.
string = "This is the string";

You are not writing over the array of 5 you allocated above. You are assigning
the pointer to the first character string literal (a statically allocated array of as many characters as
needed) .

You've essentially lost (leaked memory) the string you allocated in the previous line
by writing over the remembered address with this one.

And if you were to write:
strcpy(string, "This is the string");
which does copy the string literal over the characters pointed at by string, you'd
be in big trouble because it's undefined behavior when you access off the end of your
allocated memory.

If you wanted to write the first 5 chars of a string, this is how to do it:

#include <string>
std::string str("This is a string");
cout << str.substr(0,5) << "\n";

[Josh Lessard]

> Could someone explain for me what is happening here?

A memory leak.

char *string;
string = new char[5];
This dynamically allocates a chunk of memory big enough to hold 5 chars,
and returns a pointer to it (which gets stored in 'string').
string = "This is the string";
This places a pointer to the character string "This is the string" in your
variable 'string', which clobbers the old pointer value, rendering your
previously allocated memory inaccessible.
The output contains (This the string) even though I only allocated 5
characters in memory with new.

Yes, but you lost your pointer to that memory when you replaced it with a
pointer to "This is the string". Remember, 'string' doesn't hold the
allocated memory, it only holds a pointer to it.

************************************************** ***
Josh Lessard
Master's Student
School of Computer Science
Faculty of Mathematics
University of Waterloo
[phone] x3400
http://www.cs.uwaterloo.ca
************************************************** ***

[Gianni Mariani]

Norm wrote:

Could someone explain for me what is happening here?

char *string;
string = new char[5];
string = "This is the string";
cout << string << std::endl;

The output contains (This the string) even though I only allocated 5
characters in memory with new.

"char * s" is a "pointer to char". On a x86 this is a 32 bit number
which could theoretically address anything in memory.
new char[5] says - go find me an unused chunk of memory in my address
space big enout for 5 chars and "allocate it to me" and construct an
array of 5 chars - return the pointer to the first char.

now

s = new char[5]

takes the returned address and places it in s.

"This is the string" says to the compiler, create an const char array
and place the contents "This is the string" + a terminating ascii nul.
The value of "This is the string" is the address of the first unsigned
char in the array.

so

s = "This is the string";

REPLACES the address returned by new char[5] in the earlier statement.

Theoretically you have now leaked the memory from new char[5] because it
can no longer be deleted because you no longer have the address.

std::cout << s

applies "ostream & operator << ( ostream &, char * )" and passes the
address in s which happens to be "This is the string".

.....

Does this explain enough ?

[Norm]

"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...

"Norm" <di******@myrealbox.com> wrote in message news:bj**********@terabinaries.xmission.com...

Could someone explain for me what is happening here?

char* is not a string type. It is a pointer to a single character.
At this point in your career you should stay clear ofit. Use the

std::string type instead.

I know I should be using std::string instead I just trying to better
understand c-strings and pointer concepts

char *string;
string = new char[5];
Allocates an array of 5 char and puts the pointer to the first one in

string.

string = "This is the string";
You are not writing over the array of 5 you allocated above. You are

assigning the pointer to the first character string literal (a statically allocated array of as many characters as needed) .

You've essentially lost (leaked memory) the string you allocated in the previous line by writing over the remembered address with this one.

And if you were to write:
strcpy(string, "This is the string");
which does copy the string literal over the characters pointed at by string, you'd be in big trouble because it's undefined behavior when you access off the end of your allocated memory.
Just so I understand if I were to write this:

char *string;
string = new char[5];
strcpy(string, "This is the string");

It does copy to the the string to the allocated char's by new correct? But
in this example since the string does not fit I am getting an undefined
behavior? In my simple example what is being done with the extra char's that
don't fit? Is my compiler just seeing this and trying to fix the problem?
Because when I do (std::cout << string) the output is the entire string
literal.

Here is another question to clarify this concept for me. If I were to do
this:

char *string;
string = new char[50];
strcpy(string, "This is the string");
std::cout << string;
strcpy(string, "This is another string");
std::cout << string;

I am assuming the second strcpy is starting over from the begging and
overwriting everything from the first strcpy. Would it have been better to
delete and reallocate memory for the new string?

char *string;
string = new char[50];
strcpy(string, "This is the string");
std::cout << string;
delete string;
string = new char[50];
strcpy(string, "This is another string");
std::cout << string;

Thanks for the help everyone!

If you wanted to write the first 5 chars of a string, this is how to do it:
#include <string>
std::string str("This is a string");
cout << str.substr(0,5) << "\n";

[Ron Natalie]

"Norm" <di******@myrealbox.com> wrote in message news:bj**********@terabinaries.xmission.com...

It does copy to the the string to the allocated char's by new correct?
Yes, strcpy is logically:
char* strcpy(char* to, const char* from) {
char* ret = to;
while(*to++ = *from++);
return ret;
}

But
in this example since the string does not fit I am getting an undefined
behavior?
Yes, as soon as strcpy attempts to write the string[5] it is undefined
behavior.
In my simple example what is being done with the extra char's that
don't fit?
It attempts to write them in string[5], string[6]... but that's not a defined
operation since those locations have not been allocated.
Is my compiler just seeing this and trying to fix the problem?
Because when I do (std::cout << string) the output is the entire string
literal.
The compiler doesn't know or care. That's the problem with undefined
behavior. It may or may not work at run time. If it printed it, you just
got lucky and the extra characters you wrote didn't hit anything.

All the str* functions and anything that treats char* as if it were a string
just starts marching through memory from the given pointer looking
for the first null character.

Here is another question to clarify this concept for me. If I were to do
this:

char *string;
string = new char[50];
strcpy(string, "This is the string");
std::cout << string;
strcpy(string, "This is another string");
std::cout << string;

I am assuming the second strcpy is starting over from the begging and
overwriting everything from the first strcpy. Would it have been better to
delete and reallocate memory for the new string?
No.... As long as you don't run off the 50 characters.
You don't even need to new anything, C++ is not JAVA.
char string[50];
would have worked just fine and you never have to remember to
delete it.

If you had used std::string, you wouldn't have to worry about running off
the end, and assignment would work as you expect.
delete string;
BZZT. More undefined behavior. Anything you allocate with the array form of new
you need to deallocate with the array form of delete.

delete [] string;
string = new char[50];
strcpy(string, "This is another string");
std::cout << string;

Don't forget that you need to delete string here if you are done with it.

[Artie Gold]

Norm wrote:

"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...

"Norm" <di******@myrealbox.com> wrote in message
news:bj**********@terabinaries.xmission.com...

Could someone explain for me what is happening here?

char* is not a string type. It is a pointer to a single character.
At this point in your career you should stay clear ofit. Use the

std::string type instead.

I know I should be using std::string instead I just trying to better
understand c-strings and pointer concepts

char *string;
string = new char[5];

Allocates an array of 5 char and puts the pointer to the first one in

string.

string = "This is the string";

You are not writing over the array of 5 you allocated above. You are

assigning

the pointer to the first character string literal (a statically allocated

array of as many characters as

needed) .

You've essentially lost (leaked memory) the string you allocated in the

previous line

by writing over the remembered address with this one.

And if you were to write:
strcpy(string, "This is the string");
which does copy the string literal over the characters pointed at by

string, you'd

be in big trouble because it's undefined behavior when you access off the

end of your

allocated memory.

Just so I understand if I were to write this:

char *string;
string = new char[5];
strcpy(string, "This is the string");

It does copy to the the string to the allocated char's by new correct? But
in this example since the string does not fit I am getting an undefined
behavior? In my simple example what is being done with the extra char's that
don't fit? Is my compiler just seeing this and trying to fix the problem?
Because when I do (std::cout << string) the output is the entire string
literal.

Right. You're getting undefined behavior. In this case, you just
happened to get unlucky, and it *seemed* to work correctly.[1]

Here is another question to clarify this concept for me. If I were to do
this:

char *string;
string = new char[50];
strcpy(string, "This is the string");
std::cout << string;
strcpy(string, "This is another string");
std::cout << string;

I am assuming the second strcpy is starting over from the begging and
overwriting everything from the first strcpy. Would it have been better to
delete and reallocate memory for the new string?
Not at all. You allocated space for 50 `char's. It's yours. You may
do what you want with it (but be sure to delete it when you no
longer need it).

char *string;
string = new char[50];
strcpy(string, "This is the string");
std::cout << string;
delete string;
string = new char[50];
strcpy(string, "This is another string");
std::cout << string;

Not necessary.

If you wanted to write the first 5 chars of a string, this is how to do

it:

#include <string>
std::string str("This is a string");
cout << str.substr(0,5) << "\n";

HTH,
--ag

[1] The reason *seeming* to work is an unlucky occurence is that,
particularly with buffer overrun kinds of problems, you're likely to
have overwritten a piece of memory that will result in a crash in
some other part of your program. Situations like that tend to be
devilishly difficult to track down.
--
Artie Gold -- Austin, Texas

[Ying Yang]

Could someone explain for me what is happening here?

char *string;
You have declared a pointer named string to a char type. This pointer is
allocated on the stack.
string = new char[5];
You have made this pointer point to the first element in a constant array of
type char that has 5 elements. This constant array is allocated on the heap
(using the new operator). Note, there is a close association between
pointers and arrays.
string = "This is the string";
cout << string << std::endl;
The output contains (This the string) even though I only allocated 5
characters in memory with new.

The elements in the constant array is filled with the characters in the
string literal. Two important things to notice here is that (1) the null
character is automatically appended at the end of the array (2) it is
possible to over-write next memory locations as C++ does not do run-time
checks for array indexes that go out of bounds.

Hope this helps.

weeeeeeeeeeee

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 14/08/2003

[Steven C.]

This is a very good explaination.
"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:bj********@dispatch.concentric.net...
Norm wrote:

Could someone explain for me what is happening here?

char *string;
string = new char[5];
string = "This is the string";
cout << string << std::endl;

The output contains (This the string) even though I only allocated 5
characters in memory with new.

"char * s" is a "pointer to char". On a x86 this is a 32 bit number
which could theoretically address anything in memory.
new char[5] says - go find me an unused chunk of memory in my address
space big enout for 5 chars and "allocate it to me" and construct an
array of 5 chars - return the pointer to the first char.

now

s = new char[5]

takes the returned address and places it in s.

"This is the string" says to the compiler, create an const char array
and place the contents "This is the string" + a terminating ascii nul.
The value of "This is the string" is the address of the first unsigned
char in the array.

so

s = "This is the string";

REPLACES the address returned by new char[5] in the earlier statement.

Theoretically you have now leaked the memory from new char[5] because it
can no longer be deleted because you no longer have the address.

std::cout << s

applies "ostream & operator << ( ostream &, char * )" and passes the
address in s which happens to be "This is the string".

.....

Does this explain enough ?

[Big Brian]

> > Could someone explain for me what is happening here?

char* is not a string type. It is a pointer to a single character.
At this point in your career you should stay clear ofit. Use the std::string type instead.

Everybody needs to understand c style strings as well. I've worked on
projects where you couldn't use std::string. And you never know when
you're going to have to maintain old code which uses them.

[Jakob Bieling]

"Ying Yang" <Yi******@hotmail.com> wrote in message
news:3f**********@news.iprimus.com.au...

string = new char[5];
You have made this pointer point to the first element in a constant array

of type char that has 5 elements. This constant array is allocated on the heap (using the new operator). Note, there is a close association between
pointers and arrays.
Why are you saying 'constant array'? The array of chars that is
allocated by the statement above is not constant at all.

string = "This is the string";
cout << string << std::endl;
The output contains (This the string) even though I only allocated 5
characters in memory with new.

The elements in the constant array is filled with the characters in the
string literal.

No, not at all. The elements of the array you allocated with 'new[]' are
untouched and the pointer to the first element of that array is lost. See
Gianni's post for an in-depth explanation.
Two important things to notice here is that (1) the null
character is automatically appended at the end of the array

Using the above statement, no. This applies when using any of the str*
functions, like strcpy, strcat and whatnot.

regards
--
jb

(replace y with x if you want to reply by e-mail)

[John Carson]

"Norm" <di******@myrealbox.com> wrote in message
news:bj**********@terabinaries.xmission.com

Just so I understand if I were to write this:

char *string;
string = new char[5];
strcpy(string, "This is the string");

It does copy to the the string to the allocated char's by new
correct? But in this example since the string does not fit I am
getting an undefined behavior? In my simple example what is being
done with the extra char's that don't fit? Is my compiler just seeing
this and trying to fix the problem? Because when I do (std::cout <<
string) the output is the entire string literal.
The point is that there are two memory allocation mechanisms available and
you are assuming that there is only one, name that provided by new.

You could write:

char *string;
string = "This is the string";
cout << string << std::endl;

without any use of new and it would be fine. The compiler will put "This is
the string" in statically allocated memory, i.e., memory reserved when the
program first starts up. It then makes the string variable point to the
start of this statically allocated memory. Statically allocated memory is
the same as what you get if, say, you write

int x;

at global scope.
Here is another question to clarify this concept for me. If I were to
do this:

char *string;
string = new char[50];
strcpy(string, "This is the string");
std::cout << string;
strcpy(string, "This is another string");
std::cout << string;

I am assuming the second strcpy is starting over from the begging and
overwriting everything from the first strcpy. Would it have been
better to delete and reallocate memory for the new string?

No, that just makes extra work for no gain.

--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[Jakob Bieling]

"John Carson" <do***********@datafast.net.au> wrote in message
news:3f********@news.brisbane.pipenetworks.com...

"Norm" <di******@myrealbox.com> wrote in message
news:bj**********@terabinaries.xmission.com

Just so I understand if I were to write this:

char *string;
string = new char[5];
strcpy(string, "This is the string");

It does copy to the the string to the allocated char's by new
correct? But in this example since the string does not fit I am
getting an undefined behavior? In my simple example what is being
done with the extra char's that don't fit? Is my compiler just seeing
this and trying to fix the problem? Because when I do (std::cout <<
string) the output is the entire string literal.
The point is that there are two memory allocation mechanisms available and
you are assuming that there is only one, name that provided by new.

You could write:

char *string;
string = "This is the string";
cout << string << std::endl;

without any use of new and it would be fine. The compiler will put "This

is the string" in statically allocated memory, i.e., memory reserved when the
program first starts up. It then makes the string variable point to the
start of this statically allocated memory.

You should note that memory allocated like this is constant, meaning
that you may not change it. I do not remember why the following compiles:

char* tyt = "hello world";
tyt [0] = 'H';

but when running it, it will give you an access violation. IMO, the
string literal should be of type 'char const*', but for some reason it seems
not to be.

regards
--
jb

(replace y with x if you want to reply by e-mail)

[Kevin Goodsell]

Jakob Bieling wrote:

You should note that memory allocated like this is constant, meaning
that you may not change it. I do not remember why the following compiles:

char* tyt = "hello world";
tyt [0] = 'H';
Basically it's for historical reasons. C allowed literals to be modified
way back in the day. Implicit conversion of a string literal to a
(non-const) char * is deprecated in C++. You should always use const
char * for this purpose.

but when running it, it will give you an access violation. IMO, the
string literal should be of type 'char const*', but for some reason it seems
not to be.

Actually, the type of a string literal is const char[N] where N is the
number of characters including the null terminator. So it *is* const,
but it's a special case with that implicit conversion.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Gianni Mariani]

Jakob Bieling wrote:

"John Carson" <do***********@datafast.net.au> wrote in message
news:3f********@news.brisbane.pipenetworks.com...

You should note that memory allocated like this is constant, meaning
that you may not change it. I do not remember why the following compiles:

char* tyt = "hello world";
tyt [0] = 'H';

but when running it, it will give you an access violation. IMO, the
string literal should be of type 'char const*', but for some reason it seems
not to be.

It may or may not fault - it's undefined.

The reason why tyt does not need to be a "const char *" is there is a
special C++ rule for conversion of a string literal to a "char *" to
deal with all the bad code out there.

[Kevin Goodsell]

Big Brian wrote:

Could someone explain for me what is happening here?
char* is not a string type. It is a pointer to a single character.
At this point in your career you should stay clear ofit. Use the std::string type instead.

Everybody needs to understand c style strings as well.

Yes, but they should avoid them. Beginners and experts alike should
prefer std::string.
I've worked on
projects where you couldn't use std::string.
So, projects where you weren't allowed to use C++? (At least not all of
it.) I wonder why that restriction would be placed on a project written
in C++.
And you never know when
you're going to have to maintain old code which uses them.

Yeah. When maintaining that kind of code, I recommend converting it to
use std::string.

The advantages of std::string over C-style strings are clear. Of course
a good programmer should now how to use messy things like C-style
strings, but he should also know better than to use them (at least most
of the time).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[A]

string = new char[5];
You have made this pointer point to the first element in a constant array of

type char that has 5 elements. This constant array is allocated on the heap

(using the new operator). Note, there is a close association between
pointers and arrays.

Why are you saying 'constant array'? The array of chars that is
allocated by the statement above is not constant at all.

Array identifiers are constant so you cannot assign a value to array
identifiers - you can only assign values to the elements in the array.

string = "This is the string";
cout << string << std::endl;
The output contains (This the string) even though I only allocated 5
characters in memory with new.

The elements in the constant array is filled with the characters in the
string literal.

No, not at all. The elements of the array you allocated with 'new[]'

are untouched and the pointer to the first element of that array is lost. See
Gianni's post for an in-depth explanation.

Incorrect.

Two important things to notice here is that (1) the null
character is automatically appended at the end of the array

Using the above statement, no. This applies when using any of the str*
functions, like strcpy, strcat and whatnot.

Incorrect.

char myString[] = "Hello World";

The null character is automatically included here.

[Kevin Goodsell]

A wrote:

Why are you saying 'constant array'? The array of chars that is
allocated by the statement above is not constant at all.

Array identifiers are constant so you cannot assign a value to array
identifiers - you can only assign values to the elements in the array.

But there were no arrays in the example, other than the dynamically
allocated one (which doesn't have an identifier). Neither the pointer
nor the thing pointed to were const in the example.

No, not at all. The elements of the array you allocated with 'new[]' are
untouched and the pointer to the first element of that array is lost. See
Gianni's post for an in-depth explanation.

Incorrect.

He was precisely correct. You seem to have a lot to learn about C++.
There is absolutely no copying of array elements happening here. All
that happens is a pointer being modified to point to a different
address, thus losing the address of the dynamic array - in other words,
leaking the memory.

Two important things to notice here is that (1) the null
character is automatically appended at the end of the array
Using the above statement, no. This applies when using any of the str*
functions, like strcpy, strcat and whatnot.

Incorrect.

He's right. You are not.

char myString[] = "Hello World";

The null character is automatically included here.

Yes, but this example has nothing to do with your (blatantly incorrect)
statements, and it does nothing to disprove Jakob's (correct) statements.

(As a side note, here we have another example of the difference between
assignment and initialization. The above initialization automatically
copies the elements of the string literal into the myString array. This
cannot be duplicated with an assignment.)

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Jack Klein]

On Sat, 13 Sep 2003 18:34:16 GMT, Kevin Goodsell
<us*********************@neverbox.com> wrote in comp.lang.c++:

Big Brian wrote:

Could someone explain for me what is happening here?

char* is not a string type. It is a pointer to a single character.
At this point in your career you should stay clear ofit. Use the std::string type instead.

Everybody needs to understand c style strings as well.

Yes, but they should avoid them. Beginners and experts alike should
prefer std::string.

I've worked on
projects where you couldn't use std::string.

So, projects where you weren't allowed to use C++? (At least not all of
it.) I wonder why that restriction would be placed on a project written
in C++.

There are many existing applications that were written in a dialect of
C++ before there was a std::string or an ISO/IEC standard for C++. If
these are viable, they often need to be maintained and extended,
sometimes for very many years.

Not every project includes the luxury of starting with a clean sheet
of paper.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Kevin Goodsell]

Jack Klein wrote:

There are many existing applications that were written in a dialect of
C++ before there was a std::string or an ISO/IEC standard for C++. If
these are viable, they often need to be maintained and extended,
sometimes for very many years.

Not every project includes the luxury of starting with a clean sheet
of paper.

Yeah, I know. But I think it's unfortunate when projects that *could*
use modern C++ don't, and do things the hard way instead. I question the
validity of the reasons for this. Is there really a good reason to
forbid, e.g., templates in a C++ program in this day and age?

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Duane Hebert]

> Yeah, I know. But I think it's unfortunate when projects that *could*

use modern C++ don't, and do things the hard way instead. I question the
validity of the reasons for this. Is there really a good reason to
forbid, e.g., templates in a C++ program in this day and age?

Theoretically no but if the compiler that you're stuck with using has broken
support for templates...

[Kevin Goodsell]

Duane Hebert wrote:

Yeah, I know. But I think it's unfortunate when projects that *could*
use modern C++ don't, and do things the hard way instead. I question the
validity of the reasons for this. Is there really a good reason to
forbid, e.g., templates in a C++ program in this day and age?

Theoretically no but if the compiler that you're stuck with using has broken
support for templates...

Well, it's not necessarily one compiler. If you are targeting multiple
systems, you may be stuck with the "lowest common denominator",
unfortunately. I understand this, but what I don't quite understand is
what standard some people are apparently using to determine what the
lowest common denominator is.

Take the Mozilla project, for example. I love Mozilla. I use Firebird
for all my browsing and Thunderbird for mail and news. But I think their
coding standards are a joke. Here's a few links:

http://www.mozilla.org/hacking/mozilla-style-guide.html
http://www.mozilla.org/hacking/portable-cpp.html

And here's a few examples of the rules:

* Don't use NULL for pointers. On some systems it's declared as void *
and causes a compile warning when assigned to a pointer.

* Don't use templates.

* Don't use exceptions.

* Don't use namespaces.

* Don't put constructors in header files. (Because VC++ 1.5 can't handle it)

This seems crazy to me. Portable is one thing, but portable to ancient
compilers is another. They want it to be able to build for pretty much
any system - that's great, but is it necessary to restrict the language
that much? Considering the compilers that are available today, you'd
think they could allow the use of most language features with no
problems at all. gcc and Comeau come to mind - how many platforms do
they cover? If they could *only* build on those two compilers, I think
they'd still have pretty much the platform coverage they have now. And
if they were using the language rather than working around it, they'd
probably have fewer bugs.

I think we should demand compilers that support the actual language,
rather than restricting our use of the language to those features
vendors feel like supporting.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Greg Comeau]

In article <61*****************@newsread4.news.pas.earthlink. net>,
Kevin Goodsell <us*********************@neverbox.com> wrote:

...Take .. Mozilla ... I think their
coding standards are a joke. Here's a few links:

http://www.mozilla.org/hacking/mozilla-style-guide.html
http://www.mozilla.org/hacking/portable-cpp.html

And here's a few examples of the rules:

* Don't use NULL for pointers. On some systems it's declared as void *
and causes a compile warning when assigned to a pointer.

* Don't use templates.

* Don't use exceptions.

* Don't use namespaces.

* Don't put constructors in header files. (Because VC++ 1.5 can't handle it)

This seems crazy to me. Portable is one thing, but portable to ancient
compilers is another. They want it to be able to build for pretty much
any system - that's great, but is it necessary to restrict the language
that much? Considering the compilers that are available today, you'd
think they could allow the use of most language features with no
problems at all. gcc and Comeau come to mind - how many platforms do
they cover? If they could *only* build on those two compilers, I think
they'd still have pretty much the platform coverage they have now. And
if they were using the language rather than working around it, they'd
probably have fewer bugs.

I think we should demand compilers that support the actual language,
rather than restricting our use of the language to those features
vendors feel like supporting.

It definitely *is* the case that many projects need to constrain
themselves as per the guidelines above. However, I don't think
that's the problem, that is, I think the problem is projects which
don't need such constrains to be tied down by them, coding standards
which take on lies of their own, coding standard which remain
stagnant, inapplying situations, etc. So sure, for many project,
it can make no sense at all, and doing something as you say just
might be the ticket.
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[Default User]

Greg Comeau wrote:

coding standards which take on lies of their own

Damn those lying code standards! Or was that a bit of a Freudian?


Brian Rodenborn

[Greg Comeau]

In article <3F***************@company.com>,
Default User <fi********@company.com> wrote:

Greg Comeau wrote:

coding standards which take on lies of their own

Damn those lying code standards! Or was that a bit of a Freudian?

heh. Has got to be :)
--
Greg Comeau/4.3.3:Full C++03 core language + more Windows backends
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?