Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Impossible question?

Reply
Thread Tools

Impossible question?

 
 
shane
Guest
Posts: n/a
 
      10-04-2010
Hi/

Been given this question, doesn't seem to make sense as it requires
function overloading:

Write a utility module that contains the following functions:
a) int getint(char *prompt)
Prompts the user then reads in an integer and returns the value
through the return value of the function (Copy the function from <foo>)
b) int getint(char *prompt, int max, int min, int *num)
as for the previous function, except it must check whether the
integer is in the given range (inclusive).

Obviously this requires function overloading, which is not supported in
C (C++ does apparently). And I get this output:

************************************
util.h:12: conflicting types for `getint'
util.h:11: previous declaration of `getint'
util.c:16: conflicting types for `getint'
util.h:12: previous declaration of `getint'
util.c:25: conflicting types for `getint'
util.c:16: previous declaration of `getint'
************************************

Am I missing something, or has my lecturer set an impossible question?
Can there be a VarArgs solution, only thing I can think of?
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      10-04-2010
On 10/ 5/10 12:11 PM, shane wrote:
> Hi/
>
> Been given this question, doesn't seem to make sense as it requires
> function overloading:
>
> Write a utility module that contains the following functions:
> a) int getint(char *prompt)
> Prompts the user then reads in an integer and returns the value
> through the return value of the function (Copy the function from<foo>)
> b) int getint(char *prompt, int max, int min, int *num)
> as for the previous function, except it must check whether the
> integer is in the given range (inclusive).
>
> Obviously this requires function overloading, which is not supported in
> C (C++ does apparently). And I get this output:
>

<snip>
>
> Am I missing something, or has my lecturer set an impossible question?
> Can there be a VarArgs solution, only thing I can think of?


Are you being asked to include both in the same executable, or can you
provide two programmes?

--
Ian Collins
 
Reply With Quote
 
 
 
 
Seebs
Guest
Posts: n/a
 
      10-05-2010
On 2010-10-04, shane <(E-Mail Removed)> wrote:
> Been given this question, doesn't seem to make sense as it requires
> function overloading:


Yup. Your lecturer is a twit and doesn't know that C and C++ are
different languages.

Although! You can actually do it, sort of:

> Write a utility module that contains the following functions:

#ifndef FANCY_GETINT
> a) int getint(char *prompt)

#else
> b) int getint(char *prompt, int max, int min, int *num)

#endif

> Am I missing something, or has my lecturer set an impossible question?
> Can there be a VarArgs solution, only thing I can think of?


No, because there's nothing about prompt to tell you whether there are
additional arguments incoming.

Your lecturer is not aware that his "C" compiler is actually compiling
C++. Get ready for an exciting ride of trying to figure out what mistaken
assumptions are hidden in each assignment.

There is a plus side to this: You will be well prepared for the exciting
world of specifications written by marketing.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      10-05-2010
On October 4, 2010 19:11, in comp.lang.c, (E-Mail Removed) wrote:

> Hi/
>
> Been given this question, doesn't seem to make sense as it requires
> function overloading:


Not really. It /can/ be done without function overloading, in C, with a
minor change to the function prototype. Perhaps your instructor wasn't
providing multiple prototypes for the function (implying function
overloading), but instead was giving examples of the variety of calls that
the hypothetical function would accept.

Think of how printf() can be called as
a) int printf(char *string);
or
b) int printf(char *string, int value);

Does this imply function overloading for printf() to work?

> Write a utility module that contains the following functions:
> a) int getint(char *prompt)
> Prompts the user then reads in an integer and returns the value
> through the return value of the function (Copy the function from <foo>)
> b) int getint(char *prompt, int max, int min, int *num)
> as for the previous function, except it must check whether the
> integer is in the given range (inclusive).
>
> Obviously this requires function overloading, which is not supported in
> C (C++ does apparently). And I get this output:

[snip]
> Am I missing something, or has my lecturer set an impossible question?
> Can there be a VarArgs solution, only thing I can think of?


Assume the function prototype of...

int getint(char *prompt, ...);

Then, with suitable cues in the prompt string, the implementation of
getint() could discern whether or not additional arguments (int max, int
min, int *num) were to be utilized or not.

Of course, this would require the use of varargs within the implementation
of getint(), and the instructor's instructions would have to be interpreted
as /examples of use/ rather than as function prototypes, but it /could/ be
done with standard C.

--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-05-2010
Lew Pitcher <(E-Mail Removed)> writes:
> On October 4, 2010 19:11, in comp.lang.c, (E-Mail Removed) wrote:
>> Been given this question, doesn't seem to make sense as it requires
>> function overloading:

>
> Not really. It /can/ be done without function overloading, in C, with a
> minor change to the function prototype. Perhaps your instructor wasn't
> providing multiple prototypes for the function (implying function
> overloading), but instead was giving examples of the variety of calls that
> the hypothetical function would accept.
>
> Think of how printf() can be called as
> a) int printf(char *string);
> or
> b) int printf(char *string, int value);
>
> Does this imply function overloading for printf() to work?


No. And strictly speaking, those are declarations, not calls,
and both of them are incompatible with the actual printf().
I guess the point is that one call could be consistent with the
first declaration, and another with the second; both are compatible
with the actual declaration of printf().

>> Write a utility module that contains the following functions:
>> a) int getint(char *prompt)
>> Prompts the user then reads in an integer and returns the value
>> through the return value of the function (Copy the function from <foo>)
>> b) int getint(char *prompt, int max, int min, int *num)
>> as for the previous function, except it must check whether the
>> integer is in the given range (inclusive).
>>
>> Obviously this requires function overloading, which is not supported in
>> C (C++ does apparently). And I get this output:

> [snip]
>> Am I missing something, or has my lecturer set an impossible question?
>> Can there be a VarArgs solution, only thing I can think of?

>
> Assume the function prototype of...
>
> int getint(char *prompt, ...);
>
> Then, with suitable cues in the prompt string, the implementation of
> getint() could discern whether or not additional arguments (int max, int
> min, int *num) were to be utilized or not.


But I don't think the problem description permits using the value of
``prompt'' to control whether it looks for other arguments.

The most likely explanation is that the instructor is overlooking the
difference between C and C++, or was just sloppy with the names.

> Of course, this would require the use of varargs within the implementation
> of getint(), and the instructor's instructions would have to be interpreted
> as /examples of use/ rather than as function prototypes, but it /could/ be
> done with standard C.


Given an assignment to write a function "int getint(char *prompt)",
I don't think it's reasonable to assume that that's anything other
than the declaration of the function. And if you're free to change
the declaration, you might as well change the name.

Incidentally, <varargs.h> is an obsolete header used in pre-ANSI C
to implement variadic functions. The modern (since 1989) version
is <stdarg.h>. I know you said "varargs", not "varargs.h", but it
doesn't hurt to clarify.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
shane
Guest
Posts: n/a
 
      10-05-2010
Lew Pitcher writes:
>> Write a utility module that contains the following functions:
>> a) int getint(char *prompt)
>> Prompts the user then reads in an integer and returns the value
>> through the return value of the function (Copy the function from <foo>)
>> b) int getint(char *prompt, int max, int min, int *num)
>> as for the previous function, except it must check whether the
>> integer is in the given range (inclusive).
>>
>> Obviously this requires function overloading, which is not supported in
>> C (C++ does apparently). And I get this output:

> [snip]
>> Am I missing something, or has my lecturer set an impossible question?
>> Can there be a VarArgs solution, only thing I can think of?

>
> Assume the function prototype of...
>
> int getint(char *prompt, ...);
>
> Then, with suitable cues in the prompt string, the implementation of
> getint() could discern whether or not additional arguments (int max, int
> min, int *num) were to be utilized or not.


Got it, I can put information about the form to use after the NULL
terminator in the prompt!

Here is my full solution.

#include "stdio.h"
#include "strings.h"
#include "stdarg.h"

int getint(char *prompt,...)
{
int i=strlen(prompt),j;
va_list k;
char s[20];
printf(prompt);
gets(s);
j=atoi(s);
switch(*(prompt+ ++i)) {
case 0:
return j;
default:
va_start(k,prompt);
if(j<=va_arg(k,int) && j>=va_arg(k,int)) return *(va_arg(k,int*))=j;
printf("out-of-range error aborting");
abort();
}
}

int main()
{
int i;
char p1[]="enter a number::",p2[]="enter a number in 1 to 10::";
p1[15]=p1[16]=p2[26]=0;p2[27]=1;
printf("you entered %d\n",getint(p1));
getint(p2,10,1,&i);
printf("you entered %d\n",i);
}
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-05-2010
shane <(E-Mail Removed)> writes:
> Lew Pitcher writes:
>>> Write a utility module that contains the following functions:
>>> a) int getint(char *prompt)
>>> Prompts the user then reads in an integer and returns the value
>>> through the return value of the function (Copy the function from <foo>)
>>> b) int getint(char *prompt, int max, int min, int *num)
>>> as for the previous function, except it must check whether the
>>> integer is in the given range (inclusive).
>>>
>>> Obviously this requires function overloading, which is not supported in
>>> C (C++ does apparently). And I get this output:

>> [snip]
>>> Am I missing something, or has my lecturer set an impossible question?
>>> Can there be a VarArgs solution, only thing I can think of?

>>
>> Assume the function prototype of...
>>
>> int getint(char *prompt, ...);
>>
>> Then, with suitable cues in the prompt string, the implementation of
>> getint() could discern whether or not additional arguments (int max, int
>> min, int *num) were to be utilized or not.

>
> Got it, I can put information about the form to use after the NULL
> terminator in the prompt!


NULL is a null pointer constant, not a null character. You mean "null
terminator", or perhaps "NUL terminator", or even "'\0' terminator".

But it seems vanishingly unlikely that your instructor really had this
kind of trick in mind.

> Here is my full solution.
>
> #include "stdio.h"
> #include "strings.h"
> #include "stdarg.h"


Use angle brackets, not quotation marks, for standard headers:

#include <stdio.h>
#include <strings.h>
#include <stdarg.h>

> int getint(char *prompt,...)
> {
> int i=strlen(prompt),j;
> va_list k;
> char s[20];
> printf(prompt);
> gets(s);


Never use gets(). It cannot be used safely.

[...]

> char p1[]="enter a number::",p2[]="enter a number in 1 to 10::";
> p1[15]=p1[16]=p2[26]=0;p2[27]=1;


Trying for the IOCCC?

[...]

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-05-2010
shane <(E-Mail Removed)> writes:
<snip>
> Got it, I can put information about the form to use after the NULL
> terminator in the prompt!


That's too horrid an interface to used in practise but I suppose you've
decided to take the instructions literally. BTW, is it possible there's
been some miss-interpretation on your part?

If I had to do it this way, I'd encode the information in the visible
part of the string -- maybe by requiring that the range be signalled by,
say, %R in the prompt. The function would then print a prompt where the
%R was replaced by required range making it simple to inform the user of
the required input range. Whilst still far from perfect this would at
least get some benefit from the convoluted interface (and the prompt can
be a literal string).

> Here is my full solution.
>
> #include "stdio.h"
> #include "strings.h"
> #include "stdarg.h"


Using <>s for standard headers is much safer.

> int getint(char *prompt,...)
> {
> int i=strlen(prompt),j;
> va_list k;
> char s[20];
> printf(prompt);


What happens if the prompt has a % in it? What happens if it has
(accidentally or deliberately) %s in it?

> gets(s);


Eek! Use fgets and stay safe. Alternatively use scanf("%d", &j) though
that does not behave in exactly the same way.

> j=atoi(s);


The strtol functions is better in that atoi does not handle errors at
all well. Since one form of this function can report errors, it seems a
shame not to include input format errors in that.

> switch(*(prompt+ ++i)) {


Surely prompt[i + 1] is clearer here? While on the subject, i, j and k
and not particularly helpful names.

> case 0:
> return j;
> default:
> va_start(k,prompt);
> if(j<=va_arg(k,int) && j>=va_arg(k,int)) return *(va_arg(k,int*))=j;
> printf("out-of-range error aborting");
> abort();


Every va_start much have a matching va_end call in the same function.
Also, isn't abort() rather too drastic an action for an input utility
function to take when the input is not in the desired range? For one
thing, the error message may not even appear. Adding a \n at the end
will help some but is not really enough (you have flush and streams you
really want flushed when calling abort). Finally, errors are
traditionally sent to stderr rather that stdout.

> }
> }
>
> int main()
> {
> int i;
> char p1[]="enter a number::",p2[]="enter a number in 1 to 10::";
> p1[15]=p1[16]=p2[26]=0;p2[27]=1;
> printf("you entered %d\n",getint(p1));
> getint(p2,10,1,&i);
> printf("you entered %d\n",i);
> }


What happened to all the spaces!

--
Ben.
 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      10-05-2010
On October 5, 2010 13:15, in comp.lang.c, (E-Mail Removed) wrote:

> Lew Pitcher <(E-Mail Removed)> writes:
>> On October 4, 2010 19:11, in comp.lang.c, (E-Mail Removed) wrote:
>>> Been given this question, doesn't seem to make sense as it requires
>>> function overloading:

>>
>> Not really. It /can/ be done without function overloading, in C, with a
>> minor change to the function prototype. Perhaps your instructor wasn't
>> providing multiple prototypes for the function (implying function
>> overloading), but instead was giving examples of the variety of calls
>> that the hypothetical function would accept.

[snip]
> The most likely explanation is that the instructor is overlooking the
> difference between C and C++, or was just sloppy with the names.


Could be.

My post was coloured by my experience as a developer. If someone came to me
at work and asked for a function that accepted one or five arguments as the
caller preferred, I would have answered "varargs"

>> Of course, this would require the use of varargs within the
>> implementation of getint(), and the instructor's instructions would have
>> to be interpreted as /examples of use/ rather than as function
>> prototypes, but it /could/ be done with standard C.

>
> Given an assignment to write a function "int getint(char *prompt)",
> I don't think it's reasonable to assume that that's anything other
> than the declaration of the function. And if you're free to change
> the declaration, you might as well change the name.


Again, I approached this as I would have approached a problem at work.
Perhaps the OP's instructor "misspoke" and wanted a C++ solution, or
perhaps the OP "misunderstood" the requirements. We won't really know.

If the OP wanted a C++ overloaded function, then the OP's question shouldn't
have been asked here in comp.lang.c. And /any/ C solution we lead the OP to
will be wrong.

ISTM that we don't have sufficient information to correctly determine the
instructor's purpose and/or target solution to this problem. In that case,
IMHO, it is just as correct to suggest that the problem statement is poorly
presented, and that (with suitable interpretation of the problem
statement), a C "varargs" solution exists as it is to suggest that the
problem statement is poorly written, and that (with suitable interpretation
of the problem statement), a C++ "function overloading" solution exists.

But, that's just my opinion.

> Incidentally, <varargs.h> is an obsolete header used in pre-ANSI C
> to implement variadic functions. The modern (since 1989) version
> is <stdarg.h>. I know you said "varargs", not "varargs.h", but it
> doesn't hurt to clarify.


True.

I was referring to the concept, not the implementation. I should have been
clearer.


As for the OP's later posting of a "varargs" C solution, I'll just respond
with my own attempt. Note that the code is far from robust (the problem
statement doesn't give enough info to include some features that I'd like,
and, as a demo program, I've left out features that I'd want in a "live"
program), but it works.

====================== start of program code =============================
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <limits.h>

#define SENTINAL ':'

int getint(char *prompt, ...)
{
int val, /* input value */
items, /* scanf() result */
max = INT_MAX, /* maximum value (defaulted) */
min = INT_MIN, /* minimum value (defaulted) */
*num= NULL; /* save result here (defaulted) */

if (*prompt == SENTINAL) /* getint(char *, int, int, int *) */
{
va_list ap;

/* get additional arguments */
va_start(ap, prompt);
max = va_arg(ap, int);
min = va_arg(ap, int);
num = va_arg(ap, int *);
va_end(ap);

++prompt; /* skip the sentinal - remainder is true prompt */
}

/* now, show the prompt and get the input */
do
{
printf("\n%s :",prompt); fflush(stdout);
if ((items = scanf("%d",&val)) == 0)
scanf("%*s"); /* discard bad input */
} while ((items == 0) || (val < min) || (val > max));

if (num) *num = val;
return val;
}

int main(void)
{
int value, othervalue;

value = getint("Please input a number");
printf("\n\ngetint() returned %d\n",value);

value = getint("lease input a number", 50, 5, &othervalue);
printf("\n\ngetint() returned %d, got %d\n",value, othervalue);

return EXIT_SUCCESS;
}

======================= end of program code ==============================

--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------


 
Reply With Quote
 
James Waldby
Guest
Posts: n/a
 
      10-06-2010
On Tue, 05 Oct 2010 19:27:38 -0400, Lew Pitcher wrote:
[snipalot]
....
> #define SENTINAL ':'

....
> if (*prompt == SENTINAL) /* getint(char *, int, int, int *) */

....
> ++prompt; /* skip the sentinal - remainder is true prompt */
> }

....

Perhaps you mean "sentinel"?

--
jiw
 
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
impossible to delete file because it is impossible to take ownership Devvie Nuis Computer Support 21 04-20-2009 02:07 AM
Making the simple impossible and the impossible unthinkable... xfx.publishing@gmail.com Perl Misc 5 06-30-2006 11:50 AM
WIN XPsp2 - WIN 98se wireless network file sharing impossible =?Utf-8?B?WW91dmVz?= Wireless Networking 1 01-18-2005 09:40 PM
070-221...impossible to pass MAX MCSE 9 12-18-2003 11:51 PM
Re: VPN (after Tunnel) connection impossible zak Cisco 0 10-10-2003 08:40 AM



Advertisments