Maybe start with the program where each club sends the ball a fixed distance.
Or maybe start with the program which only has one club.
Break it down into manageable tasks, or simpler versions of the tasks, then refine the program as you go along. You don't have to write the whole thing in one sitting to do that.
> 1010.1010 Well to the left of the radix point, it's 1, 2, 4, 8 (2^0, 2^1, 2^2, 2^3 etc) To the right, it's 1/2, 1/4, 1/8, 1/16 (2^-1, 2^-2, 2^-3, 2^-4 etc)
All you need is a record of the total, and a record of the smallest. When you're done, subtract the smallest from the total, and calculate the average. No arrays necessary.
> will someone point me the reasons why a call to malloc fails even if we have enough memory ? My guess is you're still using crusty old TurboC which is limited to 640K no matter how many GB of memory you have on your pentium powered, XP hosted machine.
"Hello, yes I'd like to buy a Ferrari please" "Certainly sir, will you be wanting to replace the engine with an elastic band?"
student *select(student *k) {
int a;
printf("\n enter chosen");
scanf("%d",&a);
student *t=null; /*!! slipping into C++ mode here */
t=k;
while(k!=null) {
if((k->gpa)>a) /*!! braces here would really make your meaning clear */
printf("\n (%d %s %f ",k->id,k->name,k->gpa);
} /*!! I think this brace is in the wrong place */
/*!! That is, you want to step the list INSIDE the loop */
k=k->link;
/*!! You're supposed to return a student* here */
/*!! but you just fall off the end of the function with nothing */
}
See, already I've spotting that one of your linked list routines will lock up simply by reformatting the code to indicate the flow of the program. And that's just one I picked at random.
This simple act of clearing up your code will no doubt throw up a lot of similar problems.
First off, there is little in your code which cannot be compiled with a C compiler, so the first question is, are you learning C or C++. I'm assuming that the .cpp extension to your filename is you just taking whatever the IDE prompts you with.
> How do you clean out the contents of an array after you take input? The problem goes away (or more precisely, never arises) if you use fgets() to read all input, then use sscanf() / strcpy() / strxxx or whatever to extract information from the line returned by fgets().
By using scanf(), you upset the whole input stream, and have to resort to all sorts of bizarre ways of getting out of the hole you just dug for yourself - a hole which simply didn't need to be dug in the first place.
> Why does the following program work correctly There is a big difference between "produces expected output" and "works correctly". Your program is not correct, even though it seems to pass the "works for me" test.
When run with some diagnostic software, I get
$ valgrind ./a.out
==20047== Memcheck, a memory error detector for x86-linux.
==20047== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==20047== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==20047== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==20047== For more details, rerun with: -v
==20047==
==20047== Invalid write of size 4
==20047== at 0x804838F: main (in ./a.out)
==20047== Address 0x52BFE7E4 is just below %esp. Possibly a bug in GCC/G++
==20047== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes
20 30==20047==
==20047== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 1)
==20047== malloc/free: in use at exit: 0 bytes in 0 blocks.
==20047== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==20047== For counts of detected errors, rerun with: -v
==20047== No malloc'd blocks -- no leaks are possible.
For your example, adding more code will no doubt show up all manner of weird problems, most likely close to a deadline.
> The problem I'm having is that when I use the function strstr() in a while loop, the console hangs Well you don't advance the pointer, so it always begins the search from the same point, always finds the same match, and so on on on on .....
while ( (p=strstr(p,"thing")) != NULL ) {
// do something
// start search from just past the previous hit
p++;
}
> gets(array); NEVER use gets() to read input, there is no way to make it safe. Always use fgets().
> char string; This should really be a local variable in some function. Whether it's in main, and passed as a parameter to your function, or as a local within your function is up to you.
> while (*ptr != '\0') This loop doesn't seem to append the \0 to the string you create.
> #include <iostream.h> These are old-style headers. New C++ compilers should support #include <iostream> using namespace std; // so we can do cout rather than std::cout
> #include <math.h> The way to include a 'C' header in new C++ is to prefix the name of the header with a 'c', so #include <cmath>
> void main() main returns an int.
> a[j][count] -= (ratio * matrix[count]); As far as I can tell, matrix is uninitialised at this point, so you just introduce garbage into your calculations.
Well that seems to be OK in itself. Perhaps the problem is with the way you create the queue in the first place, and this is just where you notice that it doesn't work.
Perhaps you tried to use ^ as "raise to power" and got some very weird answers. What you need to realise is that you need to call the pow() function in math.h, because ^ is the bitwise-xor operator.
> { if (schedule == true) > { strcpy(schedule, "Booked"); The strcpy() makes no sense - schedule is an array of bool, not a string. Does your compiler even warn you about this? Or do you just ignore all warnings and just try it anyway?
> i got 2 errors n 1 warning on here so far after i compiled it So post those as well. It's even better if you comment the code you post indicating which lines are causing you problems.
> void displayCalendar(unsigned month, unsigned year, int* daysOfMonth[]) The simplest rule is to simply copy/paste the declaration of the array you want to pass, so it would be void displayCalendar(unsigned month, unsigned year, int daysOfMonth[]) Calling the function, you just use the array name, so instead of displayCalendar(month, year, daysOfMonth[]); It would be displayCalendar(month, year, daysOfMonth);
> already searched the web, but no luck so far So, is this a homework exercise in seeing who has the best google skills, or some attempt to weed out the lazy wannabe's (aka you) from someone far more interested and capable in programming?
If you're not even going to post an attempt (which we will gladly help you with), then why are you even bothering to take the course?
> while ( 0 == isOpen) Cute trick. Will you remember the == when you're comparing two variables?
The problem is, the compiler doesn't see your sneaky way of changing the variable, so it just assumes that isOpen is constant since you don't change it inside the loop. So it gets loaded ONCE when the loop enters for the first time (when it's probably still 0), and thereafter is is never read again.
To fix this, you need to indicate that the variable may change at any time, you do this with
volatile int isOpen = 0;
> op = (open_parameters*) malloc( sizeof ( open_parameters ) ); > op = (open_parameters*) open_para; This is a memory leak, there was no need to malloc anything at all. Also, since you're writing in C, the cast is unnecessary, so it's simply op = open_para; But I guess you're compiling your C code with a C++ compiler anyway, so I'll save you the trouble of moaning about the cast being necessary and just tell you to figure out how to compile for the language you're writing in.
> But, I didn't need to add a null pointer to the end of the string. It works anyways. 1. It's a NUL char, not a NULL pointer. 2. Yes, you do need to add it, otherwise you're relying on the buffer being initialised (which it isn't). On the other hand, you could be sending the \0 (either by accident or by design).
Wanna see? Try
memset( buffer, 0xff, sizeof(buffer); /* very specific non-zero fill */
sr = recv(acc, buffer, sizeof(buffer)-1, 0);
cout << "sr = " << sr << "\n";
buffStr = buffer;
> The output of sr is 1, which is not the size of the buffer Who said it would be? The size you pass is "don't go past this many characters", not "please hang around until you fill the buffer". You got 1 character, so copy it to somewhere else, and call recv() again. Keep calling it until you have all your data.
> int sr = recv(acc, buffer, sizeof(buffer), 0); 1. recv doesn't store a \0 on the end to make it a proper string 2. You need to leave room to store the \0 yourself 3. You need to code for the possibility that recv() doesn't receive the whole message in one go (if this is a TCP connection)
int sr = recv(acc, buffer, sizeof(buffer)-1, 0);
if ( sr > 0 ) {
buffer[sr] = '\0'; /* make it a string */
/* now you can do str... operations on buff */
}
Perhaps it's more to do with entering more than 80 characters rather than the number of words.
How does getline for example know how many characters to input, and not overflow the buffer? According to my info, the 2nd parameter is a length, not a char to stop at.
Well did you open the file for output in binary mode? Did you check the sizes of the file on the two different systems was the same? Have you copied a file generated on your Linux box to the windows box, and tried to play that?
http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf Read this and understand how all floats are approximations, which means no matter what you do, you invariably end up with ab.cd0000001 or ab.cc999999 type numbers as being the nearest representable value to ab.cd
Using floats for storing money is a really bad idea.
