Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Advanced C

Reply
Thread Tools

Advanced C

 
 
Ingo Menger
Guest
Posts: n/a
 
      11-30-2005

Flash Gordon schrieb:

> Ingo Menger wrote:


> > It is also announced on the very first introductionary web page, that
> > it is not portable, and cannot possibly be.
> > So what?

>
> You said written in C, it isn't it written in C + other things.


If it is written in C and asm, then the statement "it is written in C"
is obviously true.
Not so for "It is entirely written in C", "It is written in C and only
C", "It is written in C and nothing else", none of which I did state.

> You might, I would say it is mostly written in C since I recognise that
> it is not written in C in its entirety.


The same is true for the GC.

> Some requires assembler, some can be done with extensions to C, but
> neither assembler not those extensions are actually part of C. If you
> think they are, then point them out in a normative section of the standard.


I don't think so, and I wonder how you might think that I'd think so.

 
Reply With Quote
 
 
 
 
Michael Mair
Guest
Posts: n/a
 
      11-30-2005
rainbve wrote:
> "Michael Mair" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>pemo wrote:
>>
>>>What would expect to be covered?
>>>
>>>Say you'd already attended a course, that had covered stuff like structs,
>>>pointers, bitwise and logical operators, multi-demensional arrays [and
>>>the like], *but* hadn't covered other stuff like recursion, unions,
>>>bit-fields [and the like].
>>>
>>>What topics would /should be covered on a course that takes students
>>>further?

>>
>>Depends on what the students should be able to do after the
>>course. Here is a (roughly translated) table of contents for a
>>course I taught last year; <snip> indicates left-out parts.
>>Note that the topics are not necessarily mentioned the first time
>>when they appear in the ToC:
>>
>>,----
>>0 Intro

>
> <snip>
>
>>II Kr
>>7 File I/O
>><snip>
>>8 Tools
>>8.1 gcc
>>8.2 make
>>8.3 lint/splint
>>8.4 ar
>>8.5 cvs
>>8.6 gdb and ddd
>>8.7 electric fence
>>8.8 prof/gprof
>>8.9 Editor
>>8.10 Overview
>>9 Optimisation

>
> <snip>
>
> What are the subjects in 8.4 and 8.7?


These are actually off-topic round here, as you probably
already inferred from the "Tools" heading...
<OT>
I taught in a unixoid environment.

ar is a program to create and change archives as well as
extract from them; in my experience and in the above mentioned
section especially, it is used to create libraries from object
files. For more details
man ar
(you can also try this with google)

electric fence is a debug library you can link with; it replaces
malloc()/calloc()/realloc()/free() and detects access to a memory
location after (or, if wished, before) the allocated memory you
own or, by option, access to memory which once belonged to you
but has been freed.
It is an old and simple tool and quite easy to use and usually
is a quick help for finding subtle off-by-one errors.
There are better tools but I was not aiming at making the
students into professional programmers but give them a good
overview over _possible_ tools -- I often had (and sometimes still
have) the revelation "oh, such a tool exists? My, how much time this
could have saved me when..."
</OT>

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
 
 
 
Michael Mair
Guest
Posts: n/a
 
      11-30-2005
Imre Palik wrote:
> Michael Mair <(E-Mail Removed)> writes:
>
>
>>Imre Palik wrote:
>>
>>>"Ingo Menger" <(E-Mail Removed)> writes:
>>>
>>>
>>>>...
>>>>Sure, but the topic is "Advanced C".
>>>>And certainly, unions deserve much more attention than, for example
>>>>bitfields. Whereas the former is an concept that supports advanced
>>>>(altough rarely known) programming paradigms, the latter is just
>>>>another way of storing a bunch of unsigned numbers using less space.
>>>
>>>I thought the same way, until I had to to do some calculations with 24
>>>bit signed integers. I wouldn't do that without bit fields ...

>>
>>Hmmm, that will not work portably, though: The guarantees for
>>the usefulness of signed integer bit-fields are not very strong.

>
>
> Do you think it is not enough?
>
> 8 A bit-field shall have a type that is a qualified or unqualified
> version of _Bool, signed int, or unsigned int. A bit-field is
> interpreted as a signed or unsigned integer type consisting of the
> specified number of bits.93) If the value 0 or 1 is stored into a
> nonzerowidth bit-field of type _Bool, the value of the bit-field
> shall compare equal to the value stored.
>
>
>>Apart from that, "unexpected" integer promotions may make life
>>difficult.

>
>
> Could you explain this?


Read the threads
- containing <(E-Mail Removed)> which refers to
- the one starting at
<yBkKd.33221$(E-Mail Removed)>
(longish but enlightening)
- and maybe the one starting at
<(E-Mail Removed)>

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-30-2005
"Ingo Menger" <(E-Mail Removed)> writes:
> Flash Gordon schrieb:
>
>> Ingo Menger wrote:

>
>> > It is also announced on the very first introductionary web page, that
>> > it is not portable, and cannot possibly be.
>> > So what?

>>
>> You said written in C, it isn't it written in C + other things.

>
> If it is written in C and asm, then the statement "it is written in C"
> is obviously true.
> Not so for "It is entirely written in C", "It is written in C and only
> C", "It is written in C and nothing else", none of which I did state.


I interpret the statement "It is written in C" as equivalent to "It is
entirely written in C", though the latter is more explicit.

Since this has become a debate about the meanings of English sentences
rather than about the C programming language, I suggest we leave it at
that.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      12-01-2005
Skarmander <(E-Mail Removed)> writes:

> Ben Pfaff wrote:
>> char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
>> ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x1f6},*p=
>> b,x,i=24;for(;p+=!*p;*p/=4)switch(x=*p&3)case 0:{return 0;for(p--;i--;i--)case
>> 2:{i++;if(1)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}

>
> This code invokes undefined behavior by accessing b[7]. Here's a
> possible fix:
>
> char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
> ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
> ,i=24;for(p=b;p+=!*p;*p/=4)switch(*p&3)case 0:{return 0;for(p--;i--;i--)case 2
> :{i++;if(1)break;else default:continue;if(0)case 1utchar(a[i&017]);break;}}}


Excellent spotting. I've been posting that sig for years and no
one's ever noticed before. Certainly I hadn't.

Your fix is fine, of course. Here is a different one that
introduces a small amount of additional misdirection:

char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}
--
"The expression isn't unclear *at all* and only an expert could actually
have doubts about it"
--Dan Pop
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      12-01-2005
Keith Thompson wrote:
> "Ingo Menger" <(E-Mail Removed)> writes:
>> Flash Gordon schrieb:
>>
>>> Ingo Menger wrote:
>>>> It is also announced on the very first introductionary web page, that
>>>> it is not portable, and cannot possibly be.
>>>> So what?
>>> You said written in C, it isn't it written in C + other things.

>> If it is written in C and asm, then the statement "it is written in C"
>> is obviously true.
>> Not so for "It is entirely written in C", "It is written in C and only
>> C", "It is written in C and nothing else", none of which I did state.

>
> I interpret the statement "It is written in C" as equivalent to "It is
> entirely written in C", though the latter is more explicit.


As do I. After all a C programmer could be expected to follow something
written in C but if critical bits are not C then a C programmer might
not stand a chance.

> Since this has become a debate about the meanings of English sentences
> rather than about the C programming language, I suggest we leave it at
> that.


Indeed. I'll drop it here.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      12-06-2005
Ben Pfaff <(E-Mail Removed)> writes:

> "Imre Palik" <(E-Mail Removed)> writes:
>
> > I thought the same way, until I had to to do some calculations with 24
> > bit signed integers. I wouldn't do that without bit fields ...

>
> Bit-fields have the same type as another C language type, such as
> signed int or unsigned int. I don't see how they would help with
> 24-bit signed arithmetic, at least without involving undefined
> behavior.


If the operations being done don't overflow a 24 bit result, then
signed bit-fields should work just fine. Operations that overflow
would produce implementation defined or undefined behavior, but
overflow when using signed operands is undefined behavior in
any case. A 24 bit signed bit-field should behave just as nicely
as a 24 bit signed integer type that's a built in integer type
(as long as you don't want to have a pointer to it, make an
array of them, etc).

Incidentally, bit-fields are declared using int, signed int, or
unsigned int, but the type of a bit-field (usually) isn't quite
the same as the type used in the declaration but without the
bit-field-ness. Consider:

struct { unsigned u; unsigned b:1; } s = { 1, 1 };

if( (s.u << 31) > 0 ) printf( "foo" );
if( (s.b << 31) > 0 ) printf( "bas" );
printf( "\n" );

The bit-field s.b is an unsigned type, and it's legal to assign
any integral value to it. But it isn't the same as 'unsigned',
as the code fragment above demonstrates.
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      12-06-2005
Tim Rentsch <(E-Mail Removed)> writes:

> Ben Pfaff <(E-Mail Removed)> writes:
>
>> "Imre Palik" <(E-Mail Removed)> writes:
>>
>> > I thought the same way, until I had to to do some calculations with 24
>> > bit signed integers. I wouldn't do that without bit fields ...

>>
>> Bit-fields have the same type as another C language type, such as
>> signed int or unsigned int. I don't see how they would help with
>> 24-bit signed arithmetic, at least without involving undefined
>> behavior.

>
> If the operations being done don't overflow a 24 bit result, then
> signed bit-fields should work just fine. Operations that overflow
> would produce implementation defined or undefined behavior, but
> overflow when using signed operands is undefined behavior in
> any case.


But what is the benefit of a 24-bit signed integer bit-field over
a wider non-bit-field type, for the purpose of making
calculations with 24-bit signed integers? Imre seems to be
saying that there is some advantage, but I don't see it.

> A 24 bit signed bit-field should behave just as nicely as a 24
> bit signed integer type that's a built in integer type (as long
> as you don't want to have a pointer to it, make an array of
> them, etc).


Pretty big caveats, in my opinion.

> struct { unsigned u; unsigned b:1; } s = { 1, 1 };
>
> if( (s.u << 31) > 0 ) printf( "foo" );
> if( (s.b << 31) > 0 ) printf( "bas" );
> printf( "\n" );


It took me a minute to understand what was going on there. Thank
you for the enlightening example.
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      12-08-2005
Ben Pfaff <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>
> > Ben Pfaff <(E-Mail Removed)> writes:
> >
> >> "Imre Palik" <(E-Mail Removed)> writes:
> >>
> >> > I thought the same way, until I had to to do some calculations with 24
> >> > bit signed integers. I wouldn't do that without bit fields ...
> >>
> >> Bit-fields have the same type as another C language type, such as
> >> signed int or unsigned int. I don't see how they would help with
> >> 24-bit signed arithmetic, at least without involving undefined
> >> behavior.

> >
> > If the operations being done don't overflow a 24 bit result, then
> > signed bit-fields should work just fine. Operations that overflow
> > would produce implementation defined or undefined behavior, but
> > overflow when using signed operands is undefined behavior in
> > any case.

>
> But what is the benefit of a 24-bit signed integer bit-field over
> a wider non-bit-field type, for the purpose of making
> calculations with 24-bit signed integers? Imre seems to be
> saying that there is some advantage, but I don't see it.


Of course I can only speculate about what he was thinking, but here's
my guess. He's working on a platform (or platforms) that use two's
complement and where the implementation defines conversion to a signed
integer type to take just the low order bits (ie, when the value is
out of range). Now his 24-bit type will wrap around the way most
two's complement machines actually do. The advantage is he can use
normal assignment, etc, and not have to write '&0xFFFFFF' all over
the place. Maybe that isn't much of an advantage, but it's something.


> > A 24 bit signed bit-field should behave just as nicely as a 24
> > bit signed integer type that's a built in integer type (as long
> > as you don't want to have a pointer to it, make an array of
> > them, etc).

>
> Pretty big caveats, in my opinion.


It's noticeable, for sure. With a syntactic inconvenience these
limitations can be gotten around, eg,

typedef struct { signed v:24; } int_24;

int_24 things[20];

for( i = 0; i < 20; i++ ) things[i].v = 0;

Using .v or ->v is less onerous than doing explicit masking. More
important, the knowledge that elements of 'things' hold a 24-bit
datatype is localized rather than having to be repeated throughout the
code.


> > struct { unsigned u; unsigned b:1; } s = { 1, 1 };
> >
> > if( (s.u << 31) > 0 ) printf( "foo" );
> > if( (s.b << 31) > 0 ) printf( "bas" );
> > printf( "\n" );

>
> It took me a minute to understand what was going on there. Thank
> you for the enlightening example.


You're welcome. I wasn't meaning to be cryptic, although the point is
a bit understated. If the shift amount were changed from 31 to 15
this code fragment might make a good C interview/test question.
 
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: Advanced Python Programming Oxford Lectures [was: Re: *Advanced*Python book?] Michele Simionato Python 1 03-27-2010 06:10 AM
Centon Advanced A2X512S4400HB 1GB Dual Channel Kit @ Insa... Silverstrand Front Page News 0 10-24-2005 01:45 PM
Centon Advanced A2X512S4000LLU 1GB Dual Channel Kit Silverstrand Front Page News 0 10-21-2005 01:32 PM
Antec P180 Advanced Super Mid Tower @ ThinkComputers.org Silverstrand Front Page News 0 10-14-2005 12:53 AM
Centon Advanced GEMiNi PC3200 Dual-Channel Kit Silverstrand Front Page News 0 08-08-2005 09:25 PM



Advertisments