codingJoe

Members
  • Content count

    22
  • Joined

  • Last visited

Community Reputation

192 Neutral

About codingJoe

  • Rank
    Member
  1. Thanks for all the good and interesting replies! I ended up by putting the replacement words into a map (with the original words as keys). And having a recursive function that splits the text into 3 parts that will be reassembled again after the middle part was replaced. Before reassembling the 3 parts, the last part will be used in a call to the same recursive function. Above works really good if the searched words have a common prefix. Thanks again!
  2. Hi, I have following problem: I need to inspect each line of a text file, and replace all words that are recognized, with alternative words. For that, I have a correspondency list like in the example below: word1,alternativeWord1, word2,alternativeWord2, ... wordN,alternativeWordN Above list has above 1000 lines. The text file has more than 10'000 lines. My current C++ algorithm is as follows: for each line in text file:     for each word in correspondency list:         std::find(line,word). If found, replace. The correspondency list can be preprocessed offline if needed, not the text file. Above works fine but is too slow. Do you have a better suggestion? Thanks
  3. Thanks for that info MadWinter! Perfect!
  4. Hello,   I have a portable C++ Qt application that does some openGl rendering in a main window. The rendering is currently still plain old OpenGL (not even with shaders), and I feel I need to move one level up by using a third-party library.   I was first thinking about Ogre, but this is heavy, and will need to be updated on a regular basis. Then I discovered three.js and I am very pleased by the simplicity of everything. The only drawback for me is that it is javascript, but I can handle this.   My question is following:   I imagine using a webbrowser Qt widget as my main window content, so that I can do the display in there via three.js and javascript. The javascript code will read the render data from my C++ application. Is this feasable? And if yes, what kind of interface will I have to use between my C++ code and the javascript code, for fast data transfer and update?   Thanks
  5. OpenGL Rendering large meshes in OpenGl

    Thank you for your good replies, you have been very helpful. I could already slightly increase the rendering speed!
  6. Hello,   I am rendering large meshes in a very simple and straightforward way (i.e. using VBOs), but as soon as meshes start having more than 0.5 mio triangles, rendering gets slower and scene manipulation is not fluid anymore.   When I look at some other applications (i.e. visualization applications), they can handle the same imported meshes in a much faster and more fluid manner. So my question is: how do they do it?   I am not using any shaders, but the speed difference between my application and the others is too large that it could only be a matter of shaders. My code basically resumes to: vertexBuffer->bind(); glEnableClientState(GL_VERTEX_ARRAY); glVertexPointer(3,GL_FLOAT,0,0); normalBuffer->bind(); glEnableClientState(GL_NORMAL_ARRAY); glNormalPointer(GL_FLOAT,0,0); glDrawArrays(GL_TRIANGLES,0,verticesCnt); glDisableClientState(GL_NORMAL_ARRAY); normalBuffer->release(); glDisableClientState(GL_VERTEX_ARRAY); vertexBuffer->release(); Am I missing an important part of the puzzle?   Thanks
  7. My sockets are as fast as pipes..

    Thanks for the insightful comments! So if I understood correctly, using shared memory is the solution. But still no guarantee for a speed increase. I'll try my hands on this, thanks again
  8. Hello,   For an IPC I used sockets for a long time. That's convenient and relatively fast. Then I thought, at least when the 2 processes are on the same machine, that I could gain speed by using pipes instead. My idea of pipes was that they were using shared memory. But it turns out that my pipe communication is as slow as my socket communication. How can that be? Am I doing something wrong?   Currently, I have implemented the pipes on Windows, but if I can obtain a speed increase, I also want to do this on Linux.   Here my pipe implementation, client side: // connect to an existing pipe: HANDLE pipe=CreateFile("\\\\.\\Pipe\\myPipe",GENERIC_READ|GENERIC_WRITE,0,0,OPEN_EXISTING,0,0); // Write something: DWORD bytesWritten; WriteFile(pipe,buffer,bufferSize,&bytesWritten,0) // Read something: DWORD bytesRead; ReadFile(pipe,buffer,bufferSize,&bytesRead,0) And here my pipe implementation, server side: // Create the pipe: HANDLE pipe=CreateNamedPipe("\\\\.\\Pipe\\myPipe",PIPE_ACCESS_DUPLEX,PIPE_TYPE_BYTE|PIPE_READMODE_BYTE|PIPE_WAIT,PIPE_UNLIMITED_INSTANCES,3000000,3000000,NMPWAIT_USE_DEFAULT_WAIT,NULL); // Connect to client: if (_pipe!=INVALID_HANDLE_VALUE)     ConnectNamedPipe(_pipe,NULL); // Read and write from client is implemented in the same was as for the client read/write routines Anything I am doing wrong?  
  9. Thanks for all the interesting inputs! It was for me a little bit too much in-depth though ;)   Returning to my initial problem, I would be very curious if someone finds out what is going on because it is extremely mysterious to me:   1) I am not doing any fancy things. Specially not memory manipulation, etc. 2) The strange thing only happens on Linux. Windows and Mac run fine. 3) The application is cross-platform and based on Qt. 4) When working with Qt4.8, the problem doesn't happen on Linux. With Qt5.1.0, yes, even if the compiler is the same g++ 4.6.3 5) And here the actual mysterious thing:   a) I have a library LIB that exports several API functions. I also have a client application APP that dynamically loads the LIB and binds ALL of its functions at once. b) Internally, the LIB itself calls some of its exported API functions c) If APP calls the API function X, or rather just "mentions" a call to the API function X (i.e. the function doesn't need to be executed), then the LIB cannot call the same function, because the function pointer is invalid for the LIB (but working for the APP) d) if a second APP, say APP2 doesn't call and doesn't "mention" a call to the API function X, then the LIB can call the function X and it works (i.e. no crash with APP2) e) between c) and d) the LIB has not changed. It is exactly the same file. I verified also that the crash is linked to the function pointer X being invalid internally   To summarize above explanations, here a typical example:   LIB, file1: void randomFunction() {     printHello(); // internally calling the API function that this LIB exports } LIB, file2: extern "C" __attribute__((visibility("default"))) void printHello() { // one of the functions that this LIB exports     printf("Hello\n"); } APP: int main(int argc,char* argv[]) {     // Dynamically load LIB with: lib=dlopen(pathAndFilename,RTLD_LAZY)     // Bind ALL API functions with: dlsym(lib,funcName);     for (int i=0;i<10000000000;i++)         printf("."); // just spend "almost" infinite time here     printHello(); // this is actually never executed. But if we remove the loop here above, this function would execute correctly } APP2: int main(int argc,char* argv[]) {     // Dynamically load LIB with: lib=dlopen(pathAndFilename,RTLD_LAZY)     // Bind ALL API functions with: dlsym(lib,funcName);     for (int i=0;i<10000000000;i++)         printf("."); // just spend "almost" infinite time here     // printHello(); } The difference between APP and APP2 is minimal. The LIB that APP and APP2 load and bind is exactly the same. However, only with APP2 can the LIB function 'randomFunction' safely call 'printHello'. With APP, 'randomFunction' executes only to the point where 'printHello' has to be called, then crashes. Verifying the 'printHello' function address inside that 'randomFunction' reveals an illegal address --> it is logical that it crashes, but not logical that the address is illegal with APP and not illegal with APP2.   Did I make sense? I am already trying to figure out what is going on since a few days, and the more I move forward, the more I feel lost..
  10. Thanks Khatharr,   I had a look at the link which is very exhaustive, but probably too much Windows oriented. I am using g++ V4.6.3 under Ubuntu. It is invoked under the whoods by Qt (Qt V5.1.0). You are telling me that functions can get shifted around when loaded into memory, and the loader/binder takes care of correcting for that. But it seems that in my case, the loader fails at doing its job correctly:   I have library-internal calls to functions A and B too. And those calls will sometimes call the wrong address (as strangely as it seems!). My library and client application run on Windows, Mac and Linux. Windows and Mac run fine. Linux used to run fine until I switched to the newest Qt version (but still same compiler). Is it possible that Qt appended additional compilation flags that influence the way my library gets loaded?
  11. Thank you swiftcoder.   Yes, I understand that the functions should all get a same offset, but is it possible that one function gets a different offset that the others?   Let's say, that I have 2 functions in my library: A() and B(). My client application loads the library and binds the functions. I print location of function B RELATIVE to the location of functions A:   A-B=position of function B relative to function A=X   My question is: will X always be the same for the same library binary? Could it be that the library loaded decided one time to put function B before function A? (and vice-versa)
  12. Hello,   while trying to find out the reasons of a strange behaviour of my library, I stumbled upon this:   cpp file 1 of library: void printRelativeFunctionAddresses() {     printf("printRelativeFunctionAddresses-giveMeAOne: %i\n",int(printRelativeFunctionAddresses)-int(giveMeAOne));     printf("printRelativeFunctionAddresses-giveMeATwo: %i\n",int(printRelativeFunctionAddresses)-int(giveMeATwo)); } Cpp file 2 of library: extern "C" __attribute__((visibility("default"))) int giveMeAOne() {     return(1); } extern "C" __attribute__((visibility("default"))) int giveMeATwo() {     return(2); } the function printRelativeFunctionAddresses prints the same value everytime I start the library from a specific client application A. But when I use a different client application B (but that loads the exact same library), then the output is different! How can that be? Are functions shifted around during the library load operation?   I am running the library on Ubuntu 32bit, using Qt5.1.0
  13. Thank you for your explanation. But the linker does its job just after compilation, right? then a library is generated. In my case, with the exact same library that internally calls giveMeAZero, I can have two different scenarios:   1) client app also calls giveMeAZero --> when the library itself calls giveMeAZero, I get a segmentation fault 2) client app doesn't call giveMeAZero (but binds the function) --> when the library itself calls giveMeAZero, it works!   How can that be??
  14. Thanks again for your reply. Well, the project is pretty big, and cutting out everything would take time, but I will consider this. I tested a last thing in the mean time. With above mentionned piece of example code, I tried this:   In the library: printf("giveMeAZero (internal): %i\n",giveMeAZero); printf("giveMeAZero2 (internal): %i\n",giveMeAZero2); printf("giveMeAOne (internal): %i\n",giveMeAOne); In the client application: printf("giveMeAZero (clientApp): %i\n",giveMeAZero); printf("giveMeAZero2 (clientApp): %i\n",giveMeAZero2); printf("giveMeAOne (clientApp): %i\n",giveMeAOne); And the function addresses do not overlap! How can that be?   The library and client applications are both 32 bit, running on Ubuntu12.04 32bit in a virtualBox
  15. Thanks for the quick reply! Those functions were just examples. But basically when it crashes, it does it before entering the functions (checked with prints). Here an example a little bit more elaborate:   Library code, file 1: extern "C" __attribute__((visibility("default"))) int returnMeAZero() {     return(0); } extern "C" __attribute__((visibility("default"))) int returnMeAZero2() {     return(0); } extern "C" __attribute__((visibility("default"))) int returnMeAOne() {     return(1); } Library code, file 2: void randomFunction() {     returnMeAOne(); // works and doesn't crash     returnMeAZero2(); // works and doesn't crash     returnMeAZero(); // crashes before even entering the 'returnMeAZero' function } Client application: void main() {     // load library with dlopen     // bind all 3 API functions in exactly the same way (with dlsym)     returnMeAZero(); // works without crash } If I remove the 'returnMeAZero' function call in the client application, then the 'randomFunction' of the library never crashes and does exactly what it is supposed to. The whole thing behaves as if just having a function call to that function in the client application changes the physical location of the function in the library!