Embedded Strings -- Arrays or pointers?

[Sharad Kala]

| Alf P. Steinbach wrote:
| > * (e-mail address removed):
| > > I prove to you using code and arrays with diffrent size elements that

[snip]

| I am beginning to think I'am off topic due to ignorance on

You are not offtopic, but incorrect in your understanding.

| what is concidered c and what is considered c++.
| What separates them form each other? Is there such a thing as pure c++?

That makes little sense to me. C and C++ are two different programming
languages. C++ has tried to maintain compatibility with C, but not every
valid C program is a valid C++ program.

| I was thinking about the sum of the both and what can be done and not.
| You seem to know:
| how do
| int i[]={1,2,3,4};
| void main()

This exhibits undefined behavior. Main has _never ever_ in the history of
C++ returned void.

| {
| i[2]=6;

*(i + 2) = 6

Pointer aritmetic gets you to the right offset (i.e. i + 2*sizeof int).

| }
| compile and on what level is stuff happenning?

Sharad

 

[jesper]

(e-mail address removed) wrote:

[]

As far as I know there is no diffrence between them.
I might be ignorant as hell. Is exactly the same.
char astr[]="array hello";
char* pstr="pointer hello";

They are different.

Using char[] for string literals provides more information at compile
time. Consider the effects of:

unsigned a = sizeof(astr), b = sizeof(pstr);

Now a is the size of the literal including zero terminator, while b is
merely the size of the pointer.

From a dynamic linker perspective, char[] may be better than char* for

string literals. More information on that
http://people.redhat.com/drepper/dsohowto.pdf

Ok. This I can understand.
I did not consider array size being availble at compiletime.
I must confess I seldom use static arrays in any case. And have
probably come to
consider the pointer to be the same as the array.
Thank you.
/Jesper

 

[Daniel T.]

When you have compile-time strings like:

"The file is of unknown format."

What kind of variables do you use to store it? At the moment I'm using:

char const str[] = "The file is of unknown format.";

Do some of you use:

const char* const str = "The file is of unknown format.";

In *real* programs, I use whatever OS tools are available to store the
string outside the program and import it. In other words, there is a
file somewhere with a list of all my string literals, and I import them
into the program, the string literals are not imbedded in the code
itself.

 

[jesper]

This exhibits undefined behavior. Main has _never ever_ in the history of
C++ returned void.

*Blush* Well well... I think I'll just shut up

 

[Maxim Yegorushkin]

Daniel T. wrote:

[]

In *real* programs, I use whatever OS tools are available to store the
string outside the program and import it. In other words, there is a
file somewhere with a list of all my string literals, and I import them
into the program, the string literals are not imbedded in the code
itself.

This is typical for gui applications with the rationale being i18n. Not
typical for servers.

 

[Michiel.Salters]

As far as I know there is no diffrence between them.
I might be ignorant as hell. Is exactly the same.
char astr[]="array hello";
char* pstr="pointer hello";

At this moment, yes, you are ignorant as hell.
pstr resides in read-only memory and trying to modify it
is UB, whereas modifying astr is ok.

HTH,
- J.

This is just plain wrong, any compiler can tell you so.
There is no such thing as read-only memory.

Strange. I have an EPROM which definitely thinks it's read-only as
long as you don't irradiate it. And there are many compilers who are
happy to agree with that observation. Certainly you don't expect that
the compiler arranges for an UV source if you write pstr[0]=0; ?

HTH,
Michiel Salters

 

[Michiel.Salters]

In *real* programs, I use whatever OS tools are available to store the
string outside the program and import it. In other words, there is a
file somewhere with a list of all my string literals, and I import them
into the program, the string literals are not imbedded in the code
itself.

You know there are tools (like GNU's xgettext) which can find string
literals
even if they're embedded in the code itself? Keeping a separate file is
a
maintenance nightmare. Automatically creating it as part of your
automated
build is robust and easy.

HTH,
Michiel Salters

 

[Default User]

I prove to you using code and arrays with diffrent size elements
that what compiler does is:
pstr[1] = 'a'; compiles to *(pstr+(1*sizeof(*pstr))) = 'a';

That's irrelevant as far as the language is concerned. Given any
array, a is evaluated as *(a + b). Compilers are smart enough to
access the right memory location using pointer arithmetic.

Yes, that's why the seemingly odd construct:

char* arr[10];

0[arr] = 'a';

Is perfectly legal and meaningful.



Brian

 

[Maxim Yegorushkin]

Default User wrote:

[]

Yes, that's why the seemingly odd construct:

char* arr[10];
0[arr] = 'a';

Is perfectly legal and meaningful.

It is not. Had you declared arr as char arr[10], rather than char* ...,
it would have been.

 

[jesper]

Strange. I have an EPROM which definitely thinks it's read-only as
long as you don't irradiate it. And there are many compilers who are
happy to agree with that observation. Certainly you don't expect that
the compiler arranges for an UV source if you write pstr[0]=0; ?

I was being stupid. I am beginning to get a clue as to what kind of
subjects we are dealing with in this group. I was only thinking about
PC:s but I know understand what is being ment by this relating to the
language only, and why the term "undefined behaviour" is being thrown
about to the extent it is. I appologize for my somewhat agressive
statements. I need to find a PC-programming forum instead.

 

[peter koch]

Hi Jesper

This has nothing to do with your platform. On a modern pc, the
operating system will protect the memory so that you e.g. can't
overwrite the operating system or the executable code. There is nothing
to prevent the compiler to putting fixed strings in to memory in which
your program is not allowed to write. In such a case, the modification
of a constant is assured to give you "unexpected" behaviour such a
signal being sent.

/Peter

 

[Default User]

Default User wrote:

[]

Yes, that's why the seemingly odd construct:

char* arr[10];
0[arr] = 'a';

Is perfectly legal and meaningful.

It is not. Had you declared arr as char arr[10], rather than char*
..., it would have been.

That was a typo, of course. Thanks for pointing it out, correctness is
always to be preferred.



Brian