Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C or C++

Reply
Thread Tools

C or C++

 
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-09-2008
Clarification:


Ioannis Vranos wrote:
> Carmen Sei wrote:
>> if I need to write C++, I will be forced to learn C automatically?
>>
>> Since I saw many C++ code need to call C library also.
>>
>> Most program use a combination of C++ code and calling C functions.
>>
>> Then writting C++, I cannot avoid learning C right?

>
>
> With minor exceptions C95 (ISO/IEC 9899:1995) is a subset of C++
> (ISO/IEC 14882:2003). More accurately it is almost the entire functional
> paradigm subset of C++ (C++ supports 4 paradigms completely, the
> functional paradigm, the object oriented paradigm, the generic
> programming paradigm (templates), and the modular paradigm (namespaces).
>
> Each paradigm is supported well with close to optimal space and time
> efficiencies.
>
> If the question is about learning C before C++, it is not needed.

Actually it is not recommended. Learn C++ ==> alone if you do not need to
> know C programming.
>
> Currently C (ISO/IEC 9899:1999) and C++ (ISO/IEC 14882:2003) are two
> different languages.

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      04-09-2008
Ioannis Vranos wrote:
> Carmen Sei wrote:
>> if I need to write C++, I will be forced to learn C automatically?
>>
>> Since I saw many C++ code need to call C library also.
>>
>> Most program use a combination of C++ code and calling C functions.
>>
>> Then writting C++, I cannot avoid learning C right?

>
>
> With minor exceptions C95 (ISO/IEC 9899:1995) is a subset of C++
> (ISO/IEC 14882:2003).


No, they are not "minor exceptions".

--
Ian Collins.
 
Reply With Quote
 
 
 
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-09-2008
Ian Collins wrote:
> Ioannis Vranos wrote:
>> Carmen Sei wrote:
>>> if I need to write C++, I will be forced to learn C automatically?
>>>
>>> Since I saw many C++ code need to call C library also.
>>>
>>> Most program use a combination of C++ code and calling C functions.
>>>
>>> Then writting C++, I cannot avoid learning C right?

>>
>> With minor exceptions C95 (ISO/IEC 9899:1995) is a subset of C++
>> (ISO/IEC 14882:2003).

>
> No, they are not "minor exceptions".



Supposing you are not talking about the word "exception", the exceptions
I know are the following:


1. Not implicit void * to any other pointer type conversion, as in C95.
2. 'a' is a char in C++ and not an int as in C95.
3. 0 is to be preferred than NULL, which does not apply to C95.
4. POD types can be considered as char/unsigned char sequences in C++,
but only as unsigned char sequences in C95.
5. Empty parentheses in function declarations/definitions are equivalent
to void in C++, but is a different thing in C95.


(6?) The following is guaranteed to not compile in C95, but it compiles
in my C++ compiler, but I am not sure if it is a difference or a
compiler-thing:


int main(void)
{
register char array[]= "Test";

char *p= array;

return 0;
}


Have I forgotten anything?
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-09-2008
Ioannis Vranos wrote:
> Ian Collins wrote:
>> Ioannis Vranos wrote:
>>> Carmen Sei wrote:
>>>> if I need to write C++, I will be forced to learn C automatically?
>>>>
>>>> Since I saw many C++ code need to call C library also.
>>>>
>>>> Most program use a combination of C++ code and calling C functions.
>>>>
>>>> Then writting C++, I cannot avoid learning C right?
>>> With minor exceptions C95 (ISO/IEC 9899:1995) is a subset of C++
>>> (ISO/IEC 14882:2003).

>> No, they are not "minor exceptions".

>
>
> Supposing you are not talking about the word "exception", the exceptions
> I know are the following:
>
>
> 1. Not implicit void * to any other pointer type conversion, as in C95.
> 2. 'a' is a char in C++ and not an int as in C95.
> 3. 0 is to be preferred than NULL, which does not apply to C95.
> 4. POD types can be considered as char/unsigned char sequences in C++,
> but only as unsigned char sequences in C95.
> 5. Empty parentheses in function declarations/definitions are equivalent
> to void in C++, but is a different thing in C95.
>
> Have I forgotten anything?


Implicit int, missing function prototypes, use of const, assignments to
enums...

--
Ian Collins.
 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-09-2008
Ian Collins wrote:
> Ioannis Vranos wrote:
>> Ian Collins wrote:
>>> Ioannis Vranos wrote:
>>>> Carmen Sei wrote:
>>>>> if I need to write C++, I will be forced to learn C automatically?
>>>>>
>>>>> Since I saw many C++ code need to call C library also.
>>>>>
>>>>> Most program use a combination of C++ code and calling C functions.
>>>>>
>>>>> Then writting C++, I cannot avoid learning C right?
>>>> With minor exceptions C95 (ISO/IEC 9899:1995) is a subset of C++
>>>> (ISO/IEC 14882:2003).
>>> No, they are not "minor exceptions".

>>
>> Supposing you are not talking about the word "exception", the exceptions
>> I know are the following:
>>
>>
>> 1. Not implicit void * to any other pointer type conversion, as in C95.
>> 2. 'a' is a char in C++ and not an int as in C95.
>> 3. 0 is to be preferred than NULL, which does not apply to C95.
>> 4. POD types can be considered as char/unsigned char sequences in C++,
>> but only as unsigned char sequences in C95.
>> 5. Empty parentheses in function declarations/definitions are equivalent
>> to void in C++, but is a different thing in C95.
>>
>> Have I forgotten anything?

>
> Implicit int, missing function prototypes, use of const,


Right, those too.


> assignments to
> enums...



An example?

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-09-2008
Ioannis Vranos wrote:
> Ian Collins wrote:
>> Ioannis Vranos wrote:
>>> Ian Collins wrote:
>>>> Ioannis Vranos wrote:
>>>>> Carmen Sei wrote:
>>>>>> if I need to write C++, I will be forced to learn C automatically?
>>>>>>
>>>>>> Since I saw many C++ code need to call C library also.
>>>>>>
>>>>>> Most program use a combination of C++ code and calling C functions.
>>>>>>
>>>>>> Then writting C++, I cannot avoid learning C right?
>>>>> With minor exceptions C95 (ISO/IEC 9899:1995) is a subset of C++
>>>>> (ISO/IEC 14882:2003).
>>>> No, they are not "minor exceptions".
>>> Supposing you are not talking about the word "exception", the exceptions
>>> I know are the following:
>>>
>>>
>>> 1. Not implicit void * to any other pointer type conversion, as in C95.
>>> 2. 'a' is a char in C++ and not an int as in C95.
>>> 3. 0 is to be preferred than NULL, which does not apply to C95.
>>> 4. POD types can be considered as char/unsigned char sequences in C++,
>>> but only as unsigned char sequences in C95.
>>> 5. Empty parentheses in function declarations/definitions are equivalent
>>> to void in C++, but is a different thing in C95.
>>>
>>> Have I forgotten anything?

>> Implicit int, missing function prototypes, use of const,

>
> Right, those too.
>

I wouldn't call any of the above "minor exceptions".

>> assignments to
>> enums...

>
> An example?
>

typedef enum { one, two } E;

E e = 42;

--
Ian Collins.
 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      04-10-2008
Alf P. Steinbach wrote:


>> What do you mean by "valid C++"?

>
> The C programming language is defined by a set of international standards.
>
> Usually when we refer to "C" we mean the previous standard, C89 (a.k.a.
> C90).


C89/C90 is not a standard. It ceased to be one about 9 years ago. Not sure
if you mean that by "the previous standard". Btw: It's kind of strange that
the C++ standard refers to C90 in some places, even says that the whole
language is based on it, but you can't order its definition anymore, since
it's been replaced by C99. In my eyes, that makes the C++ standard severely
broken and incomplete.

>> I would think most C programs would compile with a C++ compiler, unless
>> they use keywords introduced in C++ as identifiers (e.g. new, delete).

>
> You're right that unless a C program is invalid as C++, it's valid.
>
> And depending on your definition of "most" the complete sentence might
> arguably be trivially true.


I don't think that it is for a reasonable definition of "most". (To the OP)
One example would be calls to the function malloc(). Its return value is of
type pointer to void, and in C, the general advice it to not cast it when
assigning it to a pointer of different type. In C++ however, you'll get an
error if you assign it to other pointer types without casting it. So "most"
C programs that use malloc will not compile as C++ without a modification.

 
Reply With Quote
 
Rolf Magnus
Guest
Posts: n/a
 
      04-10-2008
Alf P. Steinbach wrote:

> * Rolf Magnus:
>> Alf P. Steinbach wrote:
>>
>>
>>>> What do you mean by "valid C++"?
>>> The C programming language is defined by a set of international
>>> standards.
>>>
>>> Usually when we refer to "C" we mean the previous standard, C89 (a.k.a.
>>> C90).

>>
>> C89/C90 is not a standard. It ceased to be one about 9 years ago. Not
>> sure if you mean that by "the previous standard".

>
> Yes, that's correct (the first literally in an impractical formalistic
> narrow interpretation,


It's how the C99 standard officially defines it. And it also results from
the fact that you can't obtain C89, neither from ANSI, nor from ISO. You
just need to happen to know someone who has an old printed copy (or have
one on your own) to be able to read it. I'd say that's pretty impractical,
too. I know that there are still lots of compilers that have broken or no
C99 support, even though it has been there for almost 10 years, and that
there are also lots of C programmers that ignore C99 (maybe for just that
reason, or maybe because they just don't care at all).

>> Btw: It's kind of strange that
>> the C++ standard refers to C90 in some places, even says that the whole
>> language is based on it, but you can't order its definition anymore,
>> since it's been replaced by C99. In my eyes, that makes the C++ standard
>> severely broken and incomplete.

>
> The current C++ standard was adopted in 1998, before C99.


That doesn't change the fact that it's broken now. In the period from 1998
to 1999, it was ok. If you don't have access to an old C90 document, there
is no way to get a full definition of ISO C++. IMHO, that's not an
acceptable state for an international standard.

> The 2003 version is not new standard but Technical Corrigendum 1 (TC1).
>
> It could not change the reference to the C standard.


It's a reference to something that's not available, so it's still broken. It
could have had an addenum that contained the relevant parts of C90.

 
Reply With Quote
 
Ioannis Vranos
Guest
Posts: n/a
 
      04-10-2008
Rolf Magnus wrote:
>
> That doesn't change the fact that it's broken now. In the period from 1998
> to 1999, it was ok. If you don't have access to an old C90 document, there
> is no way to get a full definition of ISO C++. IMHO, that's not an
> acceptable state for an international standard.



Actually the C subset if C++ is C95 (9899:1995 - Amendment 1).


>> The 2003 version is not new standard but Technical Corrigendum 1 (TC1).
>>
>> It could not change the reference to the C standard.

>
> It's a reference to something that's not available, so it's still broken. It
> could have had an addenum that contained the relevant parts of C90.



I agree with that. The C++ standard must become self-contained.

 
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




Advertisments