int main()
{
while(true)
malloc(50);
return 0;
}
The loop is now infinite, but the memory will sooner or later be exhausted. At that point, malloc will not allocate anymore, but the loop will still cycle forever. It will be very hard to stop it, having no more resource to create another process to kill the cycling one ...
2 bugs found. > recompile ... 65534 bugs found. :doh:
The result of an expression is temporary, and it is destroyed an the and of the expression evaluation. In your first case, you are getting a temporary string as a result of s1+s2, whose buffer pointer is saved in s. After that, the expression finish, the temporary is destroyed, and so it is its buffer and s is left dangling. You had been lucky in having printed nothing. accessing a deleted buffer can even result in a crash. In your second example, the temporary string resulting from s1+s2 is kept alive until the expression it belongs ( cout<<(s1+s2).c_str()< ) is evaluated. Hence its buffer (renturned from `c_str()`) is still there at the time its pointer is given to `cout`. Your first sample works correctly if you retain the string: void SetStr(string& s1, string& s2) { string ss; //the place to store the result ss = s1+s2; //the result of s1+s2 is moved to ss, that survives the expression itself const char* s = ss.c_str(); //ss buffer pointer obtained cout << s << endl; //your original cout } 2 bugs found. > recompile ... 65534 bugs found. :doh:
The iterator members aren't granted to remain the same, and the iterator itself can be wider than just a pointer (it may have some other members for checkup). The standard grants that list::itrerator will always be valid until the element they refer remain in the list. An list grants that the element retain their placement in memory until they remain in the list. Instead of store the iterator, store the pointer to the value the iterator refers to:
SetItedDataPtr(&*iter);
You can -at this pioint- access the element directly through the pointer. Just make sure to update the list and the list-box coherently. (Note: if *iter has a unary-& overload, just use std::address_of(*iter) )
2 bugs found. > recompile ... 65534 bugs found. :doh:
I don't know if it is just a typo but ... your aim is impossible to get. There are infinite strings that can give the same CRC. So first start to think as "plural", then ... the only way is "try/retry/retry ...." until you retain to have enough of them.
2 bugs found. > recompile ... 65534 bugs found. :doh:
What you did in your first post is correct. The problem you run into is a LINKER problem, not compiler (if you are unsure about the difference, study a while how compile and linking process works) Your "program" is actually made by two sources (main.cxx and foo.cxx): you have to compile them both, and link them together to produce a final executable. both the files must be inside your "project" configuration. By placing the function definition in the header you solved the problem because now everything you need in known to main.cxx (that's probably the only file you compiled) But if you compile bot files now you will get a "symbol defined more than once" linked error. So either: - use separate files, but compile them all - use only a single "cxx" and define everything the the header. But -in this second case- declare the functions you will define at header level as "inline" (inline int add(int a, int b) { ... }) to avoid multiple definitions in case of multiple compilations.
2 bugs found. > recompile ... 65534 bugs found. :doh:
Not that much. The principle "It sis yopur software, but that's not your computer" was applied by the US court that made Sony BMG retire their own "copyright protection systems" and pay some billions in a class action.
2 bugs found. > recompile ... 65534 bugs found. :doh:
This sounds suspicious: If I have a license for your app, and I have a license for a debugger, I have (as per the EEC law on software copyrights) the full right to run a debugger on it. If you prevent it and I need it, I can even take you to a court to impose you to remove that protection.
2 bugs found. > recompile ... 65534 bugs found. :doh:
The reason is not because of the OS (it simply adjust the relocation table after copying the executable image in memory BEFORE jumping in it, so the exe itself has no role in that) but because of how C++ works. Objects has constructors and destructors. Try this
#include <iostream>
class A
{
public:
A() { std::cout << "A created" << std::endl; }
~A() { std::cout << "A destroyed" << std::endl; }
};
A global_a;
int main()
{
std::cout << "this is main" << std::endl;
return 0;
}
The output will be
A created
this is main
A destroyed
Global objects must be created/destroyed outside the scope of main. This is not an OS requirement, but a requirement for the C++ specification. mainCRTSturtup is the "bridge" between the OS (that has no clue about the app language specifications: it just want an address to be called) and a language like C++ that requires some code (constructors and destructors of global objects) to be executed independently of the main() function.
2 bugs found. > recompile ... 65534 bugs found. :doh:
modified on Sunday, August 14, 2011 4:33 AM
It is the "initializer" and "cleaner" of the C-RunTine. The operating system calls it with a machine code jump after loading the executable in memory and filled up the relocation table. It takes care of the invocation of the constructors of all the global objects (since the exist "outside of main", they have to be create before main is called). It then invokes "main" (or WinMain) after unpacking the command line, and - when main returns, calls the destructor of the on-fly created static objects and the destructors of the global objects in reverse construction order, then finally, returns the main return value to the OS process who invoked the app.
2 bugs found. > recompile ... 65534 bugs found. :doh:
Resmi Anna wrote:
That is why there is compilation error. c++ provides us something through which we can overcome this problem.
That's improper. virtual bases are not "the solution to ambiguity". Are just "another thing". If A is inherited twice because it must be inherited twice, it is not removing one of them that you "solve" THE problem. You actually soleve A problem, and introduce something else. The layout of D in the first case is
D[B[A]C[A]]
and in the second case is
D[B[.]C[.]A]
(note: '.' is a pointer to A, internal to the compiler generated structure) That's not equivalent to the first.
2 bugs found. > recompile ... 65534 bugs found. :doh:
The compliler has no problem in creating the D object with two A-s in it. The problem is the assignment to the A* (that is ambiguous since there are two of them), not the D creation.
2 bugs found. > recompile ... 65534 bugs found. :doh:
Ok, not a "ship" but... impressive as well! Yves Rossy[^]
2 bugs found. > recompile ... 65534 bugs found. :doh:
The "parent" should point to the parent and the "self" should point to the sibling. But it is a very poor implementation, difficult to walk and maintain (who are the children of a given parent? you should keep a list of the "world" to scan!). Hierarchies normally requires more pointers: - to the parent - to the first child (and eventually to the last) - to the next sibling (and eventually the previous)
2 bugs found. > recompile ... 65534 bugs found. :doh:
Code-o-mat wrote:
2 hours is a lot of time, you might want to shorten that.
Dangerous: those timers are expected to be consistent on a very wide number of system, and -because of the way TCP works- there is no need to make it shorter. The keep-alive is sent on a silent socket to let it be not-anymore silent. But the problem is ... why is it silent? If there are data to let flow, TCP itself recover transmission error and - if that cannot be done - reports to the soket WSAENETRESET/WSAENOTCONN independently on every keep-alive feature. If there are no data to let flow for long time, considering servers queue, routing tables, switches cam table, firewall caches, ARP table etc. assuming everything still works the same is risky. Better to close the socket, and reopen it again when furtherly needed, and use some "session layer command or data" (the application should define what the y should be) to track the state of the session or re-sync the client and the server. In other words, the OP had better to implement a more robust application protocol that uses the underlying socket not just to transfer data, but also to exchange some status information about the existence and activity of the client and the server (this can be done more frequently) if he wants to promptly react to an unexpected event.
2 bugs found. > recompile ... 65534 bugs found. :doh:
Nope. 1) Unicode is not a Microsoft product. What UNICODE is is defined by www.unicode.org[^] 2) Microsoft use to encode UNICODE into 16-bits units. That is a technique well defined by the UNICODE standard itself, known as UTF-16. Essentially, every code not in the range 0xD800-0xDFFF and lower than 0xFFFF is code as itself. Every other greater that 0xFFFF is broken in two 10-bits chunks, or-ed with 0xD800 and 0xDC00 respectively. The range 0xD800 - 0xDFFF is called "UNICODE surropgate" and does not contain valid codepoints. So you can have single unicode characters requiring two wchar_t in sequence to be represented and sequences of two wchar_t representing a single character, with code greater than 0xFFFF (typical for CJK - Chinese, Japanese, Corean characters).
2 bugs found. > recompile ... 65534 bugs found. :doh:
I'm sorry for you and for Microsoft, but the one and only entitled to say what Unicode was, is and will be is www.unicode.org[^] The page you linked is a very shame for Microsoft. A technical document like that cannot be written without specifying in the page itself a data when it was written (hey ... they speak about their new amazing Windows NT 3.5 ...) and for this sole fault should disqualify M$ of whatever authority in the field.
2 bugs found. > recompile ... 65534 bugs found. :doh:
UNICODE is actually a set of code-points whose cardinality requires 21 bits. When encoded in sequence of 1 bye is called UTF-8 and when encoded as sequence of two bytes is called UTF-16. In UTF-8 coding may vary from 1 to 4 bytes (and remains identical for code-points between 0 and 127, aka ASCII) In UTF-16 coding may be 2 or 4 bytes (and is TWO for the most of Latin, Cyrillic and Greek characters, as many simplified Chinese). UNICODE==2bytes is a misconception that originated at the time Windows included Unicode APIS using 16bits since -at that time- Unicode specs where not so wide. Actually, reading 2bytes does not necessarily means "read a character".
2 bugs found. > recompile ... 65534 bugs found. :doh:
When you create an object (like a mutex) you can specify a "name". (see CreateMutex[^]). In the child process you can retrieve another handle to that same object with OpenMutex[^], or whatever similar and coherent with the type of object) by giving it that name (that is supposed to be unique at least between all your entangled processes). Note that the returned value may be different, due to the fact the the handle value is an "index of a table of indexes" that is different in the various processes. The documentation talks improperly of inheritance of handles. What are inherited are the objects the handle refers to.
2 bugs found. > recompile ... 65534 bugs found. :doh:
Hans Dietrich wrote:
You can use the
IsWindow()function to determine if the window has been closed (i.e., destroyed).
Although this works in the most of the case, it is not "safe": when a window is destroyed its handle becomes invalid and the is ID (the handle value) can be reused by the system for another subsequently created window. If you don't look at all that while happening, IsWindow may return TRUE, but the window may not be the one you intended. (I mean: "my name (handle) is the same of my grandfather, I was born after his death, and I live in what it was his house. But I'm not him"! But if you send a letter to him, I'll read it as mine and, hopefully, I can understand the misleading only from the context".)
2 bugs found. > recompile ... 65534 bugs found. :doh: