Posts by sepp2k

If a function is nested in another function, you're not allowed to use unqualified exec in either of the two functions. Unqualified in this case means "without in". An explanation of why this limitation exists can be found here.

In your code you don't really need exec. To set and get global variables by name, you can just use globals()[name], but you don't even need global variables either. You can just define cache and rankings as local variables in mu_cache and then access them in wrap.

Another error in your code is that you use global rankings in delete_smallest. This will cause an error message about there being no global variable named rankings because rankings is a local variable in the wrap function, not a global variable. If you just remove that line, the error will disappear and you will be correctly able to access the rankings variable.

Now i wanted it to sort using bubblesort and structures.

Why? Unless you have a very goood reason not to, you should really use std::sort. And even if you do have a very good reason, I don't see why you'd want to use bubble sort instead.

I also don't see why you put your sort function in a class if the class doesn't actually contain anything.

Sorry for going off on a tangent, but:

Any (turing complete)programming language can do anything another can

People say that a lot, but that isn't actually true. Any Turing complete programming language can compute anything any other can, but that doesn't mean it can do anything.

For example programs written in Brainfuck can't write to or read from files, communicate over a network or the Internet, create GUIs or do anything else other than writing to stdout and reading from stdin.

Your code won't print all palindromes in all cases:

A palindrome can contain other palindromes that aren't its "inner strings". Take the string "kakykak" for example. Your algorithm will find "kakykak", "akyka" and "kyk", but not the two "kak"s.

Another problem is that palindromes can overlap. For example "akala" contains the palindromes "aka" and "ala", but your code wouldn't find the latter because after finding "aka", it would skip right to index 3 (the "l") and would not look for any palindromes starting at index 2.

Also technically every single letter of the string is a palindrome by itself, too.

As far as I can tell there is no more efficient way to do this

I'm assuming that the OP came across this problem in a programming contest or a site with a collection of algorithm problems or something of that sort (or possibly homework). And in those kinds of sites/contests, they wouldn't pose a problem that can't be solved in a reasonable amount of time (meaning O(n^2) at most usually). So for that reason alone I'd expect there to be a more efficient algorithm.

OP doesn't have an array of strings where he wants to check each element string. He has one string of which he wants to check every substring. Iterating over all possible substrings and calling is_palindrome on each of them (which is basically what the OP is doing now - albeit in a needlessly complicated -- and apparently in some cases broken -- way) leads to a O(n^3) runtime. The question is whether this is possible in a faster way.

I removed the /g

You mean "added", right?

It means if stdout is writing normally to the screen, it will automatically be flushed when you print a newline. But when it's writing to, say, a file or a pipe, the file won't be actually written to until the buffer is full, you explicitly flush it or the program ends.

When people talk about stdout being line-buffered, that means that if you do printf("Hello ");, then wait for some seconds and then printf("world!\n");, the output will appear all at once as "Hello world!" when the couple of seconds are over. If you used stderr instead (or you flushed stdout after the first printf), you'd see "Hello" right away and then a couple of seconds later the rest of the message would appear.

Since your format string ends with a \n anyway, that's not your problem at all. Even using stdout, your message will appear as soon as you print it, so using stderr instead changes nothing (except that it will mess with output redirection and such).

Your problem is that getchar won't return until the user entered a full line - i.e. it won't return right after the user entered the first character. That's not something you can change using only the functionality provided by the C standard. Depending on which platform you're targetting, there are platform-specific functions to do what you want though.

Your struct members are arrays of pointers, but you're treating them as if they were just pointers.

Note that you can't assign to arrays and even if you could the values that you're trying to assign them are plain pointers, not arrays of pointers.

That should still produce a type error when you try to compile it.

You did not explain what you're trying to do here (or how exactly your real code does not work - you seem to be implying that your real code does compile), so it's not clear to me what you're trying to copy where. If you intend to copy into buff, you have your argument mixed up. If you intend to copy out of buff, rubberman is right that you need to initialize it before you use it - otherwise what exactly do you think you're copying?

Also if you intend to copy into buff one obvious problem is that you never do anything with buff before foo ends.

Another potential problem is your use of strcpy, which will lead to a buffer overrun if the given string is too large to fit into the buffer. You should use strncpy instead.

Have you tried to compile the code? That should give you a list of errors telling you some of the things wrong with that code.

Which parts are you confused about specifically? The %cs in the format string are used, so that the " characters (ASCII value 34) can be inserted without messing with backslashes. Other than that the main trick is that str is used both as the format string as well as the argument to %s, so that the format string can appear verbatim in the printed output without having to repeat it.

PS: To make this a proper quine you should add the include, the return type of main and the return statemetn to the format string. You'd also need to add additional %cs for the line breaks if you want those to be reproduced as well.

PPS: When the application exits successfully, it should return 0, not 1.

Any time you venture out into the "weeds" of undefined behavior, the results can be odd or just what you might expect.

Where and how does this code invoke undefined behavior? I don't see it.

and how can i misunderstand your first post as dev90 and then support you as s2pp2k???

ss125 (who said the thing that sounded wrong) and I (sepp2k) are two different people. And I don't think Gonbe was seriously suggesting you're the same person - he was being rhetoric.

When you call a function, you need a pair of parentheses. Thus it should next.read_name(), not next.read_name.

Also your read_name is infinitely recursive and can't possibly work. And all it does (other than overflowing the stack) is to write to a local variable that it then never uses - that can't be right.

Another problem is that read_name's return type is void, so you can't use it as an operand to << (or to any other operator or function).

By the way, a couple of things I forgot to mention earlier:

The amount of bytes an integer takes up depends on the supported word size of the used CPU and there is no "default" specified in the specification.

It's true that sizeof(int) is implementation defined, but it's not necessarily equal to the supported word size. Specifically most (all?) compilers have sizeof(int) equal 4 even on 64-bit platforms.

8 and 16 bit integers

int can never have 8 bits. The C standard defines the minimal range of int and unsigned int, such that at least 16 bits are required to represent them.

No, I am not wrong in case of &arr+1.

Nobody said you were wrong. Gonbe said that what ss125 said ("&arr +1 means arr[]=> 2 bytes for arr and 2 bytes for array") sounded wrong, which it did - though I also have no idea what exactly was meant by that.

arr itself does not have a memory address.

I wouldn't say it that way (you yourself refer to arr's address a couple of times in your post). Its address just happens to be the same as that of its first element.

So the result would be the address of arr plus 2 * sizeof(int) bytes in this case.

Or to make the mechanics a bit more obvious: the address of arr plus 1 * sizeof(int[2]). That is writing p + i where p is a T pointer (or array) always increments by i * sizeof(T) bytes - T in this case being int[2] and sizeof(Foo[N]) being equal to sizeof(Foo)*N for all types Foo.

The declaration of get_name says that the return type is string. The definition says that the return type is void.

"GOOD EVENING" is an array of characters. If you take any array or pointer and write p + i, you get a pointer pointing to the address that's i elements after the location that p points to. So in case of an array, arr + i (or i + arr - order doesn't matter) produces a pointer to the element of the array arr at index i.

So 2 + "GOOD EVENING" produces a pointer that points to the second O in GOOD. Adding 6 to that moves the pointer 6 further to the right, producing a pointer that points to the first N in EVENING - same as if you had written "GOOD EVENING" + 8. So you pass a pointer to that N to printf and printf then prints all characters starting at that pointer until the end of the string. So that's why you get NING.

~s.o.s~, I think you overlooked the fact that someboundmethod is never actually called in the james' code. d simply stores a reference to the method someboundmethod of the object returned by foo(). Since that method is bound to the object, the object will live at least as a long as the method is referred to.

Ah, I'm stupid. I though setDataRef was a constructor (I didn't pay attention to the name... or the fact that it had a return type). So, yeah, ignore my answer, you can't use initialization lists with methods. Sorry.

Generally you shouldn't use assignment to initialize your members inside the constructor. As you noticed, it doesn't work. It also calls the default constructor, followed by the assignment operator, which might be needlessly expensive for some classes. Also it won't work if the default constructor or the assignment operator aren't defined for the given class.

Instead you should use initialization lists:

someDataClass &setDataRef(const largeDataType &o) : data(o) {}

Using initialization lists you can initialize references and const members without problems and you can initialize non-references using an constructor you like instead of the default constructor.

Actually everything I said in my post was bullshit because I can't read properly. I thought your variables were strings, not arrays of strings. Sorry about that.

Since they're arrays of strings, all of your assignments should cause errors. You can't put ints into an array of strings (because ints aren't strings), nor can you put arrays of strings into array of strings (because again arrays of strings aren't strings and you can only put strings into arrays of strings).

Array of ints? I don’t think I have learned about that yet

If you define an array, you write T name_of_the_array[N]; where N is the length of the array and T is the type of value you want to put inside the array. If you want to put strings into an array, you write string name_of_the_array[N]; like you're currently doing; if you want to put in ints, you write int name_of_the_array[N]; instead. And if you want to put arrays of strings into your array, you write string name_of_the_array[N][M]; or string* name_of_the_array[N]; (the former stores N arrays that all must have size M and the latter stores N pointers that can point to arrays of any size).

If you want to put multiple types of value into the same array, you're out of luck because you can't do that (except using pointers to the values and casting them, but that's almost certainly a bad idea here and probably beyond what you've currently learned anyway).

It is not clear to …

string a string within a string

Pardon?

int potion = 30;
int hiPotion = 70;
int ether = 20;

item[numItems++] = potion;
item[numItems++] = hiPotion;
item[numItems++] = ether;

I'm not exactly sure what you intend those lines to do, but I guarentee you that they won't do that.

string[index] returns a reference to a char, so the right side of the assignment should be a char. Since ints are implicitly convertible to chars, assigning an int works, but all that does is to create the character with the byte value 30, 70 or 20 respectively. So, assuming ASCII or a superset, that's an unprintable character, followed by F, followed by another unprintable character.

The same applies later in the code when you try to assign other integers (or shorts) to characters of strings.

zidane[cmd++] = magic;
zidane[cmd++] = item;

Strings aren't implicitly convertible to char, so that's why that won't compile. If you want to insert a string inside another, use the insert method.

You can't do cout << *(POINTER + 2) for the same reason that you can't do cout << *POINTER or cout << OBJECT: There is no overload for operator << that takes an ostream and a CLASS.

Also POINTER + 2 does not add two bytes to the pointer, it adds 2 * sizeof(CLASS) bytes to the pointer. Which of course will invoke undefined behavior since there's only one object in the memory that POINTER is pointing to, not three.

Store them as doubles, perform the calculations and when you're done use format when you print the results.

That's because format returns a string. A double does not have a format - only a value. If you want to store formatted numbers, you need to store them in an array of strings. If you just want to store doubles, simply use 0.0 rather than d.format(0.0).

Your power function takes n and multiplies it with itself m times. What it should be doing is take m and multiply it with itself n times.

Also n should be an int, not a float.

The acual value of true and false is not defined, nor is it guarenteed to be either 0 or 1

Not sure what you mean by "actual value", but converting true to an integer will give 1 and false will give 0. That's defined in section 3.9.1, paragraph 6 (in the C++11 standard, but I'm pretty sure it's the same in C++03 - I just don't have the 03 standard handy right now).

The only way you'd get a bool that prints as 128 is if there's UB being invoked somewhere - presumably due to a missing return statement somewhere in the function.

but I have an if after else

The if must be before the else.

walls,corner[2] = (' #')

You accidentally typed a comma instead of a period here.

As a result the parser things you want to assign to a local variable called walls as well as to the second element of a variable named corner. Because of this Python now thinks that walls is a local variable and thus produces an error when you try to access it before its value has been set.

That line makes no sense, that's why you don't understand it. As you said, it's casting to int* and then back to char*. It could just as well be written p = p; (or just left out altogether because obviously that's a noop).

Line 7 should be p = (char*) arr;. You need a cast there because only void pointers can be implicitly converted to other pointer types - other pointers or arrays can't (though some (most?) compilers allow it with a warning).

The cast on line 10 doesn't make much sense either. Since p has type char*, this line relies on the int pointer being implicitly converted back to char*, which, as I said regarding line 7, is illegal. And if it was illegal it would be the same kind of pointless to-int*-and-back casting we see on line 8. I.e. it calculates p+1 (using the type char*) and then casts that to int* and then right back to char*. So line 10 is the same as p = p + 1; (except the latter does not rely on an illegal implicit cast).

PS: Your main function is missing a return statement.

And what happened then?

it's undefined because you have no idea what other functions will do with it.

Admittedly I just found out that it's undefined 45 minutes ago, but I'm pretty sure that's not the reason why. By that logic copying the pointer to a different variable or passing it to a function that we defined ourselves would not invoke UB because then we would know what's being done with it. But according to this (page 49, lines 14+) any use of an illegal pointer invokes UB.

Also we do know what printf does with its arguments. Since the standard does not mandate that the argument for %d shall be a pointer that's legal to dereference (which it doesn't, since the argument for %d shouldn't even be a pointer), any implementation that does dereference the argument would be in violation of the standard. Likewise the standard does not mandate that %p (which the OP should be using) dereferences its argument and therefore it won't. In particular it is legal to do printf("%p", arr+n) where arr is an array of size n. If printf could potentially dereference an argument for %p, that would not be legal.

As a sidenote, there's another reason why the code invokes undefined behavior: %d expects an integer, but is given a pointer.

I did not know that merely using (without dereferencing) a pointer already invoked undefined behavior. Learn something new every day.

Since the pointer is never actually dereferenced, is it really undefined behavior?

why the o/p is 10.

It's not.

Perhaps this one

That was supposed to linked here, right?

How does it not work? Are you getting a syntax error on the funny print line? What is that line supposed to accomplish? That's not a valid use of print.

Anyway using an empty infinite loop to prevent the turtle window from closing is a very bad idea (it will cause the Python process to cause 100% CPU usage) and won't work properly anyway. You should simply call turtle.mainloop().

By the way, you could also perform a XOR swap.

Neither pointers nor floats can be operands to ^, so neither of your macros will work with the OP's float pointers.

Hardcoding float* instead of passing it in as a parameter won't make the code compile in Visual Studio, nor will it fix any other problems the macro has. The only thing it will do is make the code less general.

Earlier I tried this code on windows (IDE = visual studio), It was giving following errors:

The problem is that in C89 you're only allowed to declare variables at the beginning of a block. No further variable declarations are allowed after the first non-declaration in a given block.

So this would be legal:

int main() {
    int x = 7;
    int y = 8;
    return 0;
}

But this would not:

int main() {
    int x;
    x = 7;
    int y = 8;
    return 0;
}

Because here line 4 is a declaration, but line 3 isn't. If you put the declaration of y in a new block, it's legal again:

int main() {
    int x;
    x = 7;
    {
        int y = 8;
        return 0;
    }
}

So to fix your code sample, you can either initialize p and q on line 7 and remove lines 8 and 9, so that the declaration of t is still at the beginning of the block - or you could add braces around the body of your macro, so that it creates its own block.

The latter is much preferable because it allows you to use the macro in the middle of a block - not just at the beginning - and it limits the scope of the t variable, so that you can use SWAP multiple times in the same scope and even in a scope where there's already a variable named t …

No, it shouldn't. float* t; is a perfectly legal variable declaration in C - float* = t; is not.

am i right 100% ?

Yes.

explain me why is it neccasary to fflush the streams ?

When I run your code without flushing or adding newlines, I get a different amount of output every time I run it.

To be honest I'm not sure why anymore. I wanted to say that forking while there's still output in the buffer, will give the forked process a copy of the buffer, leading to duplicated output. That's true, but your code only prints after forking, so that shouldn't be a problem here (also the problem is that I (sometimes) get too little output when I run your code - not too much).

Oh and also note that since there's no newline at the end of your strings and you don't flush stdout before forking, the output may actually behave unpredicatably.

but if i want to know without running it ?

Then you run it in your head.

First note that the return values of the first three forks do not matter - you assign each of them to ret, but then you overwrite them right afterwards without using them. So you can simplify the code by writing it as:

fork();
fork();
fork();
ret = fork();

Now if you understand the fundamentals of fork, you know that each fork creates a new process and the control flow in that process starts right after that call to fork. So after the first fork you have two processes and each of them will then execute the second call to fork. Both of those calls will create another process. So you now have two new processes, making a total of four. Now those four processes all execute the third fork and so on...

There's already a module named math in Python. You'll need to name yours something else.

Use the sum function.

But doesn't c's memory address contain value of a+b?

Yes, after it has been assigned. A better example might be f(a+b) where f takes an int reference. Since the result of a+b is a temporary without an address, the call is illegal, but c=a+b; f(c); would be fine because c is a variable.

if so, why a's address can't be accessed? Isn't supposed to store 3?

It can. But what you're passing to print isn't a. It couldn't possibly be because print wants a MyString, not an int. So what you're passing to print is the result of MyString(a) (which is implicitly applied because it isn't marked explicit). And that result is a temporary object that's not stored in a variable and doesn't have an address. If you store it in a variable first, there will be no problem:

MyString a_as_string(a);
print(a_as_string); // Works fine even with a non-const reference

That said, print really should take a const reference because it doesn't modify its argument and there is thus no reason for it to take a non-const reference.

Also your MyString constructor really should be explicit because it makes no sense for an integer n to be implicitly converted to an empty string of size n.

You can't use as with the from foo import bar syntax. What would you expect that to accomplish anyway? The whole point of using from foo is that you don't need to use a qualified name to refer to the module's function.