Posts by Trentacle

Ancient Dragon is correct, but I'd like to point out that there is a difference between

char *str = "Test";
/* and */
char str[] = "Test";

In both cases, "Test" is a string that resides in read-only memory. In the first case, str is a pointer object that is initialized to the address of the read-only string, as Ancient Dragon described.

But in the second case, str is an array object, and the initialization actually copies the string from read-only memory into the new (read-write) array. This memory has automatic storage duration, so it disappears when str goes out of scope -- you don't have to worry about free()ing it like you do with malloc().

As an aside, this kind of automatic copying is possible only with initialization, not ordinary assignment, so the following is not valid:

char str[100];
str = "Test";

This is because an array name is not an lvalue. The other version,

char *str;
str = "Test";

is more or less fine, but you must be very careful if you ever modify the string because str points to read-only memory. If you don't try to modify the string, declare it as char const *str; instead.

use g++ on linux if those ide are too hard to understand with g++ you will have full control

g++ is not a C compiler. Please make a token effort.

You didn't ask a question, so I'm assuming you want feedback.

• void main() is a non-standard extension to the C language. Prefer int main(void) (or int main(int argc, char *argv[]) when you want to use command line arguments).
• <conio.h> is also non-standard and also very very old. Don't use it or any of the functions it provides. (Clearing the screen when you have not been explicitly asked to do so is annoying to the user.)

• fflush(stdin) invokes undefined behavior because fflush() should only be used on output streams. If you want to discard input (which is usually a bad idea anyway) then you must write your own code to do so.

• <conio.h> is also non-standard and also very very old. Don't use it or any of the functions it provides. (Clearing the screen when you have not been explicitly asked to do so is annoying to the user.)

• Your program will have undefined behavior and may fail when the user inputs N > 10. You need to ensure that all inputs are within the ranges your program can handle.

• Never ever use gets(). It can be made to overflow the array it's given very easily, which causes undefined behavior. Use fgets() instead and pass in the size of the array.

You should avoid relying on non-standard features because they don't work for everyone. I didn't try to compile and run your program because I knew as soon as I saw #include <conio.h> that it wouldn't work for me as …

$x += $y

means the same thing as

$x = $x + y

with the exception that $x is evaluated only once -- this would only make a difference if evaluating $x had side effects (e.g. when it's not really a variable but actually a subroutine call).

You can use the same op= syntax for any of Perl's operators, like *=, -=, /=, <<=, .=, etc. and the semantics are the same.

Since you're not instantiating any objects of class Die, anything you want to use must be declared static. That includes all the variables that are defined directly within the class as well as the die() method.

That said, you don't have code showing how you expect to use the Die class (namely the body of main), so I could be way off base.

It's int main(void)

I think I understand why -- printf("%s\n", s) can be optimized to puts(s).

That said, this is EXACTLY why you shouldn't ever rely on undefined behavior -- because it does weird things you can't predict and is affected by apparently unrelated changes in ways you can't anticipate. Any attempt to make sense of what happens after UB has been invoked is an exercise in futility.

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.

@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?

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.

#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?

Try here.

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

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 …

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?

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)

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.

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.

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.

On the same note, requiring less extra space than myk45's suggestion and only somewhat more computationally intensive than mine, keep an array of pointers. Step through the string, and, every time you pass a space, overwrite it with a 0 and store a pointer to the next character in the array.

When you're done, you'll have an array of pointers to null-terminated strings.

temp = array[m-1];
array[m-1] = array[n-1];
array[n-1] = temp;

and loop through the array, printing each one and spaces between each.

Well, since you posted in the C forum, here's a C example of getting a filename from the user. It performs careful error checking, which may or may not be necessary for your purposes (but you're well advised to always do it).

#include <stdio.h>
#include <string.h>

int main(void) {
        char buf[80];
        size_t len;
        printf("Enter a filename: ");
        fflush(stdout);

        if (!fgets(buf, sizeof buf, stdin)) {
                fprintf(stderr, "EOF or input error\n");
                return -1;
        }

        len = strlen(buf);
        if (len + 1 < sizeof buf) { /* end of line reached */
                buf[len - 1] = '\0'; /* remove terminal \n */
        } else {
                fprintf(stderr, "Filename too long!\n");
                return -1;
        }

        printf("You entered '%s'\n", buf);
        return 0;
}

C++ would look quite different, with lots of std::cout and std::cin, I imagine.

Best of luck.

(Man page for fgets is available at http://www.opengroup.org/onlinepubs/009695399/functions/fgets.html . You may see scanf used to read interactive input, but don't do that.)