Posts by Trentacle

What kind of image? PNG? Bitmap? Some other format?

I see what your problem is... but the advice I'm going to give is going to be more useful in the long run than telling you straight.

# after 'use strict'
use Data::Dumper;

# then in your code, when you want to see the contents of %seqs
warn Dumper(\%seqs);

Put the warn in your first while loop so you can see the hash being built.

Dumper is something you should know about, it's invaluable for debugging stuff like this.

It's only a practical configuration of your linux system. It doesn't prevent you from adding a shebang line if you want. I've been using this trick for some time now and it is very nice. Why not use all the tools that come with a linux system ?

Well, I could pretty easily install software and graphics to make my desktop look just like Windows 7, and with some dedication I could rename all the binaries to end in .exe, and then there's some trickery that I could use to make all my paths appear to start with C: and use backslashes instead of forward slashes, if I really wanted my Linux system to act like Windows... but I have no idea why I'd want that. Similarly, I don't want my Linux system to assume filetypes based on extensions, because that's one of the things that often frustrates me in Windows. But no, your way is good, too. ;)

@valorien: also read this as an alternative to the shebang line: http://www.daniweb.com/software-development/python/code/241988

This sounds like a bad idea. Non-portable, and it means all your Python scripts have to end in .py (and if by chance you were to have an actual binary end in .py you wouldn't be able to use it). Is there some problem with using a shebang line that this approach is trying to solve?

Basically there are two ways to do this, which your instructor probably is trying to get you to think about.

One, you can give the inventory variables "file scope" -- that is, declare them outside of and before your functions so that they'll be available in updatefile() as well as main() and whatever other functions might need them. This is the simplest solution and it doesn't involve passing any variables other than the file name. It has a few drawbacks you should be aware of, e.g. you couldn't easily extend the program to track the inventory of two or more players at once. It would be a poor solution for production code, but is probably fine for an assignment at your level (I'm guessing CS1).

Two, you can declare all your inventory variables inside main() and pass them as function parameters whenever they're needed. That means not only do you need to pass bees, infected, balance, honey, and beeswax to updatefile() (in addition to the file name), but you also need to pass money to buybees(), because that function needs to know how much money is in your inventory to do error checking. This is a little more complicated to implement, but it's more modular and easier to read (since the variable declaration is always close to its use). Depending on your grader, you might get higher marks for this solution than for the other, but it requires using pointers to change the value of money, which you …

Use code tags instead of quote tags to preserve formatting.

The code you've posted doesn't describe the structure you've said it does. => is just syntactic sugar for a comma, so $chainStorage->{ACB} is

{
    E => '06',
    [100, 200, 95] => 'B',
    '23' => [20, 1000, 5, 30],
}

Assuming you meant the following (formatting added)...

$chainStorage = {
    ACB => {
        E => { '06' => [100, 200, 95] },
        B => { '23' => [20, 1000, 5, 30] },
    },
    AFG => {
        C => { '24' => [18, 23, 2300, 3456] },
    },
    HJK => {
        A => { '12' => [24, 25, 3200, 5668] },
        D => { '15' => [168] },
    },
};

... then you still have kind of an odd situation because your tertiary (third-layer) hashes never have more than one key and one value. If that's always the case it'd probably be better to think of a different way to store them. You might, for instance, make the tertiary key the first element of the list, like this:

ACB => {
        E => ['06', 100, 200, 95],
        B => ['23', 20, 1000, 5, 30],
    },

Then use something like this to add the elements:

my $href = $chainStorage->{ACB};

my $sum = 0;
foreach my $aref (values %$href) {
        my @ary = @$aref;
        @ary = @ary[1..$#ary]; # I had to slice the first element back out
        $sum += $_ foreach (@ary);
}

If you can't restructure your data …

Can you be a little more explicit about the program requirements? Like, what should the file look like before and after updatefile() is called, in a sample run? The sample code you've written would overwrite anything already in the file, but you called it "update", so... I'm a little puzzled.

I can tell you right now, you don't need to pass it anything. Whether you should is a question of what will best fit the program requirements and make your code cleanest, and is ultimately up to you. You might want to at least pass the name of the file ("gamestat.txt").

#include<conio.h>
#include<graphics.h>
#include<dos.h>
void main()

I'm assuming those three headers provide all the undeclared identifiers in your code. Care to share with us where they come from?

main() returns int.

printf("Enter the weight in pounds> ");
scanf("%lf", &pounds);

Two notes here. First, there's no \n, so the implementation isn't obligated to print the prompt before waiting for input; use fflush(stdout) to make sure it works regardless. Second, check the return value of scanf() to make sure your zero is actually a zero.

return (0)

return doesn't require parens. They don't hurt anything, but I prefer to leave them off.

userRequest is local to getCommand, which means its memory disappears when control returns to main(). strtok() doesn't allocate new memory -- it just zero-terminates a token in the source string and returns a pointer to its first character. Therefore all the addresses in the parameters array are invalid when getCommand returns.

I would do something more like size_t getCommand(char *dest[], size_t size, char *source); so you can allocate the necessary memory in the caller and pass in a pointer to it. Implementation left as an exercise for the reader.

const-qualified variables aren't the same as constants.

int const i = 5;

5 is a constant. i is a variable that happens to be const-qualified, which means you can't modify it directly. Constants can never be modified, because at runtime they usually don't exist. const-qualified variables, well, it depends.

const is mostly a way of documenting variables that you intend not to modify. Consider

size_t strlen(const char *s);

The word const here indicates that the function strlen will not try to modify the referent of s (here an array of char).

An important thing to realize about const is that it's applied to variables, not objects. Observe:

int i = 0;
int *p = &i;
int const *q = &i;

Although p and q both refer to the same object, only p can safely be used to modify it. Any attempt to modify *q, which is const, causes undefined behavior (I think -- don't have my C99 at hand).

Furthermore, const-ness is not part of the value of an expression, but merely a property applied (at compile time) to certain names. The purpose of const is to allow the programmer to state his intent not to modify a certain variable within a certain scope, and for the compiler to assume that variable is not being modified, so that optimization can take place.

Your question about linkage is rather puzzling, because linkage is determined by the scope of the declaration and has nothing to …

I think the problem is that c=(a*a*a)-(a*a) crosses the limit of int values. U should instead use unsigned long.

Assuming 16-bit ints, that should only happen when a > 31, and the algorithm as given should work fine for c up to and including 28830. (With 32-bit ints, it will never overflow because a never exceeds 1000.)

The real problem I'm seeing, though, is that we've been told it "doesn't work" but haven't been given any further information.

In C99 (and GNU C, I think) the second declaration of a masks the first only for the scope of the for loop, as you said.

C89 syntax doesn't allow declarations to appear in the initializer of a for loop, so it's still invalid even if the initial declaration is removed.

#include"stdio.h"
#include"conio.h"
#include"math.h"
int main(void)
{
int a,b = 0;
int c=0;
printf("Please enter a number : ");
scanf("%d",&b);

for(a=0;a<1000;a++)
{  
   c=(a*a*a)-(a*a);
   if(b==c)
   { 
      printf("%d",a);
     }
}
getch();
}

For starters, get rid of that conio.h and getch() nonsense, and use angle brackets to surround standard header files, like this:

#include <stdio.h>

For another thing, if the user inputs "4", do you really need to check values of a all the way up to 1000?

And furthermore, if the user inputs "four", how do you tell the difference between that and zero?

Finally, you do realize that only a few numbers meet this requirement, right? [4, 18, 48, 100, 180, 294, 448, 648, 900] are the only positive integers below 1000 that can be expressed as the difference between the cube of a whole number and its square.

How does it not work?

But ungetc() is non-standard and therefore not recommended. It will not work in most compilers.

Standard section 7.19.7.11 (The ungetc function) begs to differ.

Try here.

I have plenty of projects of my own to do, thanks very much.

I could tell you how I would do it, but it smells like homework and something you should be working out on your own.

If you have specific problems, post complete, compilable code and ask specific questions.

mt = (mytype*)calloc(1, sizeof(mytype));

Better is

mt = calloc(1, sizeof *mt);

1) don't cast the result of malloc() (and friends), because all it does is hide a useful warning; and
2) sizeof *mt is shorter than sizeof(mytype) , and you don't have to change it if you later change the type of mt.

Other than that, yep, pretty much, just what gerard4143 said.

I have a personal vendetta against typedef, so I would eliminate that, too.

If you absolutely have to, use getchar(), which is declared in <stdio.h>. But if you take my advice, you'll just leave it off and run your program in such a way that you can read the output after the program has exited.

fflush(stdout) is necessary to make sure the prompt gets printed on systems that perform line buffering. Since you don't have a \n on the end of your prompt, it might not appear when you want it to, giving the impression that your program has hung when it's actually just waiting for input.

main returns int, not void.

Finally, since you don't check the return value of scanf(), you invoke undefined behavior when the user inputs non-numeric data. For a one-off program, it's not a big deal, but you should be in the habit of checking the return values of all standard library functions.

float prod() is not a prototype, it's merely a declaration. float prod(int, float) is a prototype.

As you have it declared, prod() returns int. You'll need to declare it otherwise in order to use it the way you want to.

Also, the usual: <conio.h> is obsolete and nonstandard, main returns int, use fflush(stdout) after printing a prompt without \n, don't use scanf() for interactive input, and your liberal use of whitespace is quite distracting.

There are really two answers to this question: 1) yes and 2) no.

Yes, because the cast in this case does no more than make an implicit conversion explicit. It is the same if you do float x = 12; -- you don't need to write float x = (float)12; because the conversion is done implicitly anyway (per C99 6.5.16.1p2 and 6.3.1.8). The cast is ugly and unnecessary.

No, because the statement p = 30000; (with or without a cast) invokes implementation-defined behavior. C99 6.3.2.3p5 states:

An integer may be converted to any pointer type. Except as previously specified [the previous clauses refer to the constant 0, which does have well-defined behavior when converted to a pointer], the result is implementation-defined, might not be correctly aligned, might not point to an entity of the referenced type, and might be a trap representation.

Pointers don't have to be integers; at least a few machines implement addresses as a segment+offset pair, and it's possible that more exotic implementations exist. Even on an implementation where pointers are integers, location 30000 might still not exist or point to something you can't modify (or that isn't even a memory location at all), causing your program to fail and potentially bringing your entire system down with it. Unless you know exactly 100% without a doubt what you are doing, don't mess around with that kind of thing.

(There is one exception to this rule. C99 introduces the intptr_t and uintptr_t …

to find the size of image by knowing the height and width....and by knowing the pixel depth...any solutions plz help.....

What do you mean by "size"? In what units do you intend to measure such a quantity?

"i researched about threading but it's too complicated for me"
Translation: "I don't feel like doing real work, can somebody pretty please solve my problem for me?"

Your first and most obvious error has been mentioned already. Since you haven't said otherwise, I'm assuming you fixed that error, and since you haven't kept complaining, I'm assuming that fixed your problem. If that's the case, could you mark this thread solved?

If you're still experiencing difficulties after fixing "maths.h", post the compiler output so we know where to start.

I'm not seeing any errors... compiles and runs fine, giving meaningful output. It's rather more verbose and less useful than `ls -F`, though. ;)

Do you want to change the way the output is printed?

I'd prototype main(), give some thought to the 20-character limit, and use fgets for user input if I were you. For another thing, you open the directory three times, and even open it in two places at once without calling closedir() -- probably not an issue, but asking for trouble all the same. See if you can work it down to a single call.

>void main() is not legal C (under a hosted environment).
Incorrect. Since you seem to be a standard reader, look it up and you'll see "or in some other implementation-defined manner". This is an escape clause that allows implementations to support extended functionality, such as not requiring a return value (ie. void main) or additional parameters such as the common envp third parameter.

Conceded. I should have said "not standard" rather than "not legal", as the standard allows, but does not dictate, this form.

Your three parameter version falls under the escape clause, though it is mentioned as a common extension in annex J section 5 of C99.

My careless mistake. In fact, I was trying to say (correctly) that the three parameter version was nonstandard, when I discovered it in the actual standard. I revised my post without paying attention to the context of its mention. Thank you for the correction.

If the main() takes 3 arguments i.e. int argc,char * argv[],char *env[] and SINCE C DOES NOT SUPPORT FUNCTION OVERLOADING ,y does the c compiler does not give error for simply

void main() //that is no arguments at all

OR

void main(int argc,char *argv[]) //2 arguments

There are two things wrong with your question. First, main() returns int. Always and for ever. void main() is not legal C (under a hosted environment). Your options are (under C99):

int main(void);
int main(int argc, char *argv[]);
int main(int argc, char *argv[], char *envp[]);

Also, int main() isn't a prototype, so it can refer to main no matter what parameters it takes. void main() does not imply no parameters at all, but merely that the number and type of parameters are not known.

As for the actual question, the answer is that there's no overloading going on for the simple reason that there's no conflict. A C program can have at most one definition of main(). The compiler will see which version you used and generate the appropriate code to initialize whatever parameters your program expects. This isn't overloading or anything like it.

Wait... are you trying to get the determinant of a square matrix?

1. open a pointer to a file
2. read the bytes till the end of file using fread()
3. close the pointer

I can do you one better:

1. Find a forum that discusses C++.
2. Don't append your question to a 4.5 year old thread.
3. Do some research beforehand and show some effort when posting a question.

Those tips will get better results than most of the advice floating around the interwebs.

Only <stdlib.h> exists in any form of the C standard, or on my system.

% cat file.c 
#include <alloc.h>
#include <stdio.h>

int main(void)
{
        char *x = malloc(3);
        x[0]='A';
        x[1]='\n';
        x[2]=0;
        printf("%s", x);
        return 0;
}
% cc file.c 
file.c:1:19: error: alloc.h: No such file or directory
file.c: In function ‘main’:
file.c:5: warning: incompatible implicit declaration of built-in function ‘malloc’

Don't encourage people to use nonstandard headers.

I beg to differ. malloc is defined in some implementation-defined library and declared in <stdlib.h>.

So fopen just hangs, without returning? Interesting.

The usual suspects for not being able to open a file (e.g., wrong case, bad permissions) may not apply in your situation -- but I'm not entirely certain what your situation is, and I don't think I can be any more help at this point. Perhaps somebody familiar with cygwin will come along to supply advice.

Sorry, missed the second page. Everything I had to say has been said

Every integer you pass to printf is sizeof(int) in size, unless it promotes bigger -- you can't pass anything smaller. The only way to print a 24 bit object is to write your own routine with putchar().

OTOH, you could use 3 chars.

If you're using Cygwin, it's probably best to say it upfront -- avoids confusion.

For clarification, can you tell us whether fopen returns NULL when you open the file in a subdirectory?

I agree with hsetaknev ..

Take the good part from everything ..

Problem being, that unless you have prior experience, you have no idea what the good parts are. That is why it's important to get feedback about the resources you use from people who know. I gave my opinion of the book; I can't force you (rhetorical "you" here) not to use it, but I hope you'll take my comments into consideration when learning from it, and select a wide variety of other sources so you truly understand the issues involved.

Not only that, but the OP expressed explicit interest in learning a recent version of the C standard that the book in question definitely does not cover.

Perhaps you should read it more carefully, as there are definitely examples of running Perl code from within C on that page.

That said, it is a bit unusual to call Perl from C and not the other way around. If it's reasonable to do so, another option is to compile your C code into a library and use it from Perl -- of course, this raises some more compatibility issues.

I think you can also compile Perl code into to a native library by linking it with the Perl interpreter somehow, then use that library directly... but I don't know the process.

The "simple way" is to call upon the Perl interpreter directly to do the hard stuff. Since you wish to avoid that approach, everything else is going to be quite a bit more involved.

Google suggested http://docstore.mik.ua/orelly/perl/prog3/ch21_04.htm

There's a chapter about this topic in Programming Perl IIRC, but my copy is in another state, so I can't look it up atm.

Second what WaltP says, plus don't use scanf for interactive user input, check the return values of standard library functions, and use fflush(stdout) after printing a prompt that doesn't end with '\n' to make sure it gets printed.

1 is not a portable value to pass to exit(), and returning non-zero usually means that some error occurred. Selecting the "exit" function from the menu shouldn't result in an error.

Finally, I can't imagine what version of "shutdown" you're using if -s means "halt", -l means "log off", and -h means "hibernate".

It's not too difficult.

count is just a distraction.

b starts at 10 and increments until ugly_string is 0. So the useful part of the string is from ugly_string[31] to the end; the first 31 chars are padding just to obfuscate it.

a is set to the next character in the string for each iteration of the external loop, and decremented down to 64 -- so the inner for loop just runs N = ugly_string - 64 times.

c starts at 10 and increments until it reaches 90, but it's only used when its value is 90 and subsequently knocked back down to 10.

Interesting notes are the repetition and similar groups of 4 characters in the source string. There are, umm, 46 lines of output and 42 groups of four, plus 3 extra characters -- note that there is no terminating newline on the output, and I think we definitely have a pattern there.

Come to think of it, it makes sense that each character in the source string tells you how many times to print the next character -- the last part of the conditional tells you whether to print ' ' or '!' -- the middle part of the conditional tells you when to print a newline instead -- yeah, without working out the details, that's your program explained in a nutshell.

While it's not by far the best obfuscation I've ever seen, it's certainly a valiant effort.

What?

yes but this function is not found in # include <stdio.h>

Erm, yes, it is, at least in C.

is it impossible to directly convert char to int ?

No, it's perfectly possible. You did it yourself, in your first post. But the way you phrased the question made it sound as if what you really wanted was to read an integer value from the contents of a char *. That's what the strtoX functions are for.

Perhaps you could clarify what you mean by "get integer value from the console" and "convert char to int", because I think both those questions have been adequately answered already.

Sorry, my bad!

Well, since you're repentant, I won't call the Standards Police... ;)

C++ mixed in with C is one of my pet peeves. Sorry for sounding snippy.

Hi Manimuthu,

Thanks for your reply..But this logic even i have tried. I wanted to use one single grep command for both operations. Is there a way to do this?

My advice? Don't bother, unless it's a serious performance barrier (in which case I suspect you wouldn't want to keep the whole thing in an array at once). Make the code as clear as you can and don't worry about how many times it loops over some array.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." (attributed to Brian Kernighan)

Also, you don't need

struct stacktype s1;

on line 62, you can just use stacktype s1 .

Only in C++. Please don't do that in C.

Interactively, use fgets() to get a line, then strtol() to convert it to a long.

If you're reading from structured input, use scanf().

@alexchen: C is not the same as C++. Please take that cin nonsense somewhere else.

1

int *list
int main(){

list=new int[size];
for(int i=0;i<size;i++){
list[i]=0;
cout<<list[i]<<endl;
}
}

That's not C.

Try Yashwant P kanetkar
Let us C

I've heard about this one before, but never looked it up until today. The 5th edition I found online was riddled with problems, not only grammatical errors (which are merely distracting) but careless mistakes. Notably, every single example relies on implicit int for main(), which was made illegal in C99. Furthermore, the author carelessly mixes compiler extensions with standard library features, refuses to prototype functions or declare their return types, goes into detail about implementation-defined things like structure padding and type ranges, and just generally does a shoddy job.

It's a shame it's so popular. It's as bad as Schildt, or nearly so.

Two words for the same thing.

I'm sure there are some people who draw differences and say "it's only an emulator if it does this", etc., but there's no official rule.

I tend to use "simulation" to refer to hardware, like a flight simulator, and "emulation" to refer to software, like qemu. But that's just me.

Well, it's not really a two-dimensional array -- it's a pointer to (the first element of an array of) pointer to (the first element of an array of) short.

The comp.lang.c FAQ, section 6, might help you understand, especially question 6.16.