Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Dharaskar's C questions ???

Reply
Thread Tools

Dharaskar's C questions ???

 
 
CBFalconer
Guest
Posts: n/a
 
      11-17-2007
Keith Thompson wrote:
>

.... snip ...
>
> In any case, "register" is treated as a special restricted version
> of "auto". The language easily *could* have supported "register"
> for static objects, but apparently it was thought that there's not
> much point in doing so. The cost would be addition complication
> for the compiler (assuming it's not just ignored); the benefit
> would be insignificant.


What you can count on is that the 'register' variable cannot have
its address taken.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
 
 
 
aarklon@gmail.com
Guest
Posts: n/a
 
      11-17-2007
On Nov 16, 3:18 am, Keith Thompson <(E-Mail Removed)> wrote:
> > 6) how correct is the usage of continue statement
> > instead of break statement in a switch.
> > I have heard that continue statement should be used only
> > within loops.

>
> "continue" applies to the innermost enclosing loop; it doesn't apply to switch statements.


but i have seen a program like this:-

#include<stdio.h>

int main(void)
{
int i,cho;

for(i=1;i<=3;i++)
{
printf("%d. Enter your choice between 1 to 5:",i);
scanf("%d",&cho);

switch(cho)
{

case 1:
printf("case 1\n");
continue;

case 2:
printf("case 2\n");
break;

case 3:
printf("case 3\n");
continue;
}
}

return(EXIT_SUCCESS);
}

and the o/p is given as

1. Enter your choice between 1 to 5: 1
case 1
2.Enter your choice between 1 to 5: 2
case 2
3.Enter your choice between 1 to 5: 3
case 3

 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      11-17-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On Nov 16, 3:18 am, Keith Thompson <(E-Mail Removed)> wrote:
>>> 6) how correct is the usage of continue statement
>>> instead of break statement in a switch.
>>> I have heard that continue statement should be used only
>>> within loops.

>> "continue" applies to the innermost enclosing loop; it doesn't apply to switch statements.

>
> but i have seen a program like this:-
>
> #include<stdio.h>
>
> int main(void)
> {
> int i,cho;
>
> for(i=1;i<=3;i++)
> {
> printf("%d. Enter your choice between 1 to 5:",i);
> scanf("%d",&cho);
>
> switch(cho)
> {
>
> case 1:
> printf("case 1\n");
> continue;
>
> case 2:
> printf("case 2\n");
> break;
>
> case 3:
> printf("case 3\n");
> continue;
> }


Those continue statements refer to the for loop, not the switch. An easy
way to demonstrate this is to insert the following code:

printf("Loop end\n");

The modified program will print "Loop end" only if cho is something
other than 1 or 3.

> }
>
> return(EXIT_SUCCESS);
> }

 
Reply With Quote
 
J. J. Farrell
Guest
Posts: n/a
 
      11-18-2007
(E-Mail Removed) wrote:
> On Nov 16, 3:18 am, Keith Thompson <(E-Mail Removed)> wrote:
>>> 6) how correct is the usage of continue statement
>>> instead of break statement in a switch.
>>> I have heard that continue statement should be used only
>>> within loops.

>> "continue" applies to the innermost enclosing loop; it doesn't apply to switch statements.

>
> but i have seen a program like this:-
>
> #include<stdio.h>
>
> int main(void)
> {
> int i,cho;
>
> for(i=1;i<=3;i++)
> {
> printf("%d. Enter your choice between 1 to 5:",i);
> scanf("%d",&cho);
>
> switch(cho)
> {
>
> case 1:
> printf("case 1\n");
> continue;
>
> case 2:
> printf("case 2\n");
> break;
>
> case 3:
> printf("case 3\n");
> continue;
> }
> }
>
> return(EXIT_SUCCESS);
> }
>
> and the o/p is given as
>
> 1. Enter your choice between 1 to 5: 1
> case 1
> 2.Enter your choice between 1 to 5: 2
> case 2
> 3.Enter your choice between 1 to 5: 3
> case 3


Why do you say "but"? Think about Keith's explanation and how it applies
in this case. You'll see that in this particular case the effects of
'break' and 'continue' are identical.
 
Reply With Quote
 
Charlie Gordon
Guest
Posts: n/a
 
      11-22-2007
"Keith Thompson" <(E-Mail Removed)> a écrit dans le message de news:
fhl719$vfi$(E-Mail Removed)...
> Keith Thompson wrote:
>> (E-Mail Removed) wrote:

> [...]
>>> 3) why a global declaration such as register int i; is not
>>> allowed.

>>
>> Because the standard says so.
>>
>> The original rationale, I suspect, is that tying up a CPU register (often
>> a very scarce resource) for the entire lifetime of a program is
>> undesirable. (On the other hand, declaring a register variable in main()
>> does the same thing.)
>>
>> But in standard C, the "register" keyword doesn't necessarily mean that
>> the variable is stored in a CPU register.

>
> In a followup that hasn't yet shown up on aioe.org,
> Christopher Benson-Manica <(E-Mail Removed)> writes:
> | Given that it's an ignorable suggestion rather than a command, I would
> | think that there might be some other explanation for disallowing the
> | construct.
>
> The "register" keyword existed long before C was formally standardized. I
> suspect that when it was first implemented, it wasn't considered to be
> merely a suggestion; rather, it probably *required* the compiler to store
> the specified variable in a register. In that context, not supporting
> "register" for static objects probably made sense.
>
> In any case, "register" is treated as a special restricted version of
> "auto". The language easily *could* have supported "register" for static
> objects, but apparently it was thought that there's not much point in
> doing so. The cost would be addition complication for the compiler
> (assuming it's not just ignored); the benefit would be insignificant.
>
> Not every feature that can be provided should be provided.


gcc supports global register variables as a processor specific extension.
I remember using one once for an interpreter core, to hold a pointer to the
interpreter state across function calls. It provided noticeable performance
improvements, but I would not advise beginners to mess with stuff like that,
especially with more modern processors, with more registers and more
parameters passed in registers.

--
Chqrlie.


 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      11-25-2007
On Thu, 15 Nov 2007 10:49:11 -0800 (PST), (E-Mail Removed) wrote:

> register int i;
> volatile int j;
> auto int k;
>
> time_t s1, s2, s3, e1, e2, e3;
>
> s1 = clock ();
> for (i = 1; i <= 32000; i++)
> e1 = clock ();
> printf ("\n The time in seconds for register variable is %g\n",
> difftime (e1, s1) / CLOCKS_PER_SEC);
>

As already noted, this loop should have an empty body and the second
clock() call should follow it for consistency with the other cases;
and all the clock() values should be clock_t not time_t.

Also (and related) difftime() is used to difference two time() values
(as type time_t) which need not be linear. It is not needed and in
general not appropriate for differencing clock() values, which ARE
required to be linear (except for wraparound). However, on most
systems time_t is linear so difftime() is just subtraction and clock_t
does not have a greater range than time_t so this accidentally works.

But:

> The time in seconds for register variable is 0.02
>
> The time in seconds for volatile variable is 0.01
>
> The time in seconds for auto variable is 0
>
> does this mean that accessing register variables is a slow
> operation...???
>

Your measurements are so close to the likely clock() granularity that
the signal, if any, is lost in the noise. Moreover, your trivial loops
easily could be optimized away, making this meaningless.

The basic answer, like most questions of performance in C, is that it
is not defined by the standard and depends on the implementation(s)
you are using, which in turn usually depend on the underlying machine.
Either do valid measurements -- which need to be repeated several
times, on systems (hardware and software) which are both controlled
and varied in known ways; or look at the compiled code (assuming your
implementation is indeed a compiler as essentially all are) together
with an understanding of the machine that will execute it and that
machine's performance for different instructions and memory accesses
-- which itself is often very complex and even nondeterministic on
many modern machines.

Or stop and think instead: if e.g. you spend days of your time, and
perhaps that of several colleages, to save one thousandth of a second
when the program runs, in order to 'break even' purely in time terms,
your program must be run a thousand times by a million users, or once
by a billion users -- and before Moore's Law reduces the amount of
saving to a negligible value, say within 5 years. Is that likely?

<snip other>
- formerly david.thompson1 || achar(64) || worldnet.att.net
 
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
Few Questions (HW questions already answered by me) padh.ayo@gmail.com C Programming 10 12-06-2006 05:48 PM
Malloc and free questions - learner questions pkirk25 C Programming 50 10-04-2006 02:22 PM
Questions on Canon 300D and etc. questions regarding digital photography Progressiveabsolution Digital Photography 12 03-24-2005 05:18 PM
Newbie questions - Couple of VC++ questions regarding dlls and VB6 Ali Syed C Programming 3 10-13-2004 10:15 PM
Re: Questions....questions....questions Patrick Michael A+ Certification 0 06-16-2004 04:53 PM



Advertisments