Comments by pasztorpisti (Top 200 by date)

In my opinion you didn't but I've already succeeded in starting flame wars with less "ambitious" statements than "there is not any necessity for a C++ interpreter". I'm pretty sure that such statements hurt the eyes of some people.

Sure. The short answer is indeed that simple but try to put it that way - some C++ advocates will chop off your limbs! :-)

My mind was spinning exactly around such problems. The number of these problems are endless. One of the most serious problems I was also thinking about is manual memory management that is never really needed in practice when you are toying around in an interpreter. An interpreter is the "calculator of a programmer" and even if you need something like "manual memory management" you usually need only an array, the interpreter is not a place for manual memory management that is usually done in order to optimize things at low level (for low memory consumption, better locality, etc...). In an interpreter you don't need tools that are there for low level optimization but in case of C++ you should deal with them and they would cause A LOT of headaches in some scenarios. We have just scratched the surface with problem listing but the number of WHY NOTs is already too high in my opinion to start writing a C++ interpreter.

5ed, seems to be like a shorter version of my answer. I'm afraid in order to be able to really feel the difference in complexity between a C++ interpreter and the interpreter of a dynamic language one must implement at least a simple/small interpreter for a dynamic language first. Not necessarily for an existing full featured language, for this purpose a simple custom language would be enought with only a few features. After that its much easier to imagine how complicated can it be to deal with some C++ interpreter related problems. Even if the goal is creating a C++ interpreter for someone I would definitely recommend creating a simple interpreter for a dynamic langauge as a first project for learning as doing so requires much less time than going the long hard way. Creating an interpreter from scratch for a dynamic language can be done in a few days or weeks but I would estimate the creation of a C++ interpreter to take at least months or years even by reusing existing frameworks and I'm pretty sure there would be a lot of serious problems arising during development (and my guess would be that some of these problems would have no nice solutions because C++ wasn't at all designed to be interpreted - this is why I wrote about "language design problems" in my answer).

Thank you!

Perhaps you should check the original question of OP, in that case you would understand my WHY NOTs. WHY NOTs are usually at least as important as WHYs. If someone is playing around in his free time then a few why nots will not discourage him, especially *my* why nots that are completely irrelevant to the discussion in your opinion. People are often immature in making decisions and forseeing troubles in areas where they haven't got enough experience. Learning about the troubles by reading posts here is a lot faster than learning the same by implementing a complex system in a year or two. Even if you finally decide to implement the system after reading posts and collecting info about upcoming problems then you can design and create a better system based on the collected info. To some extent this is why forums like codeproject and stackoverflow exist.

- What's wrong with using python as an example?
- C/C++ is more verbose than many other modern languages. This may not be a strong point for some people, for me it is in case of one liners. def SayHello(you): print("Hello %s!" % you)
- "Impractical", "separation of declaration and definition" without evidence: My answer doesn't try to be a full answer as that would be too long. Instead I've just listed a few problems that can make people think about the implementation of the solutions to these problems in the interpreters of these languages. The solution to the listed problems turn out to be very easy for simple dynamic languages and they would be more complex in case of a C/C++ interpreter. Of course this requires some practice/insight into the construction of a simple interpreter but I assumed that OP has this.
- Any language can be pre-compiled or interpreted and anything between the two. Even "shell script" languages, I never said its not possible. I just said that both the creation and the usage of a C/C++ interpreter would be more difficult than doing the same with some other (dynamic) languages.
- I would rather spend years of my free time to work on something that I find useful. If OP finds a C/C++ interpreter useful for some reason then it can indeed be a real goal.
- Object files: Depending on the goal of OP and on the actual interpreter implementation to reach that goal object files may be completely useless or impractical when it comes to creating an interpreter. But its not a problem as it is only a tiny detail how OP transfers data between the stages of his compiler. When I mentioned object files I was only brainstorming about easy and roboust reuse of the frontend of some existing compilers. In some cases writing a backend may be easier than parsing object files.

Thank you! "Every problem can be solved with an extra level of indirection" - even the ones I've listed but there are some problems I wouldn't like to deal with. Neither as the creator nor as the user of the interpreter...

+5, I completely agree that C/C++ is not suitable to be used as an interpreted language. I've already created a few compilers, an interpreter, and also a vm. After implementing a simple interpreter for a dynamic language its quite easy to see that some (dynamic and higher) languages are much more practical to use in interpreters for many reasons. In my answer I brought up some very simple problems/examples that show quite well why not C/C++.

If you want to get just pure "Hello World!" then you don't have to send html from the server, simple text/plain would do the job and for that you don't need templating engines like jsp.

Then let's do it, I won't hold you back. Now you have the permissions.

To me this seems to be an impossible-to-answer question. Only you have the environment to debug this issue out.

Actually you are talking about two completely different problems. A stream is an "interface" to separate the user of a "data storage" from the actual implementation of the "data storage" (file, pipe, memory buffer, socket, ...). On the other hand moving around a cursor/caret in an editor is rather a combination of a graphical user interface and an associated data structure that holds today usually the whole data in memory (since we have plenty of ram). Usually an editor uses (file)streams only to load a file into an editor or to save the edited data into a file but many different objects can provide a read and/or write stream interface (even the data structure that is used to hold the edited text for the editor). You may also confuse the "file pointer" of some seekable streams with the cursor/caret of the editor, they are totally unrelated in my opinion but you could create connection for example between a cursor/caret and the "file pointer" of a (memory) stream but a cursor/caret alone is just something that belongs to graphical user interface (GUI) programming of textboxes.

OK, someone please debug/fix the code and let's put a period at the end of this! :-)

A five, although depending on the level of knowledge of OP he may need to read something about what an abstraction/interface means, but I hope not. :-)

I often hear about relationships like "coder < programmer < sw developer < architect" but I have never seen an officially correct description about the differences although I more or less know what you mean. :-) BTW, just take a look at the CodeProject banner subtitle: "For those who code" :-) :-) :-) Maybe this is why we have so many students here with their course projects...

First create your content and get it work with a HTTP server that is proven to work. You can easily start up a test HTTP server on your machine by installing python and saying python -m SimpleHTTPServer [optional_port_number] and this command starts a http server on your machine serving the content of the current directory. When you know that your html file and the images are okay then start implementing the C++ http server that serves the html+image that are good for sure. If you don't understand something from the previous sentences then start learning at least some basics about how the HTTP protocol and HTTP servers work before trying to implement a HTTP server.

Ironically, in my opinion he should know the basics of low level programming also to understand this problem and other "higher level chapters of low level programming" he tries to deal with. One of the biggest general problem these days is that people don't know that memory is just a big byte array and a pointer is an index into it. Understanding this eliminates the fog floating around the pointers of higher level languages and this clear the path to understanding many other things.

Yes, but I don't understand what is the problem here. :-) You include the library and use an interface returned by the library... Quite a common pattern. What kind of implementation is hidden in the library and where the actual config comes from for different implementations is just a tiny detail that can be decided anytime later.

This is quite vague. You need a server with a client library that helps you to write client programs (event consumers and producers). Whether the server runs on a different machine or on the same machine as a service or as a kernel module or whatever is just an implementation detail as well as the actual implementation of the communication channel however I wouldn't use signals for this (as signals were invented for other purposes in my opinion). If you put well designed interface between the server and the client then you can implement that in several ways. For example in my client/server apps I often provide a "null" communication channel that just links the server code into the client to be able to debug the client with an "in-proc server"...

In my opinion you still don't know what you want to do and if you don't know what you wanna do then just write it as a general solution as a client lib + server that uses sockets for communication. Find out what you want. Steps #1 and #2. It has no point of thinking about how to implement "something". If you want to put the "library" too into a separate process as an intermediate layer then just do it but have a good reason for splitting up a solution into so many parts as it has performance overhead. If you don't know how to place these building blocks then you don't know it because you have no requirements. No requirements -> no good solutions as I described previously. Your vague goals are not requirements, they are just too little goals that can be achieved in 100000... ways.

I also added some comments about a use case for detached threads, and meanwhile some thoughts came to my mind about alternative implementations with an silly anitpattern... When you are tweaking the servers you may have to play around with socket options too. You can improve latency for example by turning off nagle you can tweak recv/send buffer sizes although this one usually helps only with high volumes of data... Check out the setsockopt doc pages. RTFM, its boring but needed. :-)

You are welcome. :-) The big question in this case: Can you determine the maximum number of clients? As I see you can. If yes then adjust the number of threads in the threadpool (and also the MAX_CLIENTS constant/variable) to this size, maybe a bit more and you are done. Working with a fixed number of threads is usually better than "creating them on the fly". I can not tell you what is the right solution in your case because it can be found out only by trying different solutions with different setups/tweaks and by measuring the performance according to some parameters that are important for you (latency, throughput, any occasional hangup per client, ...). Actually you should write both a preforked/multithreaded and an async server and try both of them with different setups. In case of short running jobs an async IO server with threadpool (around numcore number of threads) can also do wonders... The asnyc thread/threads are just reading the requests from multiple sockets and they are passing the incoming request to the threadpool that grinds all the requests at most on as many threads as the available cores, maybe a few threads less to give some power for the OS and IO threads... lets tweak it. At the same time when a threadpool job (a served request) is done thent he result can be passed back to the async IO thread that can put the result into the send queue of the socket. Use IOCP/epoll/kqueue depending on the os to do the IO or use a crossplatform library that uses one of these to do the job depending on the platform. What I don't like in the multithreaded version is that if you have for example 100 connections and accidently all threads are working heavily then running 100 or more very active threads on 16-24 cores is not effective. If the serving of the clients is short and can be broken down into short jobs then using async io on 1-2 threads + a threadpool with a few threads is usually the winner. Sometimes with only a few clients (for example in case of a simple http server) a multithreaded server can outperform an async one but this advantage evaporates quickly as the number of clients grow.

The standard library is also crossplatform as boost and the std lib actually ships with the new compilers out of the box. If you don't have to be compatible with old compilers then using std is often a better idea, of course there are some exceptions to this. Anyway, boost is a playground where people experiment with things and many-many std things are often just libs coming originally from boost where it was tested out and became mature. Coming back to your original problem: its actually a classic one and brings up many basic problems you don't even think about currently as I see, I will write more about these as the continuation of my answer.

If you are about to hide the contents of a folder or "mimic"/show altered folder contents then you have to write kernel modules that alter the behavior of directory listing functions. That is far from being an easy job.

+5, there are some really good hints here

+5, that's it. I've used the second approach many many times (win32 api, and dlephi also had such a feature). Messing around with the titlebar is not a good idea especially nowdays that windows has many skins, not to mention the platform independence of your C# code. Messing with hooks is a bad idea in many caseses especially when it comes to customizing the looks of controls, unfortunately windows/comctrls weren't really invented for this.

Thank you! :-) :-) :-)

What is the OriginalFunction you mentioned? Do you try to copy bytes onto the beginning of your hook function? Because that wont work.

Allocating memory and arrays of primitive elements with new is a bad practice in C++. I consider new[] as an incomplete language feature anyway: you allocate an array and delete[] knows how many objects to destruct when you free an array (so C++ stored the array length somehwere - usually on a negative offset) but you can not query the length of the array yourself, you have to store it in a separate variable...

Use new only to create classes on the heap (and maybe if you are implementing low level classes like container templates). In other cases use container classes like std::vector to get the job done. Its much cleaner and also less error prone when it comes to overindexing and the related dreaded heap corruption problems. High level containers do the memory management (and check for programming mistakes with asserts) for you and you don't perform "manual" memory management, its a very-very bad practice.

This is not a socket programming problem but a multithreading problem. Learning multithreading has a steep curve, noone will be able to teach it to you here in an answer. Normally You shouldn't use the same socket handle from two threads. The handle should be used only by the thread that serves the client. If you want to stop the servicing of the client from another "manager thread" then you should signal the other thread to stop servicing, the other thread should receive the signal and as a result it should close its socket and terminate. How do you signal? This is that difficult part, you have to learn multithreading and also some OS specific APIs. There are many good solutions when it comes to multithreading and socket handling. On windows you can find good solutions/tutorials by searching with google for tutorials that make use of the following socket handling functions on windows: WSAEventSelect WSACreateEvent WSAWaitForMultipleEvents

What you need to do is writing a "Paint" custom control that draws the right portion of the image along with the "helper gizmos" of the currently used painting tool (crop selection). You will have to handle the drawing and the input of the custom control yourself to get the job done and "to bring a crop selection tool alive". That can be a lot of hard work and learning if you are writing a custom control for the first time.

The problem OP is struggling with is a common problem. Window state changes (like minimizing/maximizing/showing/hiding - tied to WM_WINDOWPOSCHANGED) are often unreliable and hard to detect and they have corner cases (like different behavior for maximized windows). I've recently fixed a similar hacky code where minimizing/bringing back a window removed the maximized state from its parent (yes, the child window was also top level, dont ask why...) - that bug was also related to WM_WINDOWPOSCHANGED. WM_WINDOWPOSCHANGED is evil, I have fixed tons of bugs related to this and its better to avoid attaching event handlers to it whenever possible (especially because the windows version/window manager related differences).

From the words of OP I suspect that he uses the wrong event to show the second dialog anyway... And reading the question again I don't know what he wants to do. Using PostMessage() to send WM_SHOWWINDOW is also a bad idea, I would use SendMessage() for a more deterministic behavior.

Both STR and arr allocate a char array in a global memory area or on the stack containing the characters on the stack. The differences:
1. arr: arr is an identifier whose value is a constant, there is no variable allocated for the value of arr itself. When you use arr in your code then the compiler "hardcodes" this constant. (Under the hood it isn't necessarily a constant when the machine code is generated for offset independent stuff and when the location of the array is a stack relative memory area but this is the problem of the code generator, from your perspective (from the perspective of the language user) arr is a constant value without allocated variable/storage.)
- STR: In case of this declaration besides the character array the compiler also allocates a char* variable for you and initializes it for you to the address of the character array (to the constant value that is the same value you access with the arr symbol in the previous example). A very big difference compared to arr is that STR here itself is a pointer VARIABLE that you can modify later in your code, you can not do that with the arr CONSTANT.

Another very big difference: the type of the STR and arr symbols. The type of STR is char* while the type of arr is char[]. The difference is often invisible because the C/C++ compilers contain a very ugly *hack* (in my opinion): array identifiers (arr) are automatically casted to pointers in many cases. For example if you say char* myvariable = arr; then the compiler automatically casts the type of arr into a pointer that points to arr.

sizeof also has surprises: sizeof(STR) is the same as sizeof(void*) as STR is a pointer VARIABLE and sizeof(arr) will give you the size of the character array as arr is a character array. However if you declare a function like:
void myfunc(char array_param[])
{
}
then sizeof(array_param) is sizeof(void*) because array parameters are pointers in reality, array parameters are never passed by value even if you specify the exact size of the array parameter!!! You can enforce a fixed size for an incoming array parameter with the static keyword (I never used it, just seen it in a weird example...)

The ugly similarities between arrays and pointers should not exist in C/C++, modern languages eliminated these to prevent programming mistakes but C/C++ will probably keep them forever because of backward compatibility.

+5

The code seems to be OK for me at first sight. If you save the the data into a file and then you load it back (or if you serialize/deserialize it to/from somewhere else) then make sure that the data doesn't change during serialization, for example if you use fopen then make sure that you open the file in binary mode (not "w" and "r", instead "wb" and "rb") also make sure that the data is the same after saving and loading using a debugger. If you serialize then also make sure that there is no extra newline character at the end of ciphertext, check the length of the data too!

In my opinion showing a modal window (e.g.: by opening a modal dialog from another modal dialog) is OK, people are used to this design. Whether it is a good design or not is a good subject for debate: some software, typically "editor" programs like Blender3D have a UI design philosophy that everything should be modeless and everything is just a view to a fraction of the edited data. The input is also extremely practical: left hand - keyboard, right hand - mouse, and the keyboard events always go the the views that are under the mouse cursor. Its another problem that most people cant even place a cube inside the editor when they first open it but still, it provides one of the best user interfaces that facilitate extremely fast user interaction. Still, recently they have implemented a "classical" setup probably to attract more casual users.

Here OP probably has a different problem: He tries to solve a problem by using very ugly hack. When it comes to window messages and their order/occurrence in some specific cases (like "when this and that is maximized") then window messages get totally unpredictable and your program becomes vulnerable to window version changes, and not only windows version changes but also to changing the window manager on the same machine!!! (like aero to classical...) Message orders may change, some messages may disappear in some cases.

No problem, with the "new question" the answer is indeed invalid. :-)

Thank you!

That's true. I didn't think about WPF but that is indeed a case where this probably doesn't work, maybe if the target window is the main window...

+5, your statement holds true but most of the time simply sending keyboard/mouse messages to the target window works even if the target window isn't focused/foregrounded. Some applications switch mode as a result of WM_ACTIVATE/WM_ACTIVATEAPP/WM_FOCUS and in those cases posting messages may not work.

Well, but this question is about C/C++ and in my opinion this technique is definitely not the way to go for OP. He probably wouldn't be able to implement it anyway as a beginner...

In "higher level"/managed languages I simply love exceptions and the idea of aborting with an exception from outside the thread is brilliant (similarly to implementing the program exit() function as an exception) but only in case of safe/garbage collected languages where exception handling is "natural". In C/C++ often even exception usage alone is considered to be unsafe when your call stack contains frames of some 3rd party libraries (that don't expect thrown exceptions/stack unwinds).

I understand your points but I still wouldn't write such software in C/C++. In a managed env it can be OK but even in that case you have to be careful. My experience is that expecting 3rd parties to meet requirements (like not calling XYZ functions) usually doesn't work, sooner or later someone calls one (even if indirectly). Here is how I deal with UNTRUSTED 3rd party C/C++ code that may leak or has to be cancelled (or is buggy): I write a small program that performs the job without any cancellation support and then stores the result somewhere (shared memory, file, send-socket,...). From my main program I run the helper as a child process and when the helper program terminates it terminates with all of its leaks. If I have to cancel the job then I simply terminate the process. This has some other advantages too: your main program can remain single-threaded. Often multiprocessing wins in such scenarios. In linux you can compile the static lib (if it is static) into your main program and fork() does the job elegantly.

As I see we probably won't agree on this. In .Net Thread.Abort is OK. In C/C++ throwing an exception alone is dangerous if the callstack contains frames with variables without RAII pattern and usually not all frames are yours on the callstack so you can not tell whether throwing an exception is OK. I've corrected several leaks caused by throwing exception in C/C++. Chances are even better for leaks if the code makes use of C libraries that can't even make use of RAII. Besides this lets say that I write a thread that performs only math calculations without any api calls, where will the OS interrupt my thread? OK, I will probably have to perform some api calls for example to allocate memory but even this api call can be a call to a custom library that works with preallocated heap. This is already a case where you simply can not interrupt the thread automatically while in a VM you could.

You are welcome!

I see that asynchronous thread termination is nice. The problem is that it can not be implemented in C/C++ in a form that is nice. You still have to "poll" the abort flag somewhere and then you are still there where we are with the bool flag polling even if this polling is just making sure that sometime you call some abortable functions. Its already bad that "you have to make sure". In a managed environment all this can be done by the vm on low level and garbage collection solves resource leaks. This is a double fail in case of C/C++.

My concern is the complexity of the code that increases the risk of the leaks, it is very unsafe and incomplete solution so as a result it can HIDE bugs very well. Normal leaks are usually easy to catch, even in managed code with a nice profiler but leaks that happen as a result of fancy code execution flow is far from trivial to find especially for a threading rookie. I think some problems simply have no elegant/good solutions and I'm afraid this problem in C/C++ is such a problem.

I remember I brought up something like this as an argument against "automatic" exception throwing:
x = new something;
In this case even if the construction of the something instance completes before the exception is is thrown the object reference isn't put into the x variable/container so the object leaks aways. We discussed that we have to mark some intervals in your execution time as "safe places" for these exceptions. In my opinion this marking is best implemented as placing "abort request flag" checker codes into the API you program uses. The posix api thread cancellation works like this, some function calls act as cancellation points. The problem with this is that this solution is far from perfect and requires a lot of coding+api support for a solution that isn't too nice and gives you a lot of chances to introduce leaks/bugs. And what if I don't call any of the functions that act as a cancellation points? In that case I probably have to call the "abort request flag" checker function (or any other fancy functions) myself periodically (that is already an active checking like our current bool flag checker code...). My guess is that in C/C++ it is impossible to solve this elegantly but I'm not surprised about this, C/C++ is not the language of safety. :-) I'm not concerned with thread context APIs, even if we had the perfect crossplatform API for context switching this technique is not trivial to implement (where do we put the cancellation points?) and it is terribly unsafe in C/C++ and provides you hundreds of possible ways to hide bugs from yourself even if you are an expert in multithreading.

Companies with massive amount of data and money can by massive amount of computation capacity. If their data grows exponentially then their computation capacity has to follow or they have to improve/modify algorithms/methods if possible.

You are quite right about the separation between the actual problem solving and the handling of thread/task cancellation.
I remember we were talking about this technique at least twice in the past. The concept itself is brilliant but the usage of this technique in a language that manages resources "manually" like C/C++ throwing an unexpected exception results in tons of resource leaks. I think it isn't surprising that the technique is implemented only in languages with garbage collection. In C/C++ you have to deal not only with the problem of storing everything on the stack with RAII (you can not force this, someone will sooner or later will place a raw pointer there...) but you have to put be able to enable/disable the exception - I remember we were talking about this, and these exceptions should be thrown by api functions that check the "Abort-Request" flag (similarly to the posix thread cancellation). The implementation is not too difficult (very hard for someone unexperienced in threading) but it would be a bit dirty (checking abort flags here-and there and making sure that you call at least 1-2 functions in your thread with abort check) and yet unsafe. I wouldnt like to use it in a c/c++ project or with any other language that has no garbage collection. In a C/C++ application I would go with message passing whenever possible and signalling with a flag if I want to "send a message" to a "long running job". C/C++ was designed for bare metal plumbing and unfortunately implementing this technique properly isn't possible, in my opinion it solves a problem but brings a lot of other problems.

Why would you do runtime type checking when you can do compile time check that is much better? There are cases where the only possible way to go is runtime type checking of course but that is rare and can be avoided in most of the time. I use dynamic type checking usually when performance isn't critical and I can save time by writing code that does runtime type checking to save myself time by not designing/writing the code that does the same without runtime type checking. I do this usually in experimental research (throw-out) code only. In a lot of cases runtime type checking can be avoided using design patterns (for example visitor pattern) but you need even this one rarely.

Runtime type checking the incoming data to create other dynamically handled objects... Sounds like a double-wrong solution...

Lets find out a few solutions that work in theory and then create some (an) initial implementation for measurement. After some time its better to start writing code instead of guessing what would work and what wouldn't. You can gain useful experience even if you fail in a lot of cases. Of course starting to implement something that doesn't work in theory has no use.

I'm quite out of context by now and I simply don't understand the database related stuff and the complications around that part of your problem.

There is another very important thing: The size of the job to pass into a thread pool or to upload for processing with cude is very important. The size of the job is usually a candidate for optimization. pulling out a job from the queue involves synchronization and the more jobs you have the more synchronization you have. On the other hand merging/splitting jobs can effect the upload/download time with cuda depending on the kind of the jobs, ... try these things.

Thank you!

+5

EDIT: sorry, just realized that the keys here are arbitrarily specified pieces of text. What you say is right but you should mention that the keys must be "specially forged".

A non template class can have a template ctor, please see my answer/example. You can not specify the types with <> but the compiler can automatically find them out from the actual ctor arguments.

These are different kind of hardwares for different purposes, not to mention that x86 and x64 processors have a lot of inefficient heritage from the past. On the other hand you are still "thinking in threads" instead of "thinking in jobs" and "thread pools". You have things to compute, you split them up into not too small and not too large pieces, you put them into a queue and then you let the threads of the pool to pick the jobs from the queue. This way your implementation runs well regardless of the number of threads in the pool and you can easily tweak the pool at runtime to have the same number of threads as the number of cores. Starting a lot of ("random" number of) threads and letting them to fight for cpu time is simply stupid in case of computation intensive threads. By the way, GPUs and compute engines also work as I described my job-queue/threadpool example: You upload a lot of small jobs to the hardware (for example drawable pixels) and then the hardware processes all of them with whatever number of threads it has. Why do you want to "manage" it from outside from your CPU? All you have to do on the CPU is cleverly split up the jobs and upload them + download the results. Meanwhile the CPU can perform other tasks.

If you want to eliminate global variables: A global variable is nothing more then a "few bytes" of memory on a fixed offset inside the memory address space of your process. The address that holds your data could be anywhere else, even on a dynamically allocated memory area but in that case you have to pass the pointer as a parameter to both threads. On the other hand you have to make sure that you handle correctly the ownership of the dynamically allocated memory area. If you know that that one of the threads is destructed earlier than the other then you can simply put the deletion of your dynamically allocated memory into the thread that lives longer. Or you can give the ownership of the memory area to a third object that lives even longer than your two thread objects (for example an app object). This way you can guarantee that when the deletion/freeing of the memory area occurs only one of the "owner" objects/threads is alive so it doesn't happen that you free a block of memory that is still used by another thread. The dynamically allocated memory area can be anything ("p = new bool" :-) or a new struct).

I don't have experience with CUDA but I know that its usage is very similar in essence to that of some other platforms used for massively parallel computing. Generally in case of optimization and of course also in case of multithreaded optimization you can not omit/skip one terribly important thing: always measure the actual performance of your program on the ACTUAL/USED PLATFORMS/HARDWARES. Of course it is important to write the code well algorithmically but on the other hand your main logic has to distribute the computable tasks well to make efficient use of your coputation capacity. In a machine with CUDA you have several CPU cores and GPU cores. If you write your code for CUDA only then your CPU cores will only upload the computable jobs/data to the hardware controlled by CUDA and then the CPU cores just wait for the CUDA api to finish. When CUDA finishes you have to download the results. Upload/download also has a cost. If the upload/download cost is near to the cost of computing the task on CPU then it isn't worth performiing that small task with CUDA. To measure the times - to "profile" your application - you need the right tools. You should search and find the tools that can monitor all of your processing units including CPUs and GPUs or any other things. CUDA has such tools. Again, there is no golden rule when it comes to optimization. Its just a dream that you write your code along predefined guidelines and then it runs "optimally" everywhere. I work in the games industry where doing optimizations happens quite often. If your application has to run "perfectly" at least on iPad4 and some specific Android devices then you have to profile/measure your app on these hardwares and you have to fine-tune your code and job distribution logic on these platforms. if you app has to run on a PC with 8 cores (3Ghz each) with 4G ram then you have to optimize your code for this hardware. If you optimize your program for a specific hardware then it will probably not perform "optimally" on hardware that less from some of the resources of your original target hardware you performed the optimization for. In case of games for example it isn't rare to balance between CPU/GPU to "run the sh*t out of the hardware". You measure how much CPU/GPU is used and if you find out that you usually have some free idle time on the CPU (on your target hardware) then you may want to offload some tasks from the GPU to the CPU (several tasks can be performed on both CPU and gpu, for example character animation/skinning). Your application is near to optimal if it uses all cores near to 100% without stalling on any of the threads. In practice this is very hard to achieve especially if you have multiple target platforms/hardwares.

You are welcome! :-) Happy New Year!

Depending on the structure of the PE file this isn't always possible in a clean way. Usually in case of executables built by popular linkers this is somewhat easier. I wouldn't be surprised if the winapi resource functions (BeginUpdateResource and its friends) wouldn't be able to do this in all cases (correctly). Several years ago they didn't always work. In a few cases I've done this kind of stuff manually with hex or pe editors. Some related editors and libraries can screw up virtual address ranges by creating overlapping sections in the virtual memory address space of the process so the resulting binary might not work.

Thank you! Happy New Year! :-)

Thank you! :-)

Thank you! And agree.

Thank you!

Agree, no one can escape fighting a few dragons themselves before becoming a hero. At the very beginnings I mostly created my own stuff (and the total lack of internet probably helped in this a lot). Today I think it doesn't consume a lot of time and energy to check out the available solutions even if all we do is just a shallow checking of the interfaces or public interfaces. Sometimes this gives some really good hints when designing our own interface. EDIT: of course reading other's code was quite uncomfortable for me too at first. That's a "skill" that must be gained as early as possible. Lazynass can be a big enemy in this case... :-)

You are welcome. In my opinion the practical solution to your problem is still just a pure interface. Even an interface can incorporate some simple patterns. For example if the interface has a simple method that starts a background operation (like sending a message/request over the network) it can still have an optional parameter that is a listener interface/object that will be called when the operation finished (just as a simple-stupid but practically often used example).

When you get out to the wild you will see that practice so much different from theory in a lot of cases. Instead of stuffing your head with patterns they should teach you with real world examples. Good luck with your course and focus on actually solving more-and-more problems to gain experience, that's what makes a good programmer and not patterns knowledge.

I my opinion the most important thing is clear separation between modules with clear interfaces. A typical codebase often just grows and adding some new critical functionalities often appear as a dirty layer on top of what we already have (because the blurry requirements and unknown future, and quickly adding "triable things" with shortcuts). When the "final form" of the feature is more or less known then a good programmer is able to remove the added dirty layers (the result of the heavy plumbing) and incorporate them without all the dirty tricks and shortcuts by keeping the nice modularity and interfaces. In my opinion a lot of programmers fail in this. I treat those who can do this as "exceptionally good". Some companies don't spare the time to cleanup the mess left there after plumbing (time and $) but good programmers navigate more confidently even in mess as they more or less see how should it look like. There is no need at all for design pattern knowledge to be able understand other's code and to create well separated modules and/or clean interfaces. What I would recommend those who want to learn patterns: they should rather try to become good enough to write clean interfaces (even an interfaces can be screwed up badly!). I've met a few interfaces already and when the protocol (the rules of using the interface, possible func call orders, etc..) isn't clear (especially if this is spiced up with total lack of comments) that can be terrible even if we have "the interface". So here when I use the "interface" word it shouldn't be treated literally (just like patterns).

:thumbsup: :-) :-) :-)

+5, I agree again. An interesting thing is that I've already met a few exceptionally good programmers who didn't really know extensively about patterns but still wrote great code. An experienced programmer uses the good constructs wherever needed. This fact is somewhere a proof of your statement and my opinion that patterns are rather to name "complex software constructs" to speed up communication between developers. Of course patterns can be a good learning source for the beginner.

Exactly. Reading the question immediately reminded me about some monsters created by "pattern magicians". In my opinion patterns mainly exist to speed up communication between developers and not for actually "building the whole software from them".

Sure, its comfortable and good idea to use a browser plugin like livehttp or firebug.

You could use wireshark to capture the sent messages between your "server app" and the browser. It has a "Follow TCP Stream" functionality that would give you extremely helpful info to understand whats going on.

+5. This is the correct explanation but it will need some extra effort and bit twiddling from OP's side to understand for sure. It reminds me of explaining text encoding. A lot of experienced coders get confused that the text itself is just a binary blob and encoding matters only when you try to interpret it somehow (for example by iterating over the unciode codepoint sequence it describes in the text renderer).

+5. The correct user feedback is essential in all cases but many programs behave incorrectly from many aspects. One thing I really dislike on windows is popup dialogs coming out of nowhere in front of my focused window and receiving/processing input events immediately even if I wanted to send them (half second ago...) to the original focus owner. One good example to this is Total Commander background file copy ("Do you really want to delete these readonly files???"). In case of network connection (similarly to many other cases) I prefer to use a modeless status bar that shows the state of the communication. Another thing I like is using colors (green/red) to indicate status, this takes basically zero effort from the user's side to recognize things.

Of course. :-)

5.

+5, but be careful saying that "the tree uses very little storage". Depending on the scenario and the allocators in use trees can extremely fragment memory while a simple yet effective hashmap is only 2 arrays. Most of the time I use only hashmaps and a special kind of ordered map (built on top of an orderedset) that is an array that is always sorted. Depending on the frequency of different operations and the number of items trees may become the better solution but in my opinion that is relatively rare.

Thank you!

"First of all, the best and most radical method of preventing thread starvation is not writing code."
:thumbsup: :-) :-) :-) Not writing code is what I usually advice to avoid bugs...

Run the program from a debugger. In that case the runtime error will give you the chance to convert the runtime error into a breakpoint. If the program crashes only in release builds then your job will be more difficult depending on the code generation/optimization settings you used to compile the program.

Thank you!

If you fix everything I mentioned above then it will work. If it doesnt work then you havent yet fixed everything. It works fine when you debug it because when you debug the OS has enough time to empty the send buffer and to fill the recv buffer of the socket handles, when you don't debug your program is fast enough to encounter half filled buffers that you don't handle in the code.

Instead of monitoring the traffic you should debug the state of the client and then the state of the server. Its most likely a bug in the networking code. Why didn't it happen with VC++6? But there is a huge difference between the code generator of VC++6 and VS2008, the latter is much better. Networking bugs are often multithreading related and multithreading related bugs can easily be dependent on timing, and timing can be dependent on the speed/optimization of the code. I remember that a few years ago I had a multithreading bug that appeared extremely rarely in debug-compiled code but it almost always happened in release builds. The reason was probably timing and the performance diff between the code of the debug build and the release build.

Browsers are not the only http clients. ;-) Of course in this case the client is probably a browser but for some reason I associated to a http client built into a non-browser program. Probably because I have worked on such projects quite often in the past few months...

A web browser is (an operating system) a platform... :-) I wouldn't start writing another one besides the existing ones unless I wanted to dedicate the rest of my life to it.

In worst case you write a simple http client that suits your needs on top of TCP. Writing a http client on top of TCP is very easy if you don't have to support all http features. An easier solution is searching for a java/C/C++ client depending on the language you use.

You are welcome!

There is a lot of cpu and memory overhead when converting data to/from string and it usually multiplies the network traffic too but these are the only issues (that can be serious in some cases). It is a lot of waste but in case of a simply home/intranet application that is not cpu intensive and doesn't make a lot of net traffic you can go with strings.

:-) :-) :-)

Thank you! Lets share the virtual five, the tip is yours after all! :-)

EDIT: And we forgot to mention that a 3rd party module can have antidebug/compressor protection so the user may have to use IDA to fight against these before decompiling...

To my knowledge that is the only suitable tool. OP should know that decompiling an optimized binary with lots of inlined functions can look much different than the original source (even if it does the same). But at least it will be much more readable than assembly listing.

You are on the confused side. Any ttf font files are allowed to contain any number of characters from a unicode table. Most font files are incomplete and contain only a part of the unicode table/character set usually for a few countries. Not too long ago we needed a font file that contains a lot of fonts for most languages (for mobile devices) and android has a fallback ttf font that has a lot of characters from the unicode table if you need one for testing or for some other purpose.

+5

Before the .Net Thread.Join using the term "join" was a good word to make a distinction, it seems I have to find something else... :-) In my opinion joining a thread more than once is also useless and redundant feature of a threading api, every kind of threading code can be put together perfectly just by using the more strict join semantics (usually only the pool (the thread creator) has to join a thread).

I'm afraid we think about joining differently. Since I mostly do crossplatform programming I always use the stricter definitions and intersections of APIs. On windows it is really like any other synchronization (waitforsingleobject on a (thread) handle) followed by closing the handle but with pthread_join it is a bit different, you can (and you have to) join a (non-detached) thread exactly once and what this join does is basically like a waitforsingleobject+closehandle on windows. Of course you can still extend this interface with some extra code (for example with a condition/event + lock) to simulate the windows behavior. When I said "joining" I though of this as the last step of actually waiting/destroying the thread (with the more strict posix behavior). Of course you can put in waitable synchronization points to any point of the thread lifetime (including thread ending) but these points in my code are handled usually by events fired by the tasks/jobs executed by the specified thread. In my vocabulary thread joining is the end of the thread lifetime.

When I think of thread ownership I always think of the thread that actually joins the thread. :-) However in my design this is always the same thread the worker. "Thread ownership" is indeed something I use as an extra restriction because my observation is that it helps creating better design and it doesn't sacrifice any effectiveness of your threading code. Usually it doesn't make sense to create a thread on thread X and then joining it on thread Y. I often create two thread pools: One for short jobs, this pool has "num_core" number of threads. And another pool for (non-cpu-intensive) long jobs (like dir change listener). This latter "pool" runs all tasks in parallel and may have a minimum number of precreated threads (but it isnt necessary, it hides thread creation even with zero precreated threads). I never understood why do people want to put these two functionalities into one pool (cant they decide whether a job is long or short???) and this makes the pool unnecessary complicated and "undeterministic" (with a "manager thread" that tries to find out when to spawn a new thread...)

Thank you! :-)

+5, Agree.

If you want to learn it then it will unfortunately take at least months but rather years to understand it well and to get used to the patterns and their application.

+5, the answer is quite obvious. My experience is that "thread ownership" seems to be a quite difficult topic for most threading rookies. Since most multithreaded programs work with a fix number of threads I often recommend people to start these threads from the main, and then stop them before returning from main (before exit). A few sleeping threads don't hurt. This approach immediately suggests the usage of some higher level constructs like thread pools or message-processor threads created at program startup and these immediately hide the the usage of join. Starting and gracefully finishing threads in the middle of program execution is messy and beginners just make their own work even harder with that.

+5, probably a lack of knowledge of networking basics... (ports???)

Thank you!

To me this seems like a special case of physics simulation. If the physics system supports this then you can set up objects so that they seem to be "ghost objects" to each other that never collide.

5.

+5

Suggestion: As a first step write a list about the features/functionalities you want to see in your program and start programming. When you encounter a difficult problem that can't be solved easily with google then you come here and we help in it. Write the program in whatever language you feel most suitable/comfortable for the job (based on your current knowledge), if some parts of the software need low level programming then you can still easily connect C/C++ with java via jni...

Quarantine usually means moving a file into a folder and providing some mechanism to avoid execution of code in the file but still preserving the contents of the original file if you choose to restore it later. Avoiding execution: very simple mechanism can do the job, for example just renaming the file, and/or base64 (or whatever) encoding its contents just to name a few primitive methods. Of course depending on the seriousness of the antivirus software it may put special protection on the folder like hiding files in it with a driver or making processes unable to open files from that folder...

Quarantining is not a well defined operation, you implement it in whatever way you like.

Thank you!

+5, this is very important in case of C++. I've read that on some older windows versions killing a thread from outside with TerminateThread() caused leaks even on OS level.

Does the dialog have a parent wnd?

"only" +4 (to counteract the 3 and) because you forgot to mention that he should probably learn both. :-) Both can be used to create games, communication related programs, both involve a lot of old and new technologies and both can be used at corporate level.
If someone learns android then he learns a lot of generally useful knowledge that will be useful in the future in many other areas: for example Java programming and maybe C/C++ linux programming if it involves some native development.
php: an intermediate/skilled php programmer have a grasp on how http and http client/server software works that is relatively "old technology" but the world is full of it so it is very useful. But even Android developement can require the learning for example http if a program that has to be written for Android needs it. These areas can have significantly large crossections if we delve into the details...

If you spend a few years (3-5) in the industry and you spend that time to gain knowledge you will see the big picture and you can easily change to whatever area you like. After gaining the basic knowledge you can easily switch to another area within half to one year but currently it has no point to try to become better by reading our "useless" answers about this topic. The best you can do is spending a few hours on your own projects regardless of the technology they involve. Yes, sometimes finding an interesting topic is more difficult then spending a few hours a day with them. Besides doing regular programming always try to read some good technology articles/blogposts. Good programmers have knowledge that peaks in a few areas but they also have generally useful/good knowledge in a lot of other areas. Having tunnel vision and saying "Android only" and "php only", "which one?" is not a good thing. I'm not an Android programmer, I'm not a php programmer but I could write you relatively good Android code and php code because of my generally good programming skills and more or less Android/php experience. And maybe the most important thing to master: thinking efficiently and being able to prioritize and decide what is most important! For you the two most important things are:
1. having enough scores for your final year project
2. spending the next 2-3 years by gaining valuable knowledge in at least a few areas of programming
Warning!!! Many programmers, especially beginners spend several years by doing almost nothing. Doing the same and same things again and using only your existing knowledge to get the job done if it has to be done often doesn't help in becoming better! Some programmers never become good programmers! Guess why...

I would say that the desktop is a graphical user interface between the user and the whole system. The operating system itself is a big collection of things that optionally contains a desktop too.

Not a question.

Thank you!

Thank you!

Here are the parts of an URL: URI scheme/Examples.

As a programmer the more you know, the more experience you have, the better you are. A neat hobby project is more interesting for an interviewer than a usually boring final year project (of course there are exceptions but that is rare...). If you are good and you can prove this by answering my questions, then the job is yours! ;-) To get a job as a programmer you don't necessarily have to have shiny projects (its good to have 1 or 2, a good programmer can usually show at least 1-2 hobby projects) but you simply have to be good and you have to enjoy it (to become even better).

Very well said. Enthusiasm is the most important because one can not become a good programmer without that.

There is no "best opensource tool" for making "windows applications". "Windows applications" is a huge topic in which different kind of programs are best written using completely different dev envs and languages.

I would stick with C#.

One thing that is bug for sure is that the data size must be specified in bytes and not in number of wchar_t characters so you have to use wcslen(data)*sizeof(*data).
Use wireshark and its "follow tcp stream" function to check out what has actually been sent over the wire.

If you know encodings and basic C/C++ programming then you wouldn't be here with these questions.

In order to be able to use C/C++ language and a compiler correctly you need somewhat "lower (memory/byte) level" thinking. Its very easy to write a program in C/C++ that compiles with a breeze but is hell incorrect (not semantically) and *may* crash occasionally. An example is returning a reference or pointer to a local variable (declared/defined on stack as an auto variable).

You won't understand the real purpose of these types without understanding encoding (like windows1252, utf8, utf16, shift-jis, ...) of (unicode) text first.

You have been given a task that you are supposed to be able to complete. If you fail then retry the course with more care next semester.

+5, a windows message is indeed a simple and viable option in many cases.

Then it's an easy job for you. What is good in cgi is that you can replace/rewrite a cgi "script" in any other language if requirements change and you can have several cgi scripts in different languages. To start/stop programs and send signals a native cgi will do the job well. If a http server doesn't support cgi then you can implement your own "servlet"/request_handler that adds the cgi functionality to your server but I wouldn't recommend this as a first step. :-)

You are welcome! What you should learn besides cgi is the HTTP protocol at least on a basic level. In your framework there will be probably some buttons on the webpages along with some input fields (basically a form). A typical pattern you will use: when the user presses the button on a form then the browser sends the field values of the http form to the page/location your defined for the form as a POST request. Then your cgi executes and typcially you want to return a 303 (== See Other) status code to this post. But go and learn a bit more about HTTP, its simple on an intermediate level. To implement a basic control panel just go with cgi and with C++ if you like that the most. There are some helper libraries for cgi for any language (even for c/c++) that can parse the incoming parameters for you (because that is a boring thing if you write a lot of cgi scripts). And again, learning cgi and http is not a wasted time, it is useful knowledge even if you later learn a few frameworks on top of this. And besides this knowledge isnt as volatile as knowing some frameworks that morph into something totally different in 6 months. cgi and http ares the same as they were 10 years ago.

With cgi you can implement even dynamically generated websites, you can use cgi for any requests even for those that retrieve your html pages not only for those that process form posts. After html and cgi if you want more fancy stuff then learn client side programming (javascript) and maybe ajax if you want dhtml but this is optional if all you want is a basic control panel.

These are relatively simple functions you can implement in any of web development frameworks. Even without frameworks depending on how sophisticated solution you want. For example without dynamic content generation and without dhtml you can do the stuff in pure html and you can implement the server side request handler logic as a set of cgi scripts, each cgi script can be written in ANY language (including C/C++). All you need is a web server that can server your static html files and can start your cgi scripts when the user requests something from a specific path of the server (like /commands/restart_server?id=5). This is solution #0. If you want to generate the content of your html files dynamically on server side then you can do that as well by writing your main page as a cgi script. This is solution #1. To be honest I think getting to know cgi scripts would be one of the most useful things you could learn as a first step! cgi can be combined with any frameworks and cgi alone is enough to perform everything you need. It doesn't have fancy features like some other frameworks like putting together fancy user interfaces with a few lines because cgi is just a simple stupid protocol/technology but you should start learning from the basics. And again, in my opinion cgi is ONE OF THE MOST USEFUL THINGS in web development!!! To write a cgi script just use your favorite language. How cgi works in 30 minutes: You set up your web server to execute your cgi script when a request comes that matches some criteria, for example its path is /command/restart_server. Then the web server executes your script and passes the parameters of the request in environment variables to your script. Then your script interprets the request parameters and outputs the generated response to the stdout that is captured by the server. Thats it. Find a simple stupid web server that has cgi support and read a basic cgi tutorial becuase it is as simple as I described.

Very well said. :-) Unfortunately clever is not always strong enough... Two other variants: weak and clever, strong and stupid (probably most dangerous).

The biggest problem is probably the assumed meaning of these advices/words sometimes even by teachers and they give this false knowledge to a new generation.

My opinion:
reusing: sparing time, additionally reusability forces nicer lib interfaces
reinventing the wheel: taking a look behind the curtains, learning whats inside the black box

Even if you write a partial framework that doesn't replace an existing one you gain extremely valuable knowledge. In some cases I discovered that some opensource libs have extremely bad quality after rewriting the same functionality with much less code, less bugs, and nicer interfaces. One of my collegues always says that most opensource C/C++ libs born in the sandbox of some relatively beginner university students who have a lot of free time, thats the reason for the lack of quality most of the time... There may be some truth to this.

Reusing and using third party is sometimes not an option but a mandatory thing as you wouldn't have the time to maintain and develop lot of third party libs especially if their functionality is dynamically changes or follows RFCs... Unfortunately in an enterprise environment most libs fall into this latter category.

Many good points and wisdom there. Fortunately my current job allows me to write a lot of fancy stuff because the whole codebase is totally platform independent (win, osx, ios, android, win8, emscripten, ...), full of (memory usage/performance) optimizations and "wheel reinvention" with good reasons. But if I think it over what we do here is just writing the X. iteration of what we have already written many times at home and/or in other projects, just with some customizations and/or improvements over the previous iterations. Quickly collecting the joyful things that helped me to become good programmers the list would be something like:
1. asm coding on my 286/386 and later reverse engineering on win32
2. using/understanding the OS related API and techniques/algorithms I've learnt while I was doing #1
3. reinventing wheels (like network engines, rpc/rmi lib, serialization, ...)
If someone tastes programming today at a typical university he is usually taught:
- that low level coding knowledge is "useless"/not too useful today
- how to use/glue together existing libraries
- NOT TO REINVENT WHEELS, ONLY REUSE CODE (without understanding whats inside, big mistake in my opinion), code ruse, code reuse, code reuse - maybe its just the newcomers who misinterpret this... code reuse is good after all but being too serious about it even at home...

After checking the above lists maybe it isn't mistaken to say that today's new programmers are often not instructed well. A lot of sources instruct them to learn only the boring stuff because only that is useful to serve the needs of an enterprise environment and only a few of them find a better path. Still, even the best enterprise developers usually come with a "wheel reinventing" background being able to see behind the curtains to some degree (for example being able to assume the behavior of the caching of an ORM system or something similar...).

To some degree I feel the pain of the author as I've worked for companies that glued together java libs/tools and it was a source of endless boredom for me. On the other hand you can indeed have fun in programming (in worst case at home) but depending on the field of programming you enjoy working on you may extremely limit down your job opportunities and your earning capacity.

Are these (the exe and the dll) reside in the same process? I can not decide which one is your scenario:
1. Your exe tries to communicate with another process/exe that loads your DLL.
2. Your exe loads your dll within the same process and you just want to perform function calls from the exe to the dll and vice versa.

Yes, you were talking about the multithreading thingy. A bit of nostalgia about good old programming related things reminds me of this blogpost: Programming Isn't Fun Any More.

I'm not familiar with Ada but reading the wiki paragraph about Rendezvous it seems to be just another (language supported) pattern that is quite easy to implement on top of threads that operate with a blocking message queue. I think thread pools and threads with tasks/jobs are the mother of almost all other patterns. :-)

Absolutely true. Multithreading is basically a possible implementation of an async task, and multithreading is always at hand while async APIs are rarely available and even if they are present the interface is always different as you said.
Still, for some reason thread lifetime management and inter-thread communication seems to be something that is impossible to understand for most. Often, the only synchronization point should be only a message queue, sometimes 1-2 shared "databases" and thats it but people like pain in the ass and force themselves to use shared variables... Thread lifetime: maybe the simplest solution that is viable in most cases is precreating threads at startup and deleting them at exit. Instead of this they find very exotic ways to spawn/finish threads.
I've just recalled the last gui+thread related question on CP, the guy kept posting comments/messages to me for weeks relating a very simple background worker thread and he was unable to put together a good solution while step by step instructions were available for him from the very beginnings.

I remember that I had to install separate drivers on windows to force loopback connections to go through the network stack in order to be able to capture it. Loopback connections are indeed optimized and work much like pipes. Thinking it over again, multithreading is probably needed (and also buffering) if we want to create a transparent solution that runs in the background while the app uses its original code calling stdio functions (like getchar). Without threading the app code should actively handle the interprocess communication too that would be less clear.

+5. If the solution is linux only then I would advice using multiplexing (select) with nonblocking file handles instead of multithreading. Both are difficult to use but learning/using select tends to be easier for most programmers. Sockets is indeed a good replacement for pipes and its more flexible in exchange for a bit more lines of code.

:-) :-) :-) This is quite typical!

The first thing that comes to my mind is that you are trying to solve a problem in the wrong way. If you still insist on solving your problem this way without sharing the actual problem with us then I think sending the input stream with pipes to the other processes is the way to go, but even in this case buffering and blocking pipe write operations can be a problem depending on the actual scenario.

+5 for the tips - I was lazy to write them :-)

In case of OOP and procedural both are pretty important, maybe if we spoke about some declarative languages...

5.

+5, Agreee. Data vs code, this indeed makes no sense...

It is time to learn how to use a debugger. Learning this would probably be one of the best investments for the future.

The C++ standard forces you to define the static class members this way but if the language allowed then it would be perfectly possible to solve the definition inside the class declaration, the complexity of the solution (technically) wouldn't be more than that of the inline functions/methods declared in the header files... Why doesn't C++ allow you to do this??? I don't know but considering that C/C++ have the heritage of strictly separating declarations/definitions into header and .c/.cpp files I'm not surprised about this.

I guess OP meant *definition* and not declaration (and definition inside the class declaration to be precise...). It is sometimes a problem that you have to define it in a class and you are not allowed to do so in the header. To circumvent this one can use a template with which it is possible to put the definition of the static member into the header file.

+5, I would recommend OP reading at least some basic threading tutorials before proceeding with writing multithreaded code...

Then write one or search one with google.

Depending on your development environment I recommend using a good C++ IDE where the editor and the debugger is integerated. A good example on windows is Visual Studio, another free and crossplatform solution is code::blocks. use google to find tutorials about debugging in these IDEs.

I think the if statement works perfectly but you have a bug. Debug it. If you don't know how to use a debugger then learn using it or simply use the poor man's debugger: logging/printf.

Does you device support multitouch?

The problem with this is that a beginner may be unable to put together the build env, if something is wrong then troubleshooting is more difficult without background knowledge. Plus copy pasting the source code of the control system of a space rocket is not fun as a beginner. Of course if it comes to image processing then hw acceleration is the best. But here, taking a look for example at the file handling code I think that OpenCV can wait...

Thank you!

Most c++ compilers on dos have a library with which you can specify incoming parameters in registers an then you can perform an interrupt or long call and then you can read the result registers without writing assembly. This doens't mean you don't have to know a bit of assembly but you can at least do it in C/C++ without bothering with asm and linker magic. If you are very new to C++ then I would forget about this solution. Maybe someone knows an easier one.

I have always used int 16H of the BIOS for that (usually with ah==0). It depends on your compiler how to fill registers and execute interrupts with it.

"junk knowledge" :-) Sounds good! Agree with the latter statement too. Unfortunately more or less noise is present in every area and in some cases it's hard to decide what to extract as fundamentals. This is especially true in case of a beginner in an area, you know, there are so many tutorials and everything you read on the internet is of course true! :-)

Agree.

I know, there are a lot of questions that need mind reading. Unfortunately this one doesn't seem to be one of those. She didn't even read the rules before posting this here. This question requires only a few days from the life of OP reading a C book or C tutorial like http://www.cprogramming.com/ and after reading one of these the question simply evaporates by itself. This would be the purpose of the class she attends and not going to the forum where some programmers tell her about a few C language constructs that are absolute necessary to put together the homework - this is not learning. I want to see her making an effort before we do. She tries to lie us but the biggest problem here is that she lies herself too...

+5, btw, isn't this a good candidate for "Report/Not a question"?

So you want someone to translate whatever language or pseudo code or copy-pastage for you to C because you can't do it? This site is here to solve "serious" problems not for writing the homework of students. This is far below "serious". If you want to complete the class then start learning C programming quickly or change your profession. With this attitude you will never become a programmer.

+5

To me it is suspicious that you are using a 256 color palettized image. If this is the case then you have to read in and use the palette as well as an input and when you write out the grayscale you have to write out a new palette as well. Send use the info that is dumped by your program, the dumped header info.

Are you serious??? :-) :-) :-) Take a look at the code...

An unhandled (and even a handled) exception in C++ (and in most other non-garbage collected languages) can be extremely dangerous. Maybe this is one of the reasons why some C++ projects avoid using exceptions as an error handling mechanism. An unhandled exception basically returns from many function calls until someone handles it unwinding the whole callstack including the stack frame of each function (that contains the incoming params and local vars of functions). If an exception is handled nowhere (and ACCESS_VIOLATION is rarely handled because it isnt useful to handle it) then the exception unwinds the whole callstack. Result: The local vars and incoming parameters of the active function calls (at the time of exception) simply get destroyed (in case of ACCESS_VIOLATION this unwind/destroy doesnt happen if your code is compiled without SEH code generation). This is not a problem in case of local vars and params that don't need extra steps to destroy like in case of int variable or in case of complex classes that are on the stack by value (RAII: if you have SEH turned on) but this can be extremely dangerous for example if you store FILE pointers or handled or other raw C pointers on the stack because those simply get leaked, the exception returns and the rest of the function that would release these handles/pointers will never get executed. If your code is compiled without SEH support then even RAII is useless and you leak even more things.

A pointer is "just an integer" that is an index into the memory address space of your program. Its an "index" into the memory and this "index" tells you the location of some other data in memory that usually has some type. Sometimes this type is unimportant, for example when you call a function that writes out data into a file, in this case the file writer function receives just a void* and the size of data in bytes so you can easily use it with any typed pointer.

Declaring a pointer as typed or untyped is just giving some language dependent information for the compiler on how is the programmer allowed to use the pointer and to make it easier for the programmer to generate code that uses pointers to manipulate complex data (like in case of a pointer to a complex structure). Learn some assembly programming and after that you won't be surprised about this, you will immediately adore typed pointers/references and the work they do for you.

"and can be reassigned to other pointer type"
This is true only in case of C, in C++ a typed pointer can be set using a void pointer only by explicitly casting the void pointer into a compatible typed pointer.

But this is a multicharacter literal and not a string so it is basically an integer. Those are single quotes not double quotes.

EDIT: This can be done with short (max 4 byte long strings) but it would be a brutal antipattern that exploits compiler dependent behavior so the answer is indeed a big NO so +5 from me.

I've did client side web development mostly in pre-css era for a relatively short time, that was enough for me. While learning it I had the feeling that most of the time was consumed searching for the intersection of the functionality of the actual version of the most popular browsers (that is a very volatile and "useless" knowledge). I've decided to spend my life with more valuable things. Despite this I often use HTTP servers and HTTP protocol as a communication channel and sometimes I put together ultra-simple debug/utility intranet sites but I support only Firefox and these sites are so simple and ugly (focus is often exclusively on usability) that they often work with any browser.

Sure! :-) (Teach yourself Multithreading in 24 Hours..., no in 10 Minutes!)

You are welcome! I hope you have memorized ** now as an antipattern! :-)

+5. SwingWorker is just a utility class that hides actual threading model and result message passing form the worker thread to the swing gui thread (as you probably know) and this confuses so many people (just like any other threading patterns) - they think that some kind of magic is goin on behind the curtains...

:-) :-) :-) This was new for me. The title is so ridiculous, probably because the "Teach yourself X in 24 hours" series is so well known and because X here is not a technology or language but simply "Programming"!

+5, I've just cleared my filter to see all questions but I quickly restore it to avoid topics like this... Ugly client side web development problems (with wiki pages???) left unresolved for more than a decade??? :-)

+5, I always advise everyone to write only a single exported function into a DLL that returns a pointer to an interface or a descriptor (like a struct containing func ptrs in C). I also have a tip about this: Designing the interface of DLLs in C/C++ projects. This has so many advantages, for example implementing platform (in)dependent (delay) loading (windows, unix, ...) or implementing the interface many times built into the program itself (like in case of default/builtin plugins). Changing between builtin or external shared object implementation is usually a breeze. Some fight against this point for some reason...

:thumsup: Many languages survived without multiple pointers. It's just the toolset of the good old C, but even in C you can survive without pointer pointers or even more multiple indirections. Almost any of the language features can be abused.

Thank you! I was a bit confused to be honest and couldn't make distinction between seriousness and irony. :-) In this case I would simply return with a pointer as return S_OK all the time is pointless. If I have to return with a lot of values I usually pass a struct ref to the function and the func can fill my struct as it wants. This way I can pass in default values and the func declaration and function calls remain much more readable. The same is true for incoming func parameters, if a func has lots of parameters I usually replace them with a const struct ref. This way you can also declare default parameters for each incoming parameters and reading/interpreting this:
SInParams params;
params.param1 = true;
params.param2 = false;
params.param3 = 5;
func(params);

is much easier than reading/interpreting this:

func(true, false, 5);

even if the code is longer.

So yea, I agree, overusing multiple indirections is unnecessary and its a bad coding style for many reasons.

??? My first block is just the buggy copy pasted code of OP if your eyes stuck on that.

Copy the certificate to both devices. Period. :-) What holds you back?

The only valid answer is: debug it. Noone will find out whats wrong with your code and making assumptions like "Maybe because of ACCESS_VIOLATION..." is a pointless waste of time. Try to find out the location of the leak and then the cause. If you don't know how to do that then search for a memory leak debugging tutorial. Visual C++ has built in support for this. To debug the app in a real life scenario build it in debug, start it as a service, attach to it with the debugger and then reproduce the actions you suspect to be the cause of the leak.

This has nothing to do with the code above and with multithreading. This is simple gui programming and I can't read your mind or find out whats wrong with your code. Even if a dialog is modeless it usually doesn't disappear, but it can lose the focus and maybe go the the background. You can prevent it going behind your main window (even if it loses focus) if you set the main window as its parent window with SetParent(). A top level modeless window/dialog can also have a parent and this enforces the Z order between the parent and the child top level window, the child is always in front of the parent.

Is the question about the range of integral types? http://en.wikipedia.org/wiki/Integer_%28computer_science%29

That seems much like a good solution. Whenever possible I use PostMessage instead of SendMessage to avoid hangups an recursion. In this case I think SendMessage is also OK but you could use PostMessage. Its just a good practice to do so whenever possible. Another thing I noticed that you are using DestroyWindow and I just guess but this seems to be a dialogproc (because of WM_INITDIALOG). maybe you should try to use EndDialog instead of DestroyWindow, I don't know wheter it works or not and the difference between the two in case of dialogs. Maybe the difference is nothing but its better to follow the rules...

Nicely designed multithreaded code always looks like single threaded code that sends out messages and receives messages by avoiding the use of thread synchronization primitives (event, lock, ...) whenever possible. For the aspect of one thread the other threads look like async tasks that can be polled or they may send events to this thread. The threads don't use each others' data if isn't necessary, they just pass data/info to each other with messages. Most patterns are also trying to convert multithreaded code to something that looks like two or more single threaded programs/processes that communicate via messages. Did you need any events or locks in this code??? :-)

Depending on the other parts of your program this piece of code should do the job well.

You are welcome. If you want to solve some specific problems and you can narrow down your question then you can get help here at CP. And of course you should take a look around for some books (amazon, google), maybe you find some useful ones (even if their topic is not a 100% match with your questions). You have to research and read a lot. The more you know, the wider range of problems you can solve well and creatively.

Those programming for cost-of-living without enthusiasm? In my opinion it's often not laziness but a total lack of interest.

not using brains and doing "like others": very good phrasing! :-) To do it well you need some experience, taking some responsibility and having your own opinion. Not using brains? I'm not surprised about this. Here "professionals" are schooled rather than being educated.