Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Any C code are valid C++ code?

Reply
Thread Tools

Any C code are valid C++ code?

 
 
E. Robert Tisdale
Guest
Posts: n/a
 
      12-11-2004
Dik T. Winter wrote:

> E. Robert Tisdale writes:
> > Richard Tobin wrote:
> > > E. Robert Tisdale wrote:
> > >>From which I conclude that
> > >>it isn't very difficult at all for you
> > >>to ensure that your C code will compile as C++ code
> > >>and perform as expected.
> > >
> > > Possibly not, but I have no incentive to do so.

> >
> > Evidently, you don't think of the people who
> > "have mailed me to ask why one of my C programs doesn't compile"
> > as customers or employers.

>
> Probably you have not thought that the C programs involved possibly
> were freeware? Obviously, if the person complaining is a customer
> or an employer, there is pretty good incentive to make changes.
> When somebody complains about a program I put out for free, I will
> simply let it go if it is some incompatibility. Only when a (good)
> suggestion for change is involved am I inclined to modify. Why
> should I put in my free time in changing things that work for me as
> I want?


Apparently, it's a question of pride versus professionalism.
 
Reply With Quote
 
 
 
 
Herbert Rosenau
Guest
Posts: n/a
 
      12-11-2004
On Fri, 10 Dec 2004 21:56:42 UTC, "E. Robert Tisdale"
<(E-Mail Removed)> wrote:

> Victor Bazarov wrote:
>
> > http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> >
> >> Since C is a subset of C++ [...]

> >
> > Wrong premise. Wrong conclusion. The answer to your subj is "no".

>
> Practically speaking, C is a subset of C++.
> There are few exceptions.
> Each new C++ standard attempts to subsume each new C standard.


Twitsdale proves again that he does not even know what C is. You
should ignore that Twit completely.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
 
Reply With Quote
 
 
 
 
Malcolm
Guest
Posts: n/a
 
      12-11-2004

"Chris Barts" <(E-Mail Removed)> wrote
> > Since C is a subset of C++,

>
> Wrong. A common notion that is completely wrong.
>

Partly wrong. C++ was designed as a superset of C, but in order to avoid
uglification it was accepted that some C scripts would break when compiled
under C++. In fact it turns out that the majority of real C scripts will so
break, unless written with the deliberate intention of compiling under both
langages. This is not difficult to achieve, but does require some care.


 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      12-11-2004
In article <cpdj5o$ipi$(E-Mail Removed)>,
E. Robert Tisdale <(E-Mail Removed)> wrote:

>> Possibly not, but I have no incentive to do so.


>Evidently, you don't think of the people who
>"have mailed me to ask why one of my C programs doesn't compile"
>as customers or employers.


Some of them were customers or potential customers. And of course
I did answer their question: I told them to use a C compiler.

Perhaps it is different for you, but I have the good fortune to be in
a position where just because someone is an employer or customer, I
don't have to abandon my own judgment when answering their questions.

-- Richard
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-11-2004
On Fri, 10 Dec 2004 23:20:33 GMT, in comp.lang.c , "Default User"
<(E-Mail Removed)> wrote:

>Mark McIntyre wrote:
>
>> On Fri, 10 Dec 2004 20:42:03 +0200, in comp.lang.c , "Alex Vinokur"
>> <(E-Mail Removed)> wrote:
>>
>> >"Jonathan Bartlett" <(E-Mail Removed)> wrote
>> >> * different interpretation of multidimensional arrays

>>
>> > What is the difference?

>>
>> C lets you blur the distinction between ** and *[ ] and [ ][ ]
>> rather more, especially in function calls.

>
>Eh, what? Could you explain?


This code
void foo(char a[2][2]) {
// do nothing
}

int main(void) {
char** a;
foo(a);
return 0;
}

will cause most C++ compilers to abort, as in C++ there's no possible
conversion from char** to *char[2].
A C compiler will typically complain but compile it anyway, perhaps since
there is often a practical way to perform the conversion.

This may simply be a QOI issue or a case of getting overchummy with the
implementation. But I've come across this in real live production code
written by 3rd parties of great eminence.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
 
Reply With Quote
 
Malcolm
Guest
Posts: n/a
 
      12-11-2004
"Richard Tobin" <(E-Mail Removed)> wrote
>
> Perhaps it is different for you, but I have the good fortune to be in
> a position where just because someone is an employer or customer, I
> don't have to abandon my own judgment when answering their questions.
>

I've had to write code that was to all intents and purposes C in C++,
because C++ was more in keeping with the image of the company.


 
Reply With Quote
 
Joona I Palaste
Guest
Posts: n/a
 
      12-11-2004
Mark McIntyre <(E-Mail Removed)> scribbled the following
on comp.lang.c:
> On Fri, 10 Dec 2004 23:20:33 GMT, in comp.lang.c , "Default User"
> <(E-Mail Removed)> wrote:
>>Mark McIntyre wrote:
>>> On Fri, 10 Dec 2004 20:42:03 +0200, in comp.lang.c , "Alex Vinokur"
>>> <(E-Mail Removed)> wrote:
>>> >"Jonathan Bartlett" <(E-Mail Removed)> wrote
>>> >> * different interpretation of multidimensional arrays
>>>
>>> > What is the difference?
>>>
>>> C lets you blur the distinction between ** and *[ ] and [ ][ ]
>>> rather more, especially in function calls.

>>
>>Eh, what? Could you explain?


> This code
> void foo(char a[2][2]) {
> // do nothing
> }


> int main(void) {
> char** a;
> foo(a);
> return 0;
> }


> will cause most C++ compilers to abort, as in C++ there's no possible
> conversion from char** to *char[2].
> A C compiler will typically complain but compile it anyway, perhaps since
> there is often a practical way to perform the conversion.


> This may simply be a QOI issue or a case of getting overchummy with the
> implementation. But I've come across this in real live production code
> written by 3rd parties of great eminence.


I don't understand. Although the C standard says that the type char[2]
is assignable to the type char *, it also says that the type char[2][2]
is definitely *not* assignable to the type char **.
When you indirect into a char[2][2] or a char(*)[2], you expect to find
two bytes of storage right there. However, when you indirect into a
char **, you expect to find a pointer, which then points to another
byte, which might or might not be storage.

--
/-- Joona Palaste ((E-Mail Removed)) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen
 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      12-11-2004
In article <(E-Mail Removed)>,
Chris Barts <(E-Mail Removed)> wrote:
>(E-Mail Removed) wrote:
>> Since C is a subset of C++,

>
>Wrong. A common notion that is completely wrong.
>
>> so any C code or C libraries (printf(), scanf(), etc...)
>> are valid C++ code.

>
>Not true. For example, the following valid C program is not valid C++:
>
>#include <stdlib.h>
>
>int main(void)
>{
> /* new is a reserved word in C++ */
> char new, *buf;


Leaving aside the malloc issues, I'd like to comment on the "new is
a reserved word" issue, in the context of languages in general.

Given that languages always evolve over time and add in new keyords, in some
sense it can never be said that a later version of any language is
a superset of an (or all) previous version(s) of that same language. This
is because some program written to the earlier spec may have used as an
identifier something which is now reserved to the implementation.

I know that C has some features designed to minimize this, such as
reserving certain ranges of words (e.g., str*), features that are not found
in other languages, but still the problem persists. As they say, this is
why they pay us the big bucks...

 
Reply With Quote
 
Christian Bau
Guest
Posts: n/a
 
      12-11-2004
In article <9atud.479764$wV.300818@attbi_s54>,
"Victor Bazarov" <(E-Mail Removed)> wrote:

> "Dik T. Winter" <(E-Mail Removed)> wrote...
> > [...] Why
> > should I put in my free time in changing things that work for me as
> > I want?

>
> Why did you feel compelled to publish it in the first place? Can
> the same reason apply to compel you to fix it? If not, was it the
> _real_ reason you published your code? You don't have to answer.


If I write C code that I didn't intentionally make C++ compatible, then
there is always a chance that for some minor reason the code won't work
if compiled as a C++ program.

However, if you take my C source code, compile it using a C++ compiler,
and you are not capable of fixing whatever minor problems come up, then
perhaps it is dangerous letting you loose on that code.
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-12-2004
On 11 Dec 2004 18:20:05 GMT, in comp.lang.c , Joona I Palaste
<(E-Mail Removed)> wrote:

>Mark McIntyre <(E-Mail Removed)> scribbled the following
>on comp.lang.c:


(snip pretty contrived example of difference between C and C+ compiler)

>
>I don't understand. Although the C standard says that the type char[2]
>is assignable to the type char *, it also says that the type char[2][2]
>is definitely *not* assignable to the type char **.


Yeah, maybe. But no C compiler I've encountered will reject this code,
while every C++ one will. Like I said, QOI, or what? I belive you're right,
but the fact is, C code that compiles /and runs just fine on multiple
implementations/ won't even compile under C++.

>When you indirect into a char[2][2] or a char(*)[2], you expect to find
>two bytes of storage right there. However, when you indirect into a
>char **, you expect to find a pointer, which then points to another
>byte, which might or might not be storage.


Could be, Zaphod.

But remind me, does an array degenerate to a pointer under certain
circumstances, and is a pointer to x roughly the same as the address of a
block of type x? Or not? Or ....My heads hurt.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
501 PIX "deny any any" "allow any any" Any Anybody? Networking Student Cisco 4 11-16-2006 10:40 PM
XSD: Any valid XML in one node - different parser results mkremser@gmail.com XML 5 01-20-2005 11:39 PM
Deprecated functionality with generics (previously valid code now invalid) mortoray@ecircle-ag.com Java 2 01-18-2005 08:18 PM
Any C code are valid C++ code? jrefactors@hotmail.com C Programming 67 12-20-2004 06:29 AM
The promotion code "MSUU4C8E3475" is not a valid promotion code Sam-Hong Kong MCDST 2 03-04-2004 06:47 PM



Advertisments