Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > GCC is re-implementing in C++ and C discarded

Reply
Thread Tools

GCC is re-implementing in C++ and C discarded

 
 
88888 Dihedral
Guest
Posts: n/a
 
      08-25-2012
(E-Mail Removed)於 2012年8月23日星期四UTC+8下午9時32分02秒 寫道:
> On Thu, 23 Aug 2012 10:49:35 +0100, Chicken McNuggets
>
> <(E-Mail Removed)> wrote:
>
>
>
> >On 22/08/2012 21:56, Robert Wessel wrote:

>
> >

>
> >>

>
> >> *Objective C would have a similar high level of C compatibility as

>
> >> C++, for example, but I think you'd be hard pressed to consider that

>
> >> as sufficiently mainstream.

>
> >>

>
> >

>
> >I'm not so sure. Objective-C is growing in popularity all the time. It

>
> >has the advantage that any valid C program is a valid Objective-C

>
> >program and can also use C++ classes directly via Objective-C++. Sounds

>
> >like a win / win situation to me.

>
>
>


Well, the IOS and ARM or BCM CPUS are not selling in the Wintel business
model.

The objective C can be pick up very fast by professional C / C++
programmers.

>
> Outside the Apple world, the use of Objective-C relative to C++
>
> appears to be miniscule, bordering on the non-existent.


 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      08-25-2012
בתאריך יום שבת,25 באוגוסט 2012 10:06:48 UTC+1, מאת Jorgen Grahn:
> On Wed, 2012-08-22, Malcolm McLean wrote:
>
> If that is true, it should worry C programmers.
>
> C++ really /is/ the "better C" in the sense that like C it
>
>
> There are no other important languages in that area.
>

C++ is a superset of C (pedants, attack !!!). So if you write C rather than
C++ you've necessarily rejected C++. The only exception is when you're
developing for tiny embedded systems that don't come with a C++ compiler.

Why would you do that? Basically to make code more reusable, and to reduce
dependencies between source files. If my binary image library was in C++,
fr example, then a "binary image" would be an "object". Then the routines
would be member functions of the class. If you do a competent job then it does
mean that people can rewrite the image class to take packed images. But it
also means that someone look for, say, a distance transform can't just take
the code and drop in into his own program, without also pulling in an entire
binary image class that does the same thing as the one he already
has, but slightly differently.
 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      08-25-2012
בתאריך יום שישי, 24 באוגוסט 2012 10:15:49 UTC+1, מאת Nick Keighley:
> On Aug 23, 7:10*pm, Aaron W. Hsu <(E-Mail Removed)> wrote:
>
> this whole conversation strikes me as bizzare. A kind of level
> confusion. It reminds of one of my collegues who came out with "C++ is
> upwards compatible with C because it is implemented in C" and couldn't
> see what was wrong with that statement.
>

The first C++ compilers spat out C code, which was then fed to the C
compiler. Any language can be implemented in any other. The colleague
had probably heard a garbled version of the first statement, and wasn't
aware of the second.
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      08-25-2012
Malcolm McLean wrote:

> The first C++ compilers spat out C code, which was then fed to the C
> compiler. Any language can be implemented in any other. The colleague
> had probably heard a garbled version of the first statement, and wasn't
> aware of the second.


If I'm not mistaken, that trick ceassed to work once exceptions were thrown
in the mix.


Rui Maciel
 
Reply With Quote
 
Johannes Bauer
Guest
Posts: n/a
 
      08-25-2012
On 25.08.2012 12:07, Malcolm McLean wrote:

>> C++ really /is/ the "better C" in the sense that like C it
>>

> C++ is a superset of C (pedants, attack !!!). So if you write C rather than
> C++ you've necessarily rejected C++. The only exception is when you're
> developing for tiny embedded systems that don't come with a C++ compiler.


This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
Some constructs which are necessary for embedded systems are just syntax
errors in C++, while they work perfectly in C.

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht öffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$(E-Mail Removed)>
 
Reply With Quote
 
Johannes Bauer
Guest
Posts: n/a
 
      08-25-2012
On 25.08.2012 15:35, James Kuyper wrote:

>> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
>> Some constructs which are necessary for embedded systems are just syntax
>> errors in C++, while they work perfectly in C.

>
> I can understand the necessity of using C on an embedded system if C++
> is not available there. However, if a C++ compiler is available, I can't
> imagine what these "necessary constructs" could be.


Placing an interrupt vector table in ROM:

struct ivtlayout {
int vec1;
int vec2;
int vec3;
};

struct ivtlayout ivt = {
.vec1 = 1234,
};

int main() {
return 0;
}

> If you're talking about something non-portable, is there anything
> preventing a C++ compiler from providing support for a corresponding
> non-portable construct?


No, definitely not. Non-portable C++ could definitely provide this. I am
just really not a big fan of non-portable dialects. Actually, I really
don't know why this wasn't included in c++0x.

Best regards,
Johannes


--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht öffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$(E-Mail Removed)>
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      08-25-2012
Am 25.08.2012 15:35, schrieb James Kuyper:
> However, that was basically just a trick (and it took me a long time to
> perfect it). As far as I know, everything that can be done using
> portable C code can also be done by using (possibly different) C code
> that also compiles as C++ code, with the same exact meaning in both
> languages (exception: code like that which I described above, whose sole
> purpose is to detect which language it was compiled in - by definition
> such code must behave differently in order to behave correctly). Could
> you give a counter-example?


The intersection of C and C++ has
- no decent initializers, you'd need designated initializers on the C
side and constructors for C++
- no decent temporaries (compound literals for C and constructors for C++)
- no consistent way of passing dynamically sizes multi-dimensional
arrays to functions
- no type puning (union's are standardized differently between the
two)
- no consistent model for function inlining

not very attractive, at least for me

Jens
 
Reply With Quote
 
Johannes Bauer
Guest
Posts: n/a
 
      08-25-2012
On 25.08.2012 17:55, Jens Gustedt wrote:

> The intersection of C and C++ has
> - no decent initializers, you'd need designated initializers on the C
> side and constructors for C++
> - no decent temporaries (compound literals for C and constructors for C++)
> - no consistent way of passing dynamically sizes multi-dimensional
> arrays to functions
> - no type puning (union's are standardized differently between the
> two)
> - no consistent model for function inlining
>
> not very attractive, at least for me


I'm using C++ (and c++0x at that) for doing very, very low-level work,
down to 8 bit microcontrollers. And while most people seem to think that
this is impossible, quite the contrary is true: There is a huge benefit
in using it (if it is used correctly). For 8 bitters, for example, I do
not use fancy stuff (virtual methods, inheritance etc), nor parts of the
STL. I use heavily low-level language guarantees, such as strong typing
and especially strongly types class enums (gotta love those!).

To give an example on how MCU code looks using C and how it's usually
done (this is an example from an actual project of mine):

TCCR1A = _BV(COM1A1); /* Clear on Compare Match */
TCCR1B = _BV(CS10) | _BV(WGM13); /* 1 / 1 */
TCCR0B = _BV(CS02) | _BV(CS00);

where the _BV() macro is defined to be _BV(x) (1 << (x)). All the
symbols are defined by the standard library, the lvalues are volatile
registers and the rvalues are basically just bit definitions of the
hardware's datasheet.

This is just horrible. Notice how the settings of two different timers
are set, the first two lines refer to Timer 1 while the third refers to
timer 0. Both have a prescaler, or clock selection. Notice that the bits
in the standard library for this AVR processor are named CSnm, where n
is the timer (0, 1) and m is the bitvalue (0, 1, 2, 3). Obviously it is
*very* error-prone, because setting the wrong one in either register
leads to weird (and hard to debug results).

In C++, whith smart constructs, you can basically say

TCCR1().PRESCALER() = T1Presc::CKDIV_2;
TCCR0().PRESCALER() = T0Presc::CKDIV_16;

and it will boil down to the *exact* same code with no performance
penalty at all, only added typesafety. The compiler will barf if you try
to put the wrong type into a field. I find that quite awesome and this
is actually a reason for me to prefer C++ over C for this type of work.

Best regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht öffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$(E-Mail Removed)>
 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      08-25-2012
Johannes Bauer wrote:
> On 25.08.2012 11:06, Jorgen Grahn wrote:
>
>> If that is true, it should worry C programmers.
>>
>> C++ really /is/ the "better C" in the sense that like C it
>> - works for low-level code
>> - works in environments with little runtime support

>
> You clearly do *not* write low-level code.
>
> Pre-initialized structures, which C provides, are for some architectures
> I'm working in a *MUST*, since they determine the interrupt vector table
> which gets transferred to C. C++ just does not offer this. Referring to
> the Cortex-M3 and -M4 series here, for example (where the initial stack
> pointer and the IVT are placed in the start of flash).
>


I am fairly sure it is eminently possible to use pre-initialized structs
in C++.

> In fact I wrote a library to conveniently and efficiently address
> low-level registers of a MCU using c++0x features, so access to
> bitfields is truely typesafe (class enums!). This works nice and well,
> but for other parts, C is still a must because C++ just doesn't cut it.
>
> Regards,
> Johannes
>


--
Les Cargill
 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      08-25-2012
Johannes Bauer wrote:
> On 25.08.2012 16:59, Gareth Owen wrote:
>> Johannes Bauer <(E-Mail Removed)> writes:
>>
>>> On 25.08.2012 12:07, Malcolm McLean wrote:
>>>
>>> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
>>> Some constructs which are necessary for embedded systems are just syntax
>>> errors in C++, while they work perfectly in C.

>>
>> Could you give an example or three?

>
> As I said in the previous postings, a construct like this is one of the
> last reasons to have some files in C for MCU projects that I'm working
> on. Omitting some deatils (like attribute specifiers which specify where
> the IVT goes), but that's the gist:
>
> struct ivtlayout {
> int vec1;
> int vec2;
> int vec3;
> };
>
> struct ivtlayout ivt = {
> .vec1 = 1234,
> };
>
> int main() {
> return 0;
> }
>
>
> [~/tmp]: gcc -O2 -Wall -Wextra -std=c99 -pedantic x.c
> [~/tmp]: g++ -O2 -Wall -Wextra -std=c++0x -pedantic x.c
> x.c:8:2: Error: expected primary-expression before . token
>
> Best regards,
> Johannes
>



This seems to work. I commented out the string
".vec1 = 1234", which isn't strictly necessary anyway
( but is a nice thing to have available ).

C:\c\usenet>cat prein.cpp

#include <stdio.h>


struct ivtlayout {
int vec1;
int vec2;
int vec3;
};

struct ivtlayout ivt = {
/*.vec1 =*/ 1234,
};

int main() {
printf("ivt.vec1=%d\n",ivt.vec1);
return 0;
}

C:\c\usenet>g++ prein.cpp

C:\c\usenet>a
ivt.vec1=1234

C:\c\usenet>

--
Les Cargill
 
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
Re: GCC is re-implementing in C++ and C discarded Nomen Nescio C Programming 0 08-26-2012 10:34 AM
Re: GCC is re-implementing in C++ and C discarded Anonymous C Programming 10 08-26-2012 08:04 AM
Cisco VPN client, packets beeing discarded and bypassed seansan Cisco 3 09-24-2006 10:50 AM
discarded iterator.next() at interactive global scope doesn't bump interator?? Bengt Richter Python 2 09-04-2005 12:17 PM
Linker Message: "discarded section" Hartmut Sbosny C++ 2 05-29-2005 12:20 AM



Advertisments