code in C( is it correct)

[Pallav singh]

Hi all ,

struct S
{
int a;
char c;
char * ptr;
};


struct T
{
int a;
char c;
};


int main()
{
struct S s1={1,'a',"India"};
struct S s2={2,'b',"Country"};

struct T t1={1,'a'};
struct T t2={2,'b'};

if( s1= s2) // Is it Correct? if yes/ no why
printf(" data copied successfully for struct S \n ");

if( t1= t2) // Is it Correct? if yes/ no why
printf(" data copied successfully for struct T \n");

return 0;

}

 

[Victor Bazarov]

Hi all ,

struct S
{

For questions on C please go to 'comp.lang.c' newsgroup.

V

 

[Juha Nieminen]

For questions on C please go to 'comp.lang.c' newsgroup.

Exactly what in his code does not work identically in C++, and
consequently can be answered from the C++ perspective?

 

[Victor Bazarov]

Exactly what in his code does not work identically in C++, and
consequently can be answered from the C++ perspective?

I don't know. I didn't bother looking. What would be the point of
answering the question he didn't ask?

V

 

[Default User]

For questions on C please go to 'comp.lang.c' newsgroup.

It seems that he also posted this to comp.std.c. Someone there
redirected it to CLC and it's been answered there.




Brian

 

[Juha Nieminen]

I don't know. I didn't bother looking.

Why not?

If he had omitted the "in C" part in the subject, but otherwise the
post would have been completely identical, you would probably have
answered him (or at least you wouldn't have objected to his post).
However, because the string "in C" appeared in the subject, you refused
to even read the post? Exactly what is the logic you are following here?
Is it some kind of odd principle that if a poster confesses that he is
going to ask a question which is relevant to both C and C++, you refuse
to even read the question?

Neither the question nor the answer would have been different or
affected in any way, regardless of whether he had written that "in C" in
the subject of his post.

 

[Ian Collins]

Why not?

If he had omitted the "in C" part in the subject, but otherwise the
post would have been completely identical, you would probably have
answered him (or at least you wouldn't have objected to his post).
However, because the string "in C" appeared in the subject, you refused
to even read the post? Exactly what is the logic you are following here?

That this is s C++ group ant there is a C group down the hall?

Is it some kind of odd principle that if a poster confesses that he is
going to ask a question which is relevant to both C and C++, you refuse
to even read the question?

But the OP didn't do that, so why speculate?

Neither the question nor the answer would have been different or
affected in any way, regardless of whether he had written that "in C" in
the subject of his post.

But he did write "in C" in the subject of his post. What's the point in
arguing about something that didn't happen?

 

[Rolf Magnus]

Why not?

If he had omitted the "in C" part in the subject, but otherwise the
post would have been completely identical, you would probably have
answered him (or at least you wouldn't have objected to his post).

I would have answered with a few hints about things he did that one would
usually not do in C++, even if correct (like e.g. use the struct keyword
when defining instances of a struct or using printf instead of std::cout).

However, because the string "in C" appeared in the subject, you refused
to even read the post? Exactly what is the logic you are following here?

The logic is based on the fact that there is a newsgroup dedicated to C.
What would it be good for if C questions were all asked here?

About logic: If you have a question about C, what is the logic in asking it
in a C++ newsgroup and explicitly adding to the subjec that it's actually
about C instead of simply asking in a C newsgroup?

 

[Juha Nieminen]

About logic: If you have a question about C, what is the logic in asking it
in a C++ newsgroup and explicitly adding to the subjec that it's actually
about C instead of simply asking in a C newsgroup?

If the question is relevant for both C and C++, ie. it's not really
C-specific, why does it matter in which group it's asked? The question
and the answer may be of interest to C++ programmers as well.

If I had the question "what happens if I do this: j = (++j)*(++j);",
would you refuse to answer it because that's valid C code?

Tons of such question have been asked in this newsgroup without
problems. However, if those people had added "in C" to the subject of
their posts, then it somehow immediately becomes objectionable to post
it here?

 

[Anand Hariharan]

(...)

If I had the question "what happens if I do this: j = (++j)*(++j);",
would you refuse to answer it because that's valid C code?

Am guessing that's a bait, but that code is as *invalid* C as it is C++.

- Anand

 

[Rolf Magnus]

Juha Nieminen wrote:

If the question is relevant for both C and C++, ie. it's not really
C-specific, why does it matter in which group it's asked?

But the question was C specific. He asked if the provided code is correct C.
So what happens if you run it through a C++ compiler is of no relevance for
the answer.

If I had the question "what happens if I do this: j = (++j)*(++j);",
would you refuse to answer it because that's valid C code?

I would refuse if you specifically ask what happens if you do that in C.
Btw: My answers for C and for C++ would be different.

 

[Victor Bazarov]

If the question is relevant for both C and C++, ie. it's not really
C-specific, why does it matter in which group it's asked?

If the question is on topic, it is answered. And it is usually answered
from the C++ point of view, because that is *assumed*. A question about
C language is *off-topic* in a C++ newsgroup. That's all.

> The question
and the answer may be of interest to C++ programmers as well.

A question and the answer about cooking fish may be of interest to some
photographers. Yet it is bad netiquette to ask about cooking fish in a
photography newsgroup. Get it?

If I had the question "what happens if I do this: j = (++j)*(++j);",
would you refuse to answer it because that's valid C code?

No, I most likely wouldn't. Because I would *assume* the person was
asking about C++ language. I can't *assume* the question is about C++,
or answer it in terms of C++, if the question is *explicitly* about C.
Do you still not get that?

Tons of such question have been asked in this newsgroup without
problems. However, if those people had added "in C" to the subject of
their posts, then it somehow immediately becomes objectionable to post
it here?

Are you asking? What exactly is your question? Is it topical to ask
about C in a C++ newsgroup? The answer is "no, it is not". And the
reason it is not topical is because there is another newsgroup dedicated
to the C language. Do you generally agree with that Usenet practice?
If *not*, there is nothing else to talk about, because you cannot be
convinced that C questions are off-topic. If yes, *what else* is there
to talk about?

If you want the original poster's question *answered*, go ahead and
answer it. If you want *me* to explain why I didn't answer, I hope you
got an earful *already*. So, *what else* is there to talk about?

V

 

[Juha Nieminen]

(...)

Am guessing that's a bait, but that code is as *invalid* C as it is C++.

I knew someone would split hairs with that.

Besides, it's perfectly valid code. It compiles and runs just fine.
The end result might not be unambiguously defined, but that doesn't stop
it from compiling and running just fine.

 

[Juha Nieminen]

A question and the answer about cooking fish may be of interest to some
photographers. Yet it is bad netiquette to ask about cooking fish in a
photography newsgroup. Get it?

Nope, I don't get it. You are comparing two wildly different things,
while in this case the two programming languages are very closely
related. Most C question are also valid C++ questions.

No, I most likely wouldn't. Because I would *assume* the person was
asking about C++ language. I can't *assume* the question is about C++,
or answer it in terms of C++, if the question is *explicitly* about C.
Do you still not get that?

No, I don't. The question and the answer to the question doesn't
change depending on whether the person was thinking about C or C++ when
he wrote the question. So what if he was thinking about C? Are you going
to interrogate every person who posts valid C code in their post whether
they are *really* thinking about C++ instead of C, and if they confess
that they are thinking about C you will start ignoring them? Is this a
question of odd principle?

Are you asking? What exactly is your question? Is it topical to ask
about C in a C++ newsgroup? The answer is "no, it is not". And the
reason it is not topical is because there is another newsgroup dedicated
to the C language. Do you generally agree with that Usenet practice? If
*not*, there is nothing else to talk about, because you cannot be
convinced that C questions are off-topic. If yes, *what else* is there
to talk about?

I am questioning the practice of ignoring people who post completely
valid *C++* questions, but who happen to make the mistake of confessing
that they are thinking of C in the subject of their post. If only they
had omitted that little part, they would get an answer. However, all
they get is reproach.

Now, if they had posted a question which is truely C-specific, ie.
invalid C++ code, *then* there may be more reason to direct them to the
proper group.

 

[Rolf Magnus]

I knew someone would split hairs with that.

Besides, it's perfectly valid code. It compiles and runs just fine.

It might, or it might not.

The end result might not be unambiguously defined,

The behavior (and not just the resulting value) of that code is undefined,
unless it is C++ and j is of a class type with an overloaded operator++.

 

[James Kanze]

If the question is relevant for both C and C++, ie. it's not
really C-specific, why does it matter in which group it's
asked? The question and the answer may be of interest to C++
programmers as well.

If I had the question "what happens if I do this: j =
(++j)*(++j);", would you refuse to answer it because that's
valid C code?

That wouldn't work, because it's not valid C code.

IIUC, no one is rejecting the posting because of the code it
contains. People are objecting to it because the poster asked
explicitly about C. And although it may happen that the answer
will be the same for C and for C++, if you want an answer about
C (and not C++), it makes a lot more sense to ask in
comp.lang.c, rather than here.

 

[James Kanze]

Nope, I don't get it. You are comparing two wildly different
things, while in this case the two programming languages are
very closely related. Most C question are also valid C++
questions.

But normally, the "best" answers will be different for C++ and
for C. Telling someone who's asking about C to use std::string
isn't a very useful response, but it's certainly the usual (and
in many senses, the "best") response here if the code contains a
lot of char* and char[].

No, I don't. The question and the answer to the question
doesn't change depending on whether the person was thinking
about C or C++ when he wrote the question.

The answer does. (As Rolf pointed out, the answer for the above
is NOT the same in C++ as it is in C.)

So what if he was thinking about C? Are you going to
interrogate every person who posts valid C code in their post
whether they are *really* thinking about C++ instead of C, and
if they confess that they are thinking about C you will start
ignoring them? Is this a question of odd principle?

It's not a question of ignoring them. It's a question of
pointing someone who has explicitly asked about C to the forum
where they will get the most appropriate answer. And not
suggestions that they use std::string, and '<<' rather than
printf.

(I think that sometimes, people are too quick to criticize,
saying that the code is "only C". But that's not the case here,
since the poster explicitly asked about C.)

 

[Jerry Coffin]

I knew someone would split hairs with that.

Besides, it's perfectly valid code. It compiles and runs just fine.
The end result might not be unambiguously defined, but that doesn't stop
it from compiling and running just fine.

I'm afraid that's not really true. According to §5/4:

Between the previous and next sequence point a scalar
object shall have its stored value modified at most
once by the evaluation of an expression.

And according to 1.4/1:

The set of diagnosable rules consists of all syntactic
and semantic rules in this International Standard
except for those rules containing an explicit notation
that ?no diagnostic is required? or which are described
as resulting in ?undefined behavior.?

The requirement in §5.4 certainly sounds like a semantic rule to me,
and it doesn't seem to include either of the specified phrases. That
seems to mean that a diagnosable rule has been violated.

§1.3.14 defines a well-formed program as:
a C++ program constructed according to the syntax
rules, diagnosable semantic rules, and the One
Definition Rule (3.2).

So, what you have above is not simply undefined behavior -- it's an
ill-formed program, which is as "invalid" as it gets.

 

[Alf P. Steinbach]

* Jerry Coffin:

I'm afraid that's not really true. According to §5/4:

Between the previous and next sequence point a scalar
object shall have its stored value modified at most
once by the evaluation of an expression.

And according to 1.4/1:

The set of diagnosable rules consists of all syntactic
and semantic rules in this International Standard
except for those rules containing an explicit notation
that ?no diagnostic is required? or which are described
as resulting in ?undefined behavior.?

The requirement in §5.4 certainly sounds like a semantic rule to me,
and it doesn't seem to include either of the specified phrases. That
seems to mean that a diagnosable rule has been violated.

I can't find fault with your logic here, but at the same time this rule cannot
be a diagnosable one (in general).

And so I suggest (1) checking whether C++0x has changed this, and if not, (2)
whether there is an Active Issue, and if not, (3) posting in [comp.std.c++].

Anyway, it would be nice to know the result of that... ;-)

§1.3.14 defines a well-formed program as:
a C++ program constructed according to the syntax
rules, diagnosable semantic rules, and the One
Definition Rule (3.2).

So, what you have above is not simply undefined behavior -- it's an
ill-formed program, which is as "invalid" as it gets.

Cheers,

- Alf

 

[Hao Wang]

I guess you miss some operators for T and S?

Hi all ,

struct S
{
int a;
char c;
char * ptr;

struct S* operator=(struct S &tar)
{
this->a = tar.a;
this->c = tar.c;
if (!this->ptr)
{
this->ptr = new char[strlen (tar.ptr)];
return (memcpy (this->ptr,tar.ptr,strlen (tar.ptr))? this :NULL);
}
}

};


struct T
{
int a;
char c;

struct T* operator=(struct T&tar)
{
this->a = tar.a;
this->c = tar.c;
return this;
}