Posts by nezachem

Line 31 is sort of funny. You need to switch on wParam instead.

concatenate the capital letters that are followed by a space

I can think only of a 3-step solution (which looks ugly, but possibly it can be improved):
- replace all wanted spaces with, say, underscores:
s/ \([A-Z][^ ]\)/_\1/g'
- remove all remaining spaces:
s/ //g
- restore wanted spaces:
s/_/ /g'

Something like that...

In the ChanNameVAlign case you want to split at the transition from lowercase to uppercase:
s/\([a-z]\)\([A-Z]\)/\1 \2/g

In the OSDSettings, I don't see a non-contradictory criteria.

This is the linker command your gcc generated (I just broke it up into few lines for clarity:

c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/collect2.exe -Bdynamic -u ___register_frame_info -u ___deregister_frame_info -o Pascal.exe c:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../crt2.o c:/mingw/bin/../lib/gcc/mingw32/4.6.2/crtbegin.o -Lc:/mingw/bin/../lib/gcc/mingw32/4.6.2 -Lc:/mingw/bin/../lib/gcc -Lc:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc/mingw32/4.6.2/../../.. -L/mingw/lib
-lgmpxx -lgmp
C:\DOCUME~1\DMS40\LOCALS~1\Temp\ccKxmt7C.o
-lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt c:/mingw/bin/../lib/gcc/mingw32/4.6.2/crtend.o

The linker works sequentially, and only puls stuff from libraries to satisfy references, which are currently unresolved. By the time the it sees -lgmpxx and -lgmp, there is nothing yet to link from them. You need to change the order, so that linker accounts your object first So, instead of

$ g++ -v -lgmpxx -lgmp -o Pascal.exe Pascal.cpp

do

$ g++ -v Pascal.cpp -lgmpxx -lgmp -o Pascal.exe 

I had to emphasize that ls (ell-es) is a command. Run it in the directory whe you run make, and post the output here.

It means that Horse.cpp is not present (at least, in the directory where you run make). What does the ls output look like?

Size of array is MAX_SIZE. Look at line 118.

You entered 4 elements. How many elements are you actually sorting?

There are very convincing opinions that GPL is legally valid, that is it doesn't contradict the existing laws and precedents. There are equally convincing opinions that it is not. This legal limbo may be only resolved in the court. As far as I know, it didn't happen yet.

Few cases make to a judge ruling on it,

Could you please point me some which did produce a ruling? I am not aware of any (in US), but maybe I didn't search hard enough.

but it seems that it's mostly because the license violators settle it when it becomes obvious that they can't win.

That's exactly the point. Settlement does not prove anything about the validity of the license. Besides, it takes two to settle.

I believe your C++ code does fall under GPL.

A "derivative work" is defined in the Copyright Act, 17 USC 101, as a:

""work based upon one or more preexisting works, such as a translation, [...] or other modifications which, as a whole, represent an original work of authorship, is a ‘derivative work’."" (see here.

What are the actual laws on copyrighting code

The real question is, does GPL hold water. The answer is, nobody knows (in US at least, and I think it's the same in Canada), because no judge ruled on it yet.

In the valueAt, if the very first comparison fails you immediately enter the else clause and return 0. Get rid of else and move return 0.0 out of the loop.

You never change the clipboard contents. You only copy the text into some global memory, which has no association with a clipboard. Look at SetClipboardData function.

Secondary issue: speed

In regards to speed, I need to write code that gets the job done as fast as possible. This was the simplest copy function I could think of, but I don't know whether it is the fastest. What is faster, fread/fwrite or getc/putc ? Or is there another standard function that can copy even faster?

The stdio buffers data by the same chunks, so the performance difference between fread and getc is in a number of function calls made. Of course fread would be called less times than getc, but I suppose the speed gain would be infinitesimal, comparing with the actual IO time.

I'm also not sure what the bottleneck is in regards to speed, as an portable drive takes more time to write to than for example internal memory. If I write a function that compresses files before they are copied, would that increase speed? Or would it just slow the read/write process down?

The real bottleneck is in transferring data to and from the peripheral device. You sure want to minimize the amount of data transferred, so yes, compression is a standard way to increase the performance.

Something tells me you are on a Windows system. There is a distinction between a text mode and a binary mode. In the first case the ^Z character does serve as an end-of-file marker. Open your files in a binary mode: pass "rb" as a second argument to fopen. Same goes for writing.

Add the line

cout << "fact = " << fact << endl;

right after line 24, and see what happens.

Look here, specifically in the discussion of "bound imports". This is the only use I am aware of.

I actually want to automatically add .c and .o files whenever i create a new .c files.

Umm... there is a way, read on the wildcard function and stem substitution, as in

SOURCES := $(wildcard *.c)
OBJECTS := $(SOURCES: %.c=%.o)
calc: $(OBJECTS)
    gcc -o calc $(OBJECTS)
%.o: %.c
    gcc -c $< -o $@

In my opinion, wildcard is a misfeature (if you wish I may elaborate). In any case do not try to use it until you comfortably understand the basic make functionality.
Make's way of thinking is sort of convoluted. Take small steps to get used to it.

can anybody explain what the variables $@ and $< mean.

$@ in a recipe means a target name. For example,

foo.o: foo.c
    gcc -o foo.o foo.c

is the same as

foo.o: foo.c
    gcc -o $@ foo.c

Similarly, $< means a prerequisite name:

foo.o: foo.c
    gcc -o $@ $<

Not much of a value for the explicit rules, but very useful for the stem rules, such as

%.o: %.c
    gcc -o $@ $<

It is a very bad habit to use an asterisk in the dependency. Consider the situation:
foo.c bar.c are the sources. For some reason foo has been compiled into foo.o, but bar.c was not. The directory contains foo.c, bar.c, and foo.o. The dependency *.o at line 4 in your makefile evaluates to just foo.o so bar.c is never compiled.

The solution is to spell your object files explicitly:

objects = foo.o bar.o baz.o
calc: $(objects)
    gcc -o calc $(objects)

There are advanced techniques, but for now do spell your objects out.

What is my program thinking?

I have no idea. You need to debug. For that, I'd recommend to provide an ability to call evaluate() directly with any given position. Call it with

XXO
-O-
-X-

and

XXO
-O-
X--

See which one gets better score. If the first one scores better, the error is in evaluate(). Trace its execution line by line. Otherwise, the error is in alpha-beta. Again, trace why the better scoring position gets rejected.

X--
---
--- Perfect 1st move for Tic Tac Toe!

To begin with, I wouldn't call it perfect.

Now, if you are sure that the alpha-beta works correctly (I didn't bother to check), then the problem must be in a statical evaluation. And it is there indeed. Hint: pay attention to the compiler warnings.

You calculate the position of the new environment variable (line 81) based on the length of the current one. It is OK as long as you use the original length. In case of PATH it is not so.

skip 16bit it is dead

I wouldn't be so definite. 16-bit is very well around (and, ugh, 8-bit too). Their niches are very specific indeed, but really, 8-bit is the only area where assembly programming skills still have value.

The problem is that a Weierstrass product converges very poorly (my gut feeling is that it is worse than linear; correct me if I am wrong). That is, even 1e8 iterations may not be enough.

Well something must be different. My first recommendation is to attach a debugger, and figure out what exactly is failing. My second recommendation is to get rid of system(), and use rename() and unlink(); if you insist on system(), at least spell out explicit paths to mv and rm.

So, you passed FunctionToPass to ThreadProc as a parameter, which is correct. Now you need to actually call it:

DWORD WINAPI ThreadProc(LPVOID lpParameter)
{
    void (* function)() = (void (*)())lpParameter;
    function();
    return 0;
}

void not ignored as it ought to be

because you are not passing the function to the thread. You are calling it (notice () in FunctionToPass() at line 21), then try to dereference the result (notice * there). Since FunctionToPass is void, the compiler complains.

In this context, lemma is a dictionary form of a word.

That was not what I meant. In my own opinion, the OP meant that a user-defined function can run AFTER main() has ended, of which I try to explain that if main() has ended, the program has ended.

Even that is wrong. Add a

~foo() { std::cout << "Me last!!" << std::endl; }

to Narue's example.

The problem is that data is one-element array. The only valid element is data[0] . Accessing data[1] is illegal. Try data[0] = whatever .

Still, we need to see the code which produces error.

The presence of flags, and special casing of certain conditions usually indicate that something is wrong. For example, on a very first insertion you compare temp with arr[0], which has a garbage value. If that comparison fail, the next comparison accesses arr[count], and count is -1. Welcome undefined behaviour.

Looking closely, you'd realize that all the work is really done in lines 32-42, with small modifications (count shall be initialized to 0 BTW):

for(pos = 0; (pos < count) && (temp > arr[pos]); pos++)
        ;
    for(i = count; i > pos; i--)
        arr[i] = arr[i - 1];
    arr[pos] = temp;
    count++;

Make sure you understand why count must be initialized to 0, and how your special cases are automatically handled here.

> But, when I try to define data in another line of code, I get cross-type errors.

Can you show how you do it?

It means the variable "extra" is equal to the number in array cell 20.
The long way is: extra = extra + randomArray[20]

These two explanations are sort of contradictory. So, is it equal, or is it increased by?

So back to base 1, can you explain the plus sign. And I don't mean syntax. I mean, why did you put it there?

Can you explain the plus sign at line 18?

> for some reason the ReducedFraction function is not working

Perhaps, because you never call it.

The problem has nothing to do with 64 bit types. Values you read are not garbage, but a very valuable port definitions:

struct ofp_phy_port ports[0];  /* Port definitions. The number of ports is inferred from the length field in the header. */

Which means, once you've

recv(connected, &features_rep, sizeof(features_rep), 0)

you need to inspect features_rep.header.length , figure out how many struct ofp_phy_port follow, allocate memory for them and read those data.

Think of the case of a list with 2 elements. Once you've deleted the last one, where does _first->_fore point to?
BTW, same applies to _last->_fore in a general case.

You have to understand how fscanf works. Where does it store the result of conversion, and what does it return.
In your case, all the numbers you read end up in input , while input1[] collects return codes (which all happen to be 1, indicating successful conversion of one field).

As usual, "doesn't seem to work" is not a helpful description of the problem. My wild guess is that you do not account for the newline character (which does appear in buff), and becomes an inherent part of certain words.

a) Yes
b) C++ does not address this
d) Sort of (due to e)
e) Very much
f) Start here, then try to apply those ideas to your architecture (if it is not x86).

You forgot to chdir(strPathname.c_str()) The logfile is created, but in the wrong place.

Depends on your development environment. Every IDE I know has one. If you calling gcc from the command line, then use gdb.

Run your program in a debugger. It will show you exactly where the segfault occurs, along with the function call sequence which lead to it. Usually it is more than enough to pinpoint the problem.

This is a quite unusual way to serve connections. You don't need to shutdown a listening socket; the same one will accept new connections as many times as you want:

listen(serverSocket, 1);
    while(1) {
        clientSocket = accept(serverSocket, 0, 0);
        do_stuff(clientSocket);
        shutdown(clientSocket, SD_BOTH);
        closeSocket(clientSocket);
    }

In your code, after the line 51 you lose the handle to the listening socket forever. It is not affected by shutdown/closesocket anymore. The socket object is still sitting there interfering with a next one you are trying to create.

The way you wrote it, checkurl() is not a method of Ui_MainWindow class, but a standalone function. Give it a proper indentation.

You're writing the entire array writePlanet each time you call save().

No. OP is writing a same nonsensical pointer multiple times. Here is the essential code:

void save(planet_t writePlanet[], int totalSize){
      for(count = 0; count<PLANET_SIZE; count++){ /**/
         fwrite( &writePlanet, sizeof(writePlanet), 1, outFile);
         printf("\n%s", writePlanet[count].name); /* Test to see if its writing. */
      }

writePlanet is a pointer. &writePlanet is a pointer to it (an address of some location in the save() 's stack frame). sizeof(writePlanet) is a size of a pointer.

To write the entire array, do

fwrite(writePlanet, sizeof(*writePlanet), totalSize, outFile)

assuming that totalSize is a number of entries to be written.

Same stays for read.

The SUBDIRS variable contains a space. From make point of view, the line

make -C /lib/modules/2.6.38-8-generic/build SUBDIRS=/home/andrew/Documents/OS_Projects/Chapter 6 modules

means that SUBDIRS=/home/andrew/Documents/OS_Projects/Chapter , while 6 and modules are targets to make. You may either rename your directory to Chapter_6, or change your makefile to something like

$(MAKE) -C $(KDIR) SUBDIRS=\"$(PWD)\" modules

(untested)

Yes, to remove a widget you'd do widget.grid_forget(). May we see the failing code (specifically, what is self in that context)?

I am afraid you've misunderstood. The code is plain C. No porting effort required. Except maybe an olbanic case in the comment.

You didn't initialize buf.priority (mtype in the msgsnd terms). msgsnd requires it to be positive, thus EINVAL. Adding

buf.priority = 2;

at around line 43 heals everything.
PS: Why 2? Because of 2 at line 76...