Actually, it looks like 4. would have prevented 5. and 6. from ever being executed. Perhaps it would work if I just changed that to "If you can, move left and goto 1".
In any case, I've come up...
Type: Posts; User: Angus
Actually, it looks like 4. would have prevented 5. and 6. from ever being executed. Perhaps it would work if I just changed that to "If you can, move left and goto 1".
In any case, I've come up...
You're right: I'm screwed.
Perhaps the trick is not to go one element at a time, but every you increment an element, you first reset all elements to the left to their lowest values, and then work...
('Looks like this forum isn't going to let me express sets w/out code tags :mad:)
Hmm... I think we need a concrete example.
Say we have a set
{ A, B, C, D, E, F }. Ordered subsets of 3 would be ...
Well if "odometer" is the right name, it seems poorly chosen, since odometers cover all combinations of a set. I'm not sure why you think there's a danger of roll over, since it seems fairly simple...
It just occurred to me what Ocifer was saying. A very conceptually simple algorithm is within reach for this. To generate the power set you get k-permutations of n and then just keep decrementing k....
It's a good bit more cool than I'd like it to be. It's part of an job application demo I'm supposed to make. What I'm supposed to do is take 6 random operands and try to make them equal another...
Ok, the power set. I'm not sure what you suggest is as simple as you think, because generating a power set is an exercise in permutations in itself.
I have a set and need to get all the permutations of that set and all permutations of all its subsets. STL has a nice clean function that does permutations, but alas, it does not generate...
N/m. It seems that when I migrated from popen() to pipe()/fork()/execv() I neglected to comment out the original popen(). I had to have an epiphany that these problems might be caused by the shell...
I'm trying to capture the stderr from a process which is being called by execv(). Instead, however, it seems to be writing to a descriptor that isn't even opened in this process. The short...
Ok, well I guess that's gotta be the way it is, then. But now that I think about it, whenever I see braces I instinctively keep away from anything inside them that's stack-based, from outside them....
You are quite sure about this? Because I've been using exceptions for a long time. It may just be blind luck that I've never required destructors in the try block to be called, but this is new to me.
I always thought that the stack was supposed to be unwound when the catch block is finished, after an exception. The long experience I've had with exceptions certainly supports this. A recent...
I think that the last 3 posts are correct. I suppose what the man pages should say is that if the output gets truncated then you cannot trust what the output is, and should redo the function again...
That's borrowed from Visual Studio's VERIFY(). As far as this code is concerned, it is the same as assert().
If snprintf() returned anything but 2 then verify() would have aborted the program....
I'm trying to write an optimal function that converts a blob into a hexadecimal character string. It's written in C++, but I think it is also C
const unsigned char *pBytes = (const unsigned...
It would be the question if it called for empirical data.
Funny you should say that. I remember reading somewhere that you should never use a variable smaller than an int, if space is not a concern, and you are going to use the value for any kind of...
I see. Usually, eh? Well, I guess there's not much point in trying to program for lazy allocation. In any case, my hopes for calloc() are shattered, because it clearly doesn't generally do the lazy...
Well, every time you call realloc() to increase the size of the block you run the risk of having to copy all the data in that block. If you can rely on lazy allocation, though, you'd only have to...
Because I don't always know how much that is, and I risk calling realloc() a lot
That's a good philosophy, Salem. You should go by it more often
Then
The use of macros and #if #endif block should cure that
A quick reading of /proc/sys/vm/overcommit_memory should tell me all I need to know
Is that the only drawback? If I was in the racket to impress folk I probably would have chosen pop music instead.
Account for my request anymore than it would just, say, 10 bytes?
Recently I read somewhere that calloc() does lazy allocation, in that it doesn't allocate any real memory, but just virtual memory. Real memory pages are only allocated as writes to it are performed,...