Search Results

Search found 976 results on 40 pages for 'typedef'.

Page 36/40 | < Previous Page | 32 33 34 35 36 37 38 39 40  | Next Page >

• Drawing with element array in OpenGL ES

  - by FatalMojo

  Hello! I am trying to use OpenGLES to draw a x by y matrix of squares about an arbitrary point. I have an array sideVertice[] that holds a series of vertex structs defined as such typedef struct { GLfloat x; GLfloat y; GLfloat z; } Vertex3D; and an element array defined as such GLubyte elementArray[]; my draw loop is as such glLoadIdentity(); glVertexPointer(3, GL_FLOAT, 0, cube.sideVertice); for (int i=0; i<((cube.cubeSize + 1)*(cube.cubeSize + 1)); i++) { for (int j=0; j<=3; j++) { elementArray[j] = j + i*4; glDrawElements(GL_TRIANGLE_STRIP, 4, GL_UNSIGNED_BYTE, elementArray); } } for (int i=0; i<=3; i++) elementArray[i] = i; However, the visual output is corrupted and I cannot figure out what the problem is. here is an output of the vertice held in the array: 2010-04-15 23:44:48.816 RubixGL[4203:20b] vertex[0][0] x:-26.000000 y:1.000000 2010-04-15 23:44:48.817 RubixGL[4203:20b] vertex[1][1] x:-26.000000 y:26.000000 2010-04-15 23:44:48.826 RubixGL[4203:20b] vertex[2][2] x:-1.000000 y:1.000000 2010-04-15 23:44:48.829 RubixGL[4203:20b] vertex[3][3] x:-1.000000 y:26.000000 2010-04-15 23:44:48.830 RubixGL[4203:20b] Next Face 2010-04-15 23:44:48.830 RubixGL[4203:20b] vertex[0][4] x:1.000000 y:1.000000 2010-04-15 23:44:48.832 RubixGL[4203:20b] vertex[1][5] x:1.000000 y:26.000000 2010-04-15 23:44:48.837 RubixGL[4203:20b] vertex[2][6] x:26.000000 y:1.000000 2010-04-15 23:44:48.838 RubixGL[4203:20b] vertex[3][7] x:26.000000 y:26.000000 2010-04-15 23:44:48.848 RubixGL[4203:20b] Next Face 2010-04-15 23:44:48.849 RubixGL[4203:20b] vertex[0][8] x:-26.000000 y:-26.000000 2010-04-15 23:44:48.850 RubixGL[4203:20b] vertex[1][9] x:-26.000000 y:-1.000000 2010-04-15 23:44:48.851 RubixGL[4203:20b] vertex[2][10] x:-1.000000 y:-26.000000 2010-04-15 23:44:48.852 RubixGL[4203:20b] vertex[3][11] x:-1.000000 y:-1.000000 2010-04-15 23:44:48.853 RubixGL[4203:20b] Next Face 2010-04-15 23:44:48.853 RubixGL[4203:20b] vertex[0][12] x:1.000000 y:-26.000000 2010-04-15 23:44:48.854 RubixGL[4203:20b] vertex[1][13] x:1.000000 y:-1.000000 2010-04-15 23:44:48.854 RubixGL[4203:20b] vertex[2][14] x:26.000000 y:-26.000000 2010-04-15 23:44:48.855 RubixGL[4203:20b] vertex[3][15] x:26.000000 y:-1.000000 any ideas?

  Read the article

• C: reading file and populating struct

  - by deostroll

  Hi, I have a structure with the following definition: typedef struct myStruct{ int a; char* c; int f; } OBJECT; I am able to populate this object and write it to a file. However I am not able to read the char* c value in it...while trying to read it, it gives me a segmentation fault error. Is there anything wrong with my code: //writensave.c #include "mystruct.h" #include <stdio.h> #include <string.h> #define p(x) printf(x) int main() { p("Creating file to write...\n"); FILE* file = fopen("struct.dat", "w"); if(file == NULL) { printf("Error opening file\n"); return -1; } p("creating structure\n"); OBJECT* myObj = (OBJECT*)malloc(sizeof(OBJECT)); myObj->a = 20; myObj->f = 45; myObj->c = (char*)calloc(30, sizeof(char)); strcpy(myObj->c, "This is a test"); p("Writing object to file...\n"); fwrite(myObj, sizeof(OBJECT), 1, file); p("Close file\n"); fclose(file); p("End of program\n"); return 0; } Here is how I am trying to read it: //readnprint.c #include "mystruct.h" #include <stdio.h> #define p(x) printf(x) int main() { FILE* file = fopen("struct.dat", "r"); char* buffer; buffer = (char*) malloc(sizeof(OBJECT)); if(file == NULL) { p("Error opening file"); return -1; } fread((void *)buffer, sizeof(OBJECT), 1, file); OBJECT* obj = (OBJECT*)buffer; printf("obj->a = %d\nobj->f = %d \nobj->c = %s", obj->a, obj->f, obj->c); fclose(file); return 0; }

  Read the article

• No matter what, I can't get this stupid progress bar to update from a thread!

  - by Synthetix

  I have a Windows app written in C (using gcc/MinGW) that works pretty well except for a few UI problems. One, I simply cannot get the progress bar to update from a thread. In fact, I probably can't get ANY UI stuff to update. Basically, I have a spawned thread that does some processing, and from that thread I attempt to update the progress bar in the main thread. I tried this by using PostMessage() to the main hwnd, but no luck even though I can do other things like open message boxes. However, it's unclear whether the message box is getting called within the thread or on the main thread. Here's some code: //in header/globally accessible HWND wnd; //main application window HWND progress_bar; //progress bar typedef struct { //to pass to thread DWORD mainThreadId; HWND mainHwnd; char *filename; } THREADSTUFF; //callback function LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam){ switch(msg){ case WM_CREATE:{ //create progress bar progress_bar = CreateWindowEx( 0, PROGRESS_CLASS, (LPCTSTR)NULL, WS_CHILD | WS_VISIBLE, 79,164,455,15, hwnd, (HMENU)20, NULL, NULL); break; } case WM_COMMAND:{ if(LOWORD(wParam)==2){ //do some processing in a thread //struct of stuff I need to pass to thread THREADSTUFF *threadStuff; threadStuff = (THREADSTUFF*)malloc(sizeof(*threadStuff)); threadStuff->mainThreadId = GetCurrentThreadId(); threadStuff->mainHwnd = hwnd; threadStuff->filename = (void*)&filename; hThread1 = CreateThread(NULL,0,convertFile (LPVOID)threadStuff,0,NULL); }else if(LOWORD(wParam)==5){ //update progress bar MessageBox(hwnd,"I got a message!", "Message", MB_OK | MB_ICONINFORMATION); PostMessage(progress_bar,PBM_STEPIT,0,CLR_DEFAULT); } break; } } } This all seems to work okay. The problem is in the thread: DWORD WINAPI convertFile(LPVOID params){ //get passed params, this works perfectly fine THREADSTUFF *tData = (THREADSTUFF*)params; MessageBox(tData->mainHwnd,tData->filename,"File name",MB_OK | MB_ICONINFORMATION); //yep PostThreadMessage(tData->mainThreadId,WM_COMMAND,5,0); //only shows message PostMessage(tData->mainHwnd,WM_COMMAND,5,0); //only shows message } When I say, "only shows message," that means the MessageBox() function in the callback works, but not the PostMessage() to update the position of the progress bar. What am I missing?

  Read the article

• Multiset container appears to stop sorting

  - by Sarah

  I would appreciate help debugging some strange behavior by a multiset container. Occasionally, the container appears to stop sorting. This is an infrequent error, apparent in only some simulations after a long time, and I'm short on ideas. (I'm an amateur programmer--suggestions of all kinds are welcome.) My container is a std::multiset that holds Event structs: typedef std::multiset< Event, std::less< Event > > EventPQ; with the Event structs sorted by their double time members: struct Event { public: explicit Event(double t) : time(t), eventID(), hostID(), s() {} Event(double t, int eid, int hid, int stype) : time(t), eventID( eid ), hostID( hid ), s(stype) {} bool operator < ( const Event & rhs ) const { return ( time < rhs.time ); } double time; ... }; The program iterates through periods of adding events with unordered times to EventPQ currentEvents and then pulling off events in order. Rarely, after some events have been added (with perfectly 'legal' times), events start getting executed out of order. What could make the events ever not get ordered properly? (Or what could mess up the iterator?) I have checked that all the added event times are legitimate (i.e., all exceed the current simulation time), and I have also confirmed that the error does not occur because two events happen to get scheduled for the same time. I'd love suggestions on how to work through this. The code for executing and adding events is below for the curious: double t = 0.0; double nextTimeStep = t + EPID_DELTA_T; EventPQ::iterator eventIter = currentEvents.begin(); while ( t < EPID_SIM_LENGTH ) { // Add some events to currentEvents while ( ( *eventIter ).time < nextTimeStep ) { Event thisEvent = *eventIter; t = thisEvent.time; executeEvent( thisEvent ); eventCtr++; currentEvents.erase( eventIter ); eventIter = currentEvents.begin(); } t = nextTimeStep; nextTimeStep += EPID_DELTA_T; } void Simulation::addEvent( double et, int eid, int hid, int s ) { assert( currentEvents.find( Event(et) ) == currentEvents.end() ); Event thisEvent( et, eid, hid, s ); currentEvents.insert( thisEvent ); }

  Read the article

• Why does DebugActiveProcessStop crash my debugging app?

  - by SparkyNZ

  I have a debugging program which I've written to attach to a process and create a crash dump file. That part works fine. The problem I have is that when the debugger program terminates, so does the program that it was debugging. I did some Googling and found the DebugActiveProcessStop() API call. This didn't show up in my older MSDN documentation as it was only introduced in Windows XP so I've tried loading it dynamicall from Kernel32.dll at runtime. Now my problem is that my debugger program crashes as soon as the _DebugActiveProcessStop() call is made. Can somebody please tell me what I'm doing wrong? typedef BOOL (*DEBUGACTIVEPROCESSSTOP)(DWORD); DEBUGACTIVEPROCESSSTOP _DebugActiveProcessStop; HMODULE hK32 = LoadLibrary( "kernel32.dll" ); if( hK32 ) _DebugActiveProcessStop = (DEBUGACTIVEPROCESSSTOP) GetProcAddress( hK32,"DebugActiveProcessStop" ); else { printf( "Can't load Kernel32.dll\n" ); return; } if( ! _DebugActiveProcessStop ) { printf( "Can't find DebugActiveProcessStop\n" ); return; } ... void DebugLoop( void ) { DEBUG_EVENT de; while( 1 ) { WaitForDebugEvent( &de, INFINITE ); switch( de.dwDebugEventCode ) { case CREATE_PROCESS_DEBUG_EVENT: hProcess = de.u.CreateProcessInfo.hProcess; break; case EXCEPTION_DEBUG_EVENT: // PDS: I want a crash dump immediately! dwProcessId = de.dwProcessId; dwThreadId = de.dwThreadId; WriteCrashDump( &de.u.Exception ); return; case CREATE_THREAD_DEBUG_EVENT: case OUTPUT_DEBUG_STRING_EVENT: case EXIT_THREAD_DEBUG_EVENT: case EXIT_PROCESS_DEBUG_EVENT : case LOAD_DLL_DEBUG_EVENT: case UNLOAD_DLL_DEBUG_EVENT: case RIP_EVENT: default: break; } ContinueDebugEvent( de.dwProcessId, de.dwThreadId, DBG_CONTINUE ); } } ... void main( void ) { ... BOOL bo = DebugActiveProcess( dwProcessId ); if( bo == 0 ) printf( "DebugActiveProcess failed, GetLastError: %u \n",GetLastError() ); hProcess = OpenProcess( PROCESS_ALL_ACCESS, TRUE, dwProcessId ); if( hProcess == NULL ) printf( "OpenProcess failed, GetLastError: %u \n",GetLastError() ); DebugLoop(); _DebugActiveProcessStop( dwProcessId ); CloseHandle( hProcess ); }

  Read the article

• What is GC holes?

  - by tianyi

  I wrote a long TCP connection socket server in C#. Spike in memory in my server happens. I used dotNet Memory Profiler(a tool) to detect where the memory leaks. Memory Profiler indicates the private heap is huge, and the memory is something like below(the number is not real,what I want to show is the GC0 and GC2's Holes are very very huge, the data size is normal): Managed heaps - 1,500,000KB Normal heap - 1400,000KB Generation #0 - 600,000KB Data - 100,000KB "Holes" - 500,000KB Generation #1 - xxKB Data - 0KB "Holes" - xKB Generation #2 - xxxxxxxxxxxxxKB Data - 100,000KB "Holes" - 700,000KB Large heap - 131072KB Large heap - 83KB Overhead/unused - 130989KB Overhead - 0KB Howerver, what is GC hole? I read an article about the hole: http://kaushalp.blogspot.com/2007/04/what-is-gc-hole-and-how-to-create-gc.html The author said : The code snippet below is the simplest way to introduce a GC hole into the system. //OBJECTREF is a typedef for Object*. { PointerTable *pTBL = o_pObjectClass->GetPointerTable(); OBJECTREF aObj = AllocateObjectMemory(pTBL); OBJECTREF bObj = AllocateObjectMemory(pTBL); //WRONG!!! “aObj” may point to garbage if the second //“AllocateObjectMemory” triggered a GC. DoSomething (aOb, bObj); } All it does is allocate two managed objects, and then does something with them both. This code compiles fine, and if you run simple pre-checkin tests, it will probably “work.” But this code will crash eventually. Why? If the second call to “AllocateObjectMemory” triggers a GC, that GC discards the object instance you just assigned to “aObj”. This code, like all C++ code inside the CLR, is compiled by a non-managed compiler and the GC cannot know that “aObj” holds a root reference to an object you want kept live. ======================================================================== I can't understand what he explained. Does the sample mean aObj becomes a wild pointer after GC? Is it mean { aObj = (*aObj)malloc(sizeof(object)); free(aObj); function(aObj);? } ? I hope somebody can explain it.

  Read the article

• Can't insert a number into a C++ custom streambuf/ostream

  - by 0xbe5077ed

  I have written a custom std::basic_streambuf and std::basic_ostream because I want an output stream that I can get a JNI string from in a manner similar to how you can call std::ostringstream::str(). These classes are quite simple. namespace myns { class jni_utf16_streambuf : public std::basic_streambuf<char16_t> { JNIEnv * d_env; std::vector<char16_t> d_buf; virtual int_type overflow(int_type); public: jni_utf16_streambuf(JNIEnv *); jstring jstr() const; }; typedef std::basic_ostream<char16_t, std::char_traits<char16_t>> utf16_ostream; class jni_utf16_ostream : public utf16_ostream { jni_utf16_streambuf d_buf; public: jni_utf16_ostream(JNIEnv *); jstring jstr() const; }; // ... } // namespace myns In addition, I have made four overloads of operator<<, all in the same namespace: namespace myns { // ... utf16_ostream& operator<<(utf16_ostream&, jstring) throw(std::bad_cast); utf16_ostream& operator<<(utf16_ostream&, const char *); utf16_ostream& operator<<(utf16_ostream&, const jni_utf16_string_region&); jni_utf16_ostream& operator<<(jni_utf16_ostream&, jstring); // ... } // namespace myns The implementation of jni_utf16_streambuf::overflow(int_type) is trivial. It just doubles the buffer width, puts the requested character, and sets the base, put, and end pointers correctly. It is tested and I am quite sure it works. The jni_utf16_ostream works fine inserting unicode characters. For example, this works fine and results in the stream containing "hello, world": myns::jni_utf16_ostream o(env); o << u"hello, wor" << u'l' << u'd'; My problem is as soon as I try to insert an integer value, the stream's bad bit gets set, for example: myns::jni_utf16_ostream o(env); if (o.badbit()) throw "bad bit before"; // does not throw int32_t x(5); o << x; if (o.badbit()) throw "bad bit after"; // throws :( I don't understand why this is happening! Is there some other method on std::basic_streambuf I need to be implementing????

  Read the article

• Directly Jump to another C++ function

  - by maligree

  I'm porting a small academic OS from TriCore to ARM Cortex (Thumb-2 instruction set). For the scheduler to work, I sometimes need to JUMP directly to another function without modifying the stack nor the link register. On TriCore (or, rather, on tricore-g++), this wrapper template (for any three-argument-function) works: template< class A1, class A2, class A3 > inline void __attribute__((always_inline)) JUMP3( void (*func)( A1, A2, A3), A1 a1, A2 a2, A3 a3 ) { typedef void (* __attribute__((interrupt_handler)) Jump3)( A1, A2, A3); ( (Jump3)func )( a1, a2, a3 ); } //example for using the template: JUMP3( superDispatch, this, me, next ); This would generate the assembler instruction J (a.k.a. JUMP) instead of CALL, leaving the stack and CSAs unchanged when jumping to the (otherwise normal) C++ function superDispatch(SchedulerImplementation* obj, Task::Id from, Task::Id to). Now I need an equivalent behaviour on ARM Cortex (or, rather, for arm-none-linux-gnueabi-g++), i.e. generate a B (a.k.a. BRANCH) instruction instead of BLX (a.k.a. BRANCH with link and exchange). But there is no interrupt_handler attribute for arm-g++ and I could not find any equivalent attribute. So I tried to resort to asm volatile and writing the asm code directly: template< class A1, class A2, class A3 > inline void __attribute__((always_inline)) JUMP3( void (*func)( A1, A2, A3), A1 a1, A2 a2, A3 a3 ) { asm volatile ( "mov.w r0, %1;" "mov.w r1, %2;" "mov.w r2, %3;" "b %0;" : : "r"(func), "r"(a1), "r"(a2), "r"(a3) : "r0", "r1", "r2" ); } So far, so good, in my theory, at least. Thumb-2 requires function arguments to be passed in the registers, i.e. r0..r2 in this case, so it should work. But then the linker dies with undefined reference to `r6' on the closing bracket of the asm statement ... and I don't know what to make of it. OK, I'm not the expert in C++, and the asm syntax is not very straightforward... so has anybody got a hint for me? A hint to the correct __attribute__ for arm-g++ would be one way, a hint to fix the asm code would be another. Another way maybe would be to tell the compiler that a1..a3 should already be in the registers r0..r2 when the asm statement is entered (I looked into that a bit, but did not find any hint).

  Read the article

• Better way to write an object generator for an RAII template class?

  - by Dan

  I would like to write an object generator for a templated RAII class -- basically a function template to construct an object using type deduction of parameters so the types don't have to be specified explicitly. The problem I foresee is that the helper function that takes care of type deduction for me is going to return the object by value, which will result in a premature call to the RAII destructor when the copy is made. Perhaps C++0x move semantics could help but that's not an option for me. Anyone seen this problem before and have a good solution? This is what I have: template<typename T, typename U, typename V> class FooAdder { private: typedef OtherThing<T, U, V> Thing; Thing &thing_; int a_; // many other members public: FooAdder(Thing &thing, int a); ~FooAdder(); void foo(T t, U u); void bar(V v); }; The gist is that OtherThing has a horrible interface, and FooAdder is supposed to make it easier to use. The intended use is roughly like this: FooAdder(myThing, 2) .foo(3, 4) .foo(5, 6) .bar(7) .foo(8, 9); The FooAdder constructor initializes some internal data structures. The foo and bar methods populate those data structures. The ~FooAdder dtor wraps things up and calls a method on thing_, taking care of all the nastiness. That would work fine if FooAdder wasn't a template. But since it is, I would need to put the types in, more like this: FooAdder<Abc, Def, Ghi>(myThing, 2) ... That's annoying, because the types can be inferred based on myThing. So I would prefer to create a templated object generator, similar to std::make_pair, that will do the type deduction for me. Something like this: template<typename T, typename U, typename V> FooAdder<T, U, V> AddFoo(Thing &thing, int a) { return FooAdder<T, U, V>(thing, a); } That seems problematic: because it returns by value, the stack temporary object will be destructed, which will cause the RAII dtor to run prematurely. One thought I had was to give FooAdder a copy ctor with move semantics, kinda like std::auto_ptr. But I would like to do this without dynamic memory allocation, so I thought the copy ctor could set a flag within FooAdder indicating the dtor shouldn't do the wrap-up. Like this: FooAdder(FooAdder &rhs) // Note: rhs is not const : thing_(rhs.thing_) , a_(rhs.a_) , // etc... lots of other members, annoying. , moved(false) { rhs.moved = true; } ~FooAdder() { if (!moved) { // do whatever it would have done } } Seems clunky. Anyone got a better way?

  Read the article

• get return value from 2 threads in C

  - by polslinux

  #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <stdint.h> #include <inttypes.h> typedef struct tmp_num{ int tmp_1; int tmp_2; }t_num; t_num t_nums; void *num_mezzo_1(void *num_orig); void *num_mezzo_2(void *num_orig); int main(int argc, char *argv[]){ pthread_t thread1, thread2; int tmp=0,rc1,rc2,num; num=atoi(argv[1]); if(num <= 3){ printf("Questo è un numero primo: %d\n", num); exit(0); } if( (rc1=pthread_create( &thread1, NULL, &num_mezzo_1, (void *)&num)) ){ printf("Creazione del thread fallita: %d\n", rc1); exit(1); } if( (rc2=pthread_create( &thread2, NULL, &num_mezzo_2, (void *)&num)) ){ printf("Creazione del thread fallita: %d\n", rc2); exit(1); } t_nums.tmp_1 = 0; t_nums.tmp_2 = 0; pthread_join(thread1, (void **)(&t_nums.tmp_1)); pthread_join(thread2, (void **)(&t_nums.tmp_2)); tmp=t_nums.tmp_1+t_nums.tmp_2; printf("%d %d %d\n", tmp, t_nums.tmp_1, t_nums.tmp_2); if(tmp>2){ printf("Questo NON è un numero primo: %d\n", num); } else{ printf("Questo è un numero primo: %d\n", num); } exit(0); } void *num_mezzo_1(void *num_orig){ int cont_1; int *n_orig=(int *)num_orig; t_nums.tmp_1 = 0; for(cont_1=1; cont_1<=(*n_orig/2); cont_1++){ if((*n_orig % cont_1) == 0){ (t_nums.tmp_1)++; } } pthread_exit((void *)(&t_nums.tmp_1)); return NULL; } void *num_mezzo_2(void *num_orig){ int cont_2; int *n_orig=(int *)num_orig; t_nums.tmp_2 = 0; for(cont_2=((*n_orig/2)+1); cont_2<=*n_orig; cont_2++){ if((*n_orig % cont_2) == 0){ (t_nums.tmp_2)++; } } pthread_exit((void *)(&t_nums.tmp_2)); return NULL; } How this program works: i have to input a number and this program will calculate if it is a prime number or not (i know that it is a bad algorithm but i only need to learn pthread). The problem is that the returned values are too much big.For example if i write "12" the value of tmp tmp_1 tmp_2 into the main are 12590412 6295204 6295208.Why i got those numbers??

  Read the article

• Several C# Language Questions

  - by Water Cooler v2

  1) What is int? Is it any different from the struct System.Int32? I understand that the former is a C# alias (typedef or #define equivalant) for the CLR type System.Int32. Is this understanding correct? 2) When we say: IComparable x = 10; Is that like saying: IComparable x = new System.Int32(); But we can't new a struct, right? or in C like syntax: struct System.In32 *x; x=>someThing = 10; 3) What is String with a capitalized S? I see in Reflector that it is the sealed String class, which, of course, is a reference type, unlike the System.Int32 above, which is a value type. What is string, with an uncapitalized s, though? Is that also the C# alias for this class? Why can I not see the alias definitions in Reflector? 4) Try to follow me down this subtle train of thought, if you please. We know that a storage location of a particular type can only access properties and members on its interface. That means: Person p = new Customer(); p.Name = "Water Cooler v2"; // legal because as Name is defined on Person. but // illegal without an explicit cast even though the backing // store is a Customer, the storage location is of type // Person, which doesn't support the member/method being // accessed/called. p.GetTotalValueOfOrdersMade(); Now, with that inference, consider this scenario: int i = 10; // obvious System.object defines no member to // store an integer value or any other value in. // So, my question really is, when the integer is // boxed, what is the *type* it is actually boxed to. // In other words, what is the type that forms the // backing store on the heap, for this operation? object x = i; Update Thank you for your answers, Eric Gunnerson and Aaronought. I'm afraid I haven't been able to articulate my questions well enough to attract very satisfying answers. The trouble is, I do know the answers to my questions on the surface, and I am, by no means, a newbie programmer. But I have to admit, a deeper understanding to the intricacies of how a language and its underlying platform/runtime handle storage of types has eluded me for as long as I've been a programmer, even though I write correct code.

  Read the article

• Detect if class has overloaded function fails on Comeau compiler

  - by Frank

  Hi Everyone, I'm trying to use SFINAE to detect if a class has an overloaded member function that takes a certain type. The code I have seems to work correctly in Visual Studio and GCC, but does not compile using the Comeau online compiler. Here is the code I'm using: #include <stdio.h> //Comeau doesnt' have boost, so define our own enable_if_c template<bool value> struct enable_if_c { typedef void type; }; template<> struct enable_if_c< false > {}; //Class that has the overloaded member function class TestClass { public: void Func(float value) { printf( "%f\n", value ); } void Func(int value) { printf( "%i\n", value ); } }; //Struct to detect if TestClass has an overloaded member function for type T template<typename T> struct HasFunc { template<typename U, void (TestClass::*)( U )> struct SFINAE {}; template<typename U> static char Test(SFINAE<U, &TestClass::Func>*); template<typename U> static int Test(...); static const bool Has = sizeof(Test<T>(0)) == sizeof(char); }; //Use enable_if_c to only allow the function call if TestClass has a valid overload for T template<typename T> typename enable_if_c<HasFunc<T>::Has>::type CallFunc(TestClass &test, T value) { test.Func( value ); } int main() { float value1 = 0.0f; int value2 = 0; TestClass testClass; CallFunc( testClass, value1 ); //Should call TestClass::Func( float ) CallFunc( testClass, value2 ); //Should call TestClass::Func( int ) } The error message is: no instance of function template "CallFunc" matches the argument list. It seems that HasFunc::Has is false for int and float when it should be true. Is this a bug in the Comeau compiler? Am I doing something that's not standard? And if so, what do I need to do to fix it?

  Read the article

• (Strange) C++ linker error in constructor

  - by Microkernel

  I am trying to write a template class in C++ and getting this strange linker error and can't figureout the cause, please let me know whats wrong with this! Here is the error message I am getting in Visula C++ 2010. 1>------ Rebuild All started: Project: FlashEmulatorTemplates, Configuration: Debug Win32 ------ 1> main.cpp 1> emulator.cpp 1> Generating Code... 1>main.obj : error LNK2019: unresolved external symbol "public: __thiscall flash_emulator<char>::flash_emulator<char>(char const *,struct FLASH_PROPERTIES *)" (??0?$flash_emulator@D@@QAE@PBDPAUFLASH_PROPERTIES@@@Z) referenced in function _main 1>C:\Projects\FlashEmulator_templates\VS\FlashEmulatorTemplates\Debug\FlashEmulatorTemplates.exe : fatal error LNK1120: 1 unresolved externals ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ========== Error message in g++ main.cpp: In function âint main()â: main.cpp:8: warning: deprecated conversion from string constant to âchar*â /tmp/ccOJ8koe.o: In function `main': main.cpp:(.text+0x21): undefined reference to `flash_emulator<char>::flash_emulator(char*, FLASH_PROPERTIES*)' collect2: ld returned 1 exit status There are 2 .cpp files and 1 header file, and I have given them below. emulator.h #ifndef __EMULATOR_H__ #define __EMULATOR_H__ typedef struct { int property; }FLASH_PROPERTIES ; /* Flash emulation class */ template<class T> class flash_emulator { private: /* Private data */ int key; public: /* Constructor - Opens an existing flash by name flashName or creates one with given FLASH_PROPERTIES if it doesn't exist */ flash_emulator( const char *flashName, FLASH_PROPERTIES *properties ); /* Constructor - Opens an existing flash by name flashName or creates one with given properties given in configFIleName */ flash_emulator<T>( char *flashName, char *configFileName ); /* Destructor for the emulator */ ~flash_emulator(){ } }; #endif /* End of __EMULATOR_H__ */ emulator.cpp #include <Windows.h> #include "emulator.h" using namespace std; template<class T>flash_emulator<T>::flash_emulator( const char *flashName, FLASH_PROPERTIES *properties ) { return; } template<class T>flash_emulator<T>::flash_emulator(char *flashName, char *configFileName) { return; } main.cpp #include <Windows.h> #include "emulator.h" int main() { FLASH_PROPERTIES properties = {0}; flash_emulator<char> myEmulator("C:\newEMu.flash", &properties); return 0; }

  Read the article

• How to copy the memeory allocated in device function back to main memory

  - by xhe8

  I have a CUDA program containing a host function and a device function Execute(). In the host function, I allocate a global memory output which will then be passed to the device function and used to store the address of the global memory allocated within the device function. I want to access the in-kernel allocated memory in the host function. The following is the code: #include <stdio.h> typedef struct { int * p; int num; } Structure_A; \__global__ void Execute(Structure_A *output); int main(){ Structure_A *output; cudaMalloc((void***)&output,sizeof(Structure_A)*1); dim3 dimBlockExecute(1,1); dim3 dimGridExecute(1,1); Execute<<<dimGridExecute,dimBlockExecute>>>(output); Structure_A * output_cpu; int * p_cpu; cudaError_t err; output_cpu= (Structure_A*)malloc(1); err=cudaMemcpy(output_cpu,output,sizeof(Structure_A),cudaMemcpyDeviceToHost); if( err != cudaSuccess) { printf("CUDA error a: %s\n", cudaGetErrorString(err)); exit(-1); } p_cpu=(int *)malloc(1); err=cudaMemcpy(p_cpu,output_cpu[0].p,sizeof(int),cudaMemcpyDeviceToHost); if( err != cudaSuccess) { printf("CUDA error b: %s\n", cudaGetErrorString(err)); exit(-1); } printf("output=(%d,%d)\n",output_cpu[0].num,p_cpu[0]); return 0; } \__global__ void Execute(Structure_A *output){ int thid=threadIdx.x; output[thid].p= (int*)malloc(thid+1); output[thid].num=(thid+1); output[thid].p[0]=5; } I can compile the program. But when I run it, I got a error showing that there is a invalid argument in the following memory copy function. "err=cudaMemcpy(p_cpu,output_cpu[0].p,sizeof(int),cudaMemcpyDeviceToHost);" CUDA version is 4.2. CUDA card: Tesla C2075 OS: x86_64 GNU/Linux

  Read the article

• Boost MultiIndex - objects or pointers (and how to use them?)?

  - by Sarah

  I'm programming an agent-based simulation and have decided that Boost's MultiIndex is probably the most efficient container for my agents. I'm not a professional programmer, and my background is very spotty. I've two questions: Is it better to have the container contain the agents (of class Host) themselves, or is it more efficient for the container to hold Host *? Hosts will sometimes be deleted from memory (that's my plan, anyway... need to read up on new and delete). Hosts' private variables will get updated occasionally, which I hope to do through the modify function in MultiIndex. There will be no other copies of Hosts in the simulation, i.e., they will not be used in any other containers. If I use pointers to Hosts, how do I set up the key extraction properly? My code below doesn't compile. // main.cpp - ATTEMPTED POINTER VERSION ... #include <boost/multi_index_container.hpp> #include <boost/multi_index/hashed_index.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/mem_fun.hpp> #include <boost/tokenizer.hpp> typedef multi_index_container< Host *, indexed_by< // hash by Host::id hashed_unique< BOOST_MULTI_INDEX_MEM_FUN(Host,int,Host::getID) > // arg errors here > // end indexed_by > HostContainer; ... int main() { ... HostContainer testHosts; Host * newHostPtr; newHostPtr = new Host( t, DOB, idCtr, 0, currentEvents ); testHosts.insert( newHostPtr ); ... } I can't find a precisely analogous example in the Boost documentation, and my knowledge of C++ syntax is still very weak. The code does appear to work when I replace all the pointer references with the class objects themselves. As best I can read it, the Boost documentation (see summary table at bottom) implies I should be able to use member functions with pointer elements.

  Read the article

• Parent Objects

  - by Ali Bahrami

  Support for Parent Objects was added in Solaris 11 Update 1. The following material is adapted from the PSARC arc case, and the Solaris Linker and Libraries Manual. A "plugin" is a shared object, usually loaded via dlopen(), that is used by a program in order to allow the end user to add functionality to the program. Examples of plugins include those used by web browsers (flash, acrobat, etc), as well as mdb and elfedit modules. The object that loads the plugin at runtime is called the "parent object". Unlike most object dependencies, the parent is not identified by name, but by its status as the object doing the load. Historically, building a good plugin is has been more complicated than it should be: A parent and its plugin usually share a 2-way dependency: The plugin provides one or more routines for the parent to call, and the parent supplies support routines for use by the plugin for things like memory allocation and error reporting. It is a best practice to build all objects, including plugins, with the -z defs option, in order to ensure that the object specifies all of its dependencies, and is self contained. However: The parent is usually an executable, which cannot be linked to via the usual library mechanisms provided by the link editor. Even if the parent is a shared object, which could be a normal library dependency to the plugin, it may be desirable to build plugins that can be used by more than one parent, in which case embedding a dependency NEEDED entry for one of the parents is undesirable. The usual way to build a high quality plugin with -z defs uses a special mapfile provided by the parent. This mapfile defines the parent routines, specifying the PARENT attribute (see example below). This works, but is inconvenient, and error prone. The symbol table in the parent already describes what it makes available to plugins — ideally the plugin would obtain that information directly rather than from a separate mapfile. The new -z parent option to ld allows a plugin to link to the parent and access the parent symbol table. This differs from a typical dependency: No NEEDED record is created. The relationship is recorded as a logical connection to the parent, rather than as an explicit object name However, it operates in the same manner as any other dependency in terms of making symbols available to the plugin. When the -z parent option is used, the link-editor records the basename of the parent object in the dynamic section, using the new tag DT_SUNW_PARENT. This is an informational tag, which is not used by the runtime linker to locate the parent, but which is available for diagnostic purposes. The ld(1) manpage documentation for the -z parent option is: -z parent=object Specifies a "parent object", which can be an executable or shared object, against which to link the output object. This option is typically used when creating "plugin" shared objects intended to be loaded by an executable at runtime via the dlopen() function. The symbol table from the parent object is used to satisfy references from the plugin object. The use of the -z parent option makes symbols from the object calling dlopen() available to the plugin. Example For this example, we use a main program, and a plugin. The parent provides a function named parent_callback() for the plugin to call. The plugin provides a function named plugin_func() to the parent: % cat main.c #include <stdio.h> #include <dlfcn.h> #include <link.h> void parent_callback(void) { printf("plugin_func() has called parent_callback()\n"); } int main(int argc, char **argv) { typedef void plugin_func_t(void); void *hdl; plugin_func_t *plugin_func; if (argc != 2) { fprintf(stderr, "usage: main plugin\n"); return (1); } if ((hdl = dlopen(argv[1], RTLD_LAZY)) == NULL) { fprintf(stderr, "unable to load plugin: %s\n", dlerror()); return (1); } plugin_func = (plugin_func_t *) dlsym(hdl, "plugin_func"); if (plugin_func == NULL) { fprintf(stderr, "unable to find plugin_func: %s\n", dlerror()); return (1); } (*plugin_func)(); return (0); } % cat plugin.c #include <stdio.h> extern void parent_callback(void); void plugin_func(void) { printf("parent has called plugin_func() from plugin.so\n"); parent_callback(); } Building this in the traditional manner, without -zdefs: % cc -o main main.c % cc -G -o plugin.so plugin.c % ./main ./plugin.so parent has called plugin_func() from plugin.so plugin_func() has called parent_callback() As noted above, when building any shared object, the -z defs option is recommended, in order to ensure that the object is self contained and specifies all of its dependencies. However, the use of -z defs prevents the plugin object from linking due to the unsatisfied symbol from the parent object: % cc -zdefs -G -o plugin.so plugin.c Undefined first referenced symbol in file parent_callback plugin.o ld: fatal: symbol referencing errors. No output written to plugin.so A mapfile can be used to specify to ld that the parent_callback symbol is supplied by the parent object. % cat plugin.mapfile $mapfile_version 2 SYMBOL_SCOPE { global: parent_callback { FLAGS = PARENT }; }; % cc -zdefs -Mplugin.mapfile -G -o plugin.so plugin.c However, the -z parent option to ld is the most direct solution to this problem, allowing the plugin to actually link against the parent object, and obtain the available symbols from it. An added benefit of using -z parent instead of a mapfile, is that the name of the parent object is recorded in the dynamic section of the plugin, and can be displayed by the file utility: % cc -zdefs -zparent=main -G -o plugin.so plugin.c % elfdump -d plugin.so | grep PARENT [0] SUNW_PARENT 0xcc main % file plugin.so plugin.so: ELF 32-bit LSB dynamic lib 80386 Version 1, parent main, dynamically linked, not stripped % ./main ./plugin.so parent has called plugin_func() from plugin.so plugin_func() has called parent_callback() We can also observe this in elfedit plugins on Solaris systems running Solaris 11 Update 1 or newer: % file /usr/lib/elfedit/dyn.so /usr/lib/elfedit/dyn.so: ELF 32-bit LSB dynamic lib 80386 Version 1, parent elfedit, dynamically linked, not stripped, no debugging information available Related Other Work The GNU ld has an option named --just-symbols that can be used in a similar manner: --just-symbols=filename Read symbol names and their addresses from filename, but do not relocate it or include it in the output. This allows your output file to refer symbolically to absolute locations of memory defined in other programs. You may use this option more than once. -z parent is a higher level operation aimed specifically at simplifying the construction of high quality plugins. Although it employs the same operation, it differs from --just symbols in 2 significant ways: There can only be one parent. The parent is recorded in the created object, and can be displayed by 'file', or other similar tools.

  Read the article

• Anatomy of a .NET Assembly - CLR metadata 1

  - by Simon Cooper

  Before we look at the bytes comprising the CLR-specific data inside an assembly, we first need to understand the logical format of the metadata (For this post I only be looking at simple pure-IL assemblies; mixed-mode assemblies & other things complicates things quite a bit). Metadata streams Most of the CLR-specific data inside an assembly is inside one of 5 streams, which are analogous to the sections in a PE file. The name of each section in a PE file starts with a ., and the name of each stream in the CLR metadata starts with a #. All but one of the streams are heaps, which store unstructured binary data. The predefined streams are: #~ Also called the metadata stream, this stream stores all the information on the types, methods, fields, properties and events in the assembly. Unlike the other streams, the metadata stream has predefined contents & structure. #Strings This heap is where all the namespace, type & member names are stored. It is referenced extensively from the #~ stream, as we'll be looking at later. #US Also known as the user string heap, this stream stores all the strings used in code directly. All the strings you embed in your source code end up in here. This stream is only referenced from method bodies. #GUID This heap exclusively stores GUIDs used throughout the assembly. #Blob This heap is for storing pure binary data - method signatures, generic instantiations, that sort of thing. Items inside the heaps (#Strings, #US, #GUID and #Blob) are indexed using a simple binary offset from the start of the heap. At that offset is a coded integer giving the length of that item, then the item's bytes immediately follow. The #GUID stream is slightly different, in that GUIDs are all 16 bytes long, so a length isn't required. Metadata tables The #~ stream contains all the assembly metadata. The metadata is organised into 45 tables, which are binary arrays of predefined structures containing information on various aspects of the metadata. Each entry in a table is called a row, and the rows are simply concatentated together in the file on disk. For example, each row in the TypeRef table contains: A reference to where the type is defined (most of the time, a row in the AssemblyRef table). An offset into the #Strings heap with the name of the type An offset into the #Strings heap with the namespace of the type. in that order. The important tables are (with their table number in hex): 0x2: TypeDef 0x4: FieldDef 0x6: MethodDef 0x14: EventDef 0x17: PropertyDef Contains basic information on all the types, fields, methods, events and properties defined in the assembly. 0x1: TypeRef The details of all the referenced types defined in other assemblies. 0xa: MemberRef The details of all the referenced members of types defined in other assemblies. 0x9: InterfaceImpl Links the types defined in the assembly with the interfaces that type implements. 0xc: CustomAttribute Contains information on all the attributes applied to elements in this assembly, from method parameters to the assembly itself. 0x18: MethodSemantics Links properties and events with the methods that comprise the get/set or add/remove methods of the property or method. 0x1b: TypeSpec 0x2b: MethodSpec These tables provide instantiations of generic types and methods for each usage within the assembly. There are several ways to reference a single row within a table. The simplest is to simply specify the 1-based row index (RID). The indexes are 1-based so a value of 0 can represent 'null'. In this case, which table the row index refers to is inferred from the context. If the table can't be determined from the context, then a particular row is specified using a token. This is a 4-byte value with the most significant byte specifying the table, and the other 3 specifying the 1-based RID within that table. This is generally how a metadata table row is referenced from the instruction stream in method bodies. The third way is to use a coded token, which we will look at in the next post. So, back to the bytes Now we've got a rough idea of how the metadata is logically arranged, we can now look at the bytes comprising the start of the CLR data within an assembly: The first 8 bytes of the .text section are used by the CLR loader stub. After that, the CLR-specific data starts with the CLI header. I've highlighted the important bytes in the diagram. In order, they are: The size of the header. As the header is a fixed size, this is always 0x48. The CLR major version. This is always 2, even for .NET 4 assemblies. The CLR minor version. This is always 5, even for .NET 4 assemblies, and seems to be ignored by the runtime. The RVA and size of the metadata header. In the diagram, the RVA 0x20e4 corresponds to the file offset 0x2e4 Various flags specifying if this assembly is pure-IL, whether it is strong name signed, and whether it should be run as 32-bit (this is how the CLR differentiates between x86 and AnyCPU assemblies). A token pointing to the entrypoint of the assembly. In this case, 06 (the last byte) refers to the MethodDef table, and 01 00 00 refers to to the first row in that table. (after a gap) RVA of the strong name signature hash, which comes straight after the CLI header. The RVA 0x2050 corresponds to file offset 0x250. The rest of the CLI header is mainly used in mixed-mode assemblies, and so is zeroed in this pure-IL assembly. After the CLI header comes the strong name hash, which is a SHA-1 hash of the assembly using the strong name key. After that comes the bodies of all the methods in the assembly concatentated together. Each method body starts off with a header, which I'll be looking at later. As you can see, this is a very small assembly with only 2 methods (an instance constructor and a Main method). After that, near the end of the .text section, comes the metadata, containing a metadata header and the 5 streams discussed above. We'll be looking at this in the next post. Conclusion The CLI header data doesn't have much to it, but we've covered some concepts that will be important in later posts - the logical structure of the CLR metadata and the overall layout of CLR data within the .text section. Next, I'll have a look at the contents of the #~ stream, and how the table data is arranged on disk.

  Read the article

• Open GL stars are not rendering

  - by Darestium

  I doing Nehe's Open GL Lesson 9. I'm using SFML for windowing, the strange thing is no stars are rendering. #include <SFML/System.hpp> #include <SFML/Window.hpp> #include <SFML/Graphics.hpp> #include <iostream> void processEvents(sf::Window *app); void processInput(sf::Window *app); void renderGlScene(sf::Window *app); void init(); int loadResources(); const int NUM_OF_STARS = 50; float triRot = 0.0f; float quadRot = 0.0f; bool twinkle = false; bool tKey = false; float zoom = 15.0f; float tilt = 90.0f; float spin = 0.0f; unsigned int loop; unsigned int texture_handle[1]; typedef struct { int r, g, b; float distance; float angle; } stars; stars star[NUM_OF_STARS]; int main() { sf::Window app(sf::VideoMode(800, 600, 32), "Nehe Lesson 9"); app.UseVerticalSync(false); init(); if (loadResources() == -1) { return EXIT_FAILURE; } while (app.IsOpened()) { processEvents(&app); processInput(&app); renderGlScene(&app); app.Display(); } return EXIT_SUCCESS; } int loadResources() { sf::Image img_data; // Load Texture if (!img_data.LoadFromFile("data/images/star.bmp")) { std::cout << "Could not load data/images/star.bmp"; return -1; } // Generate 1 texture glGenTextures(1, &texture_handle[0]); // Linear filtering glBindTexture(GL_TEXTURE_2D, texture_handle[0]); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, img_data.GetWidth(), img_data.GetHeight(), 0, GL_RGBA, GL_UNSIGNED_BYTE, img_data.GetPixelsPtr()); return 0; } void processInput(sf::Window *app) { const sf::Input& input = app->GetInput(); if (input.IsKeyDown(sf::Key::T) && !tKey) { tKey = true; twinkle = !twinkle; } if (!input.IsKeyDown(sf::Key::T)) { tKey = false; } if (input.IsKeyDown(sf::Key::Up)) { tilt -= 0.05f; } if (input.IsKeyDown(sf::Key::Down)) { tilt += 0.05f; } if (input.IsKeyDown(sf::Key::PageUp)) { zoom -= 0.02f; } if (input.IsKeyDown(sf::Key::Up)) { zoom += 0.02f; } } void init() { glClearDepth(1.f); glClearColor(0.f, 0.f, 0.f, 0.f); // Enable texturing glEnable(GL_TEXTURE_2D); //glDepthMask(GL_TRUE); // Setup a perpective projection glMatrixMode(GL_PROJECTION); glLoadIdentity(); gluPerspective(45.f, 1.f, 1.f, 500.f); glShadeModel(GL_SMOOTH); glBlendFunc(GL_SRC_ALPHA, GL_ONE); glEnable(GL_BLEND); for (loop = 0; loop < NUM_OF_STARS; loop++) { star[loop].distance = (float)loop / NUM_OF_STARS * 5.0f; // Calculate distance from the centre // Give stars random rgb value star[loop].r = rand() % 256; star[loop].g = rand() % 256; star[loop].b = rand() % 256; } } void processEvents(sf::Window *app) { sf::Event event; while (app->GetEvent(event)) { if (event.Type == sf::Event::Closed) { app->Close(); } if (event.Type == sf::Event::KeyPressed && event.Key.Code == sf::Key::Escape) { app->Close(); } } } void renderGlScene(sf::Window *app) { app->SetActive(); // Clear color depth buffer glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // Apply some transformations glMatrixMode(GL_MODELVIEW); glLoadIdentity(); // Select texture glBindTexture(GL_TEXTURE_2D, texture_handle[0]); for (loop = 0; loop < NUM_OF_STARS; loop++) { glLoadIdentity(); // Reset The View Before We Draw Each Star glTranslatef(0.0f, 0.0f, zoom); // Zoom Into The Screen (Using The Value In 'zoom') glRotatef(tilt, 1.0f, 0.0f, 0.0f); // Tilt The View (Using The Value In 'tilt') glRotatef(star[loop].angle, 0.0f, 1.0f, 0.0f); // Rotate To The Current Stars Angle glTranslatef(star[loop].distance, 0.0f, 0.0f); // Move Forward On The X Plane glRotatef(-star[loop].angle,0.0f,1.0f,0.0f); // Cancel The Current Stars Angle glRotatef(-tilt,1.0f,0.0f,0.0f); // Cancel The Screen Tilt if (twinkle) { glColor4ub(star[(NUM_OF_STARS - loop) - 1].r, star[(NUM_OF_STARS - loop)-1].g, star[(NUM_OF_STARS - loop) - 1].b, 255); glBegin(GL_QUADS); // Begin Drawing The Textured Quad glTexCoord2f(0.0f, 0.0f); glVertex3f(-1.0f, -1.0f, 0.0f); glTexCoord2f(1.0f, 0.0f); glVertex3f( 1.0f, -1.0f, 0.0f); glTexCoord2f(1.0f, 1.0f); glVertex3f( 1.0f, 1.0f, 0.0f); glTexCoord2f(0.0f, 1.0f); glVertex3f(-1.0f, 1.0f, 0.0f); glEnd(); // Done Drawing The Textured Quad } glRotatef(spin,0.0f,0.0f,1.0f); // Rotate The Star On The Z Axis // Assign A Color Using Bytes glColor4ub(star[loop].r, star[loop].g, star[loop].b, 255); glBegin(GL_QUADS); // Begin Drawing The Textured Quad glTexCoord2f(0.0f, 0.0f); glVertex3f(-1.0f,-1.0f, 0.0f); glTexCoord2f(1.0f, 0.0f); glVertex3f( 1.0f,-1.0f, 0.0f); glTexCoord2f(1.0f, 1.0f); glVertex3f( 1.0f, 1.0f, 0.0f); glTexCoord2f(0.0f, 1.0f); glVertex3f(-1.0f, 1.0f, 0.0f); glEnd(); // Done Drawing The Textured Quad spin += 0.01f; // Used To Spin The Stars star[loop].angle += (float)loop / NUM_OF_STARS; // Changes The Angle Of A Star star[loop].distance -= 0.01f; // Changes The Distance Of A Star if (star[loop].distance < 0.0f) { star[loop].distance += 5.0f; // Move The Star 5 Units From The Center star[loop].r = rand() % 256; // Give It A New Red Value star[loop].g = rand() % 256; // Give It A New Green Value star[loop].b = rand() % 256; // Give It A New Blue Value } } } I've looked over the code atleast 10 times now and I can't figure out the problem. Any help would be much appreciated.

  Read the article

• boost fusion: strange problem depending on number of elements on a vector

  - by ChAoS

  I am trying to use Boost::Fusion (Boost v1.42.0) in a personal project. I get an interesting error with this code: #include "boost/fusion/include/sequence.hpp" #include "boost/fusion/include/make_vector.hpp" #include "boost/fusion/include/insert.hpp" #include "boost/fusion/include/invoke_procedure.hpp" #include "boost/fusion/include/make_vector.hpp" #include <iostream> class Class1 { public: typedef boost::fusion::vector<int,float,float,char,int,int> SequenceType; SequenceType s; Class1(SequenceType v):s(v){} }; class Class2 { public: Class2(){} void met(int a,float b ,float c ,char d ,int e,int f) { std::cout << a << " " << b << " " << c << " " << d << " " << e << std::endl; } }; int main(int argn, char**) { Class2 p; Class1 t(boost::fusion::make_vector(9,7.66f,8.99f,'s',7,6)); boost::fusion::begin(t.s); //OK boost::fusion::insert(t.s, boost::fusion::begin(t.s), &p); //OK boost::fusion::invoke_procedure(&Class2::met,boost::fusion::insert(t.s, boost::fusion::begin(t.s), &p)); //FAILS } It fails to compile (gcc 4.4.1): In file included from /home/thechaos/Escriptori/of_preRelease_v0061_linux_FAT/addons/ofxTableGestures/ext/boost/fusion/include/invoke_procedur e.hpp:10, from problema concepte.cpp:11: /home/thechaos/Escriptori/of_preRelease_v0061_linux_FAT/addons/ofxTableGestures/ext/boost/fusion/functional/invocation/invoke_procedure.hpp: I n function ‘void boost::fusion::invoke_procedure(Function, const Sequence&) [with Function = void (Class2::*)(int, float, float, char, int, in t), Sequence = boost::fusion::joint_view<boost::fusion::joint_view<boost::fusion::iterator_range<boost::fusion::vector_iterator<const boost::f usion::vector<int, float, float, char, int, int, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_>, 0>, boost::fusion::vector_iterator<boost::fusion::vector<int, float, float, char, int, int, boost::fusion::void_, boost::fusion::void_, boost::fus ion::void_, boost::fusion::void_>, 0> >, const boost::fusion::single_view<Class2*> >, boost::fusion::iterator_range<boost::fusion::vector_iter ator<boost::fusion::vector<int, float, float, char, int, int, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion: :void_>, 0>, boost::fusion::vector_iterator<const boost::fusion::vector<int, float, float, char, int, int, boost::fusion::void_, boost::fusion ::void_, boost::fusion::void_, boost::fusion::void_>, 6> > >]’: problema concepte.cpp:39: instantiated from here /home/thechaos/Escriptori/of_preRelease_v0061_linux_FAT/addons/ofxTableGestures/ext/boost/fusion/functional/invocation/invoke_procedure.hpp:88 : error: incomplete type ‘boost::fusion::detail::invoke_procedure_impl<void (Class2::*)(int, float, float, char, int, int), const boost::fusio n::joint_view<boost::fusion::joint_view<boost::fusion::iterator_range<boost::fusion::vector_iterator<const boost::fusion::vector<int, float, f loat, char, int, int, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_>, 0>, boost::fusion::vector_itera tor<boost::fusion::vector<int, float, float, char, int, int, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion:: void_>, 0> >, const boost::fusion::single_view<Class2*> >, boost::fusion::iterator_range<boost::fusion::vector_iterator<boost::fusion::vector< int, float, float, char, int, int, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_>, 0>, boost::fusion: :vector_iterator<const boost::fusion::vector<int, float, float, char, int, int, boost::fusion::void_, boost::fusion::void_, boost::fusion::voi d_, boost::fusion::void_>, 6> > >, 7, true, false>’ used in nested name specifier However, if I change the number of arguments in the vectors and the method from 6 to 5 from int,float,float,char,int,int to int,float,float,char,int,I can compile it without problems. I suspected about the maximum number of arguments being a limitation, but I tried to change it through defining FUSION_MAX_VECTOR_SIZE without success. I am unable to see what am I doing wrong. Can you reproduce this? Can it be a boost bug (i doubt it but is not impossible)?

  Read the article

• overriding ctype<wchar_t>

  - by Potatoswatter

  I'm writing a lambda calculus interpreter for fun and practice. I got iostreams to properly tokenize identifiers by adding a ctype facet which defines punctuation as whitespace: struct token_ctype : ctype<char> { mask t[ table_size ]; token_ctype() : ctype<char>( t ) { for ( size_t tx = 0; tx < table_size; ++ tx ) { t[tx] = isalnum( tx )? alnum : space; } } }; (classic_table() would probably be cleaner but that doesn't work on OS X!) And then swap the facet in when I hit an identifier: locale token_loc( in.getloc(), new token_ctype ); … locale const &oldloc = in.imbue( token_loc ); in.unget() >> token; in.imbue( oldloc ); There seems to be surprisingly little lambda calculus code on the Web. Most of what I've found so far is full of unicode ? characters. So I thought to try adding Unicode support. But ctype<wchar_t> works completely differently from ctype<char>. There is no master table; there are four methods do_is x2, do_scan_is, and do_scan_not. So I did this: struct token_ctype : ctype< wchar_t > { typedef ctype<wchar_t> base; bool do_is( mask m, char_type c ) const { return base::do_is(m,c) || (m&space) && ( base::do_is(punct,c) || c == L'?' ); } const char_type* do_is (const char_type* lo, const char_type* hi, mask* vec) const { base::do_is(lo,hi,vec); for ( mask *vp = vec; lo != hi; ++ vp, ++ lo ) { if ( *vp & punct || *lo == L'?' ) *vp |= space; } return hi; } const char_type *do_scan_is (mask m, const char_type* lo, const char_type* hi) const { if ( m & space ) m |= punct; hi = do_scan_is(m,lo,hi); if ( m & space ) hi = find( lo, hi, L'?' ); return hi; } const char_type *do_scan_not (mask m, const char_type* lo, const char_type* hi) const { if ( m & space ) { m |= punct; while ( * ( lo = base::do_scan_not(m,lo,hi) ) == L'?' && lo != hi ) ++ lo; return lo; } return base::do_scan_not(m,lo,hi); } }; (Apologies for the flat formatting; the preview converted the tabs differently.) The code is WAY less elegant. I does better express the notion that only punctuation is additional whitespace, but that would've been fine in the original had I had classic_table. Is there a simpler way to do this? Do I really need all those overloads? (Testing showed do_scan_not is extraneous here, but I'm thinking more broadly.) Am I abusing facets in the first place? Is the above even correct? Would it be better style to implement less logic?

  Read the article

• issue with std::advance on std::sets

  - by tim

  I've stumbled upon what I believe is a bug in the stl algorithm advance. When I'm advancing the iterator off of the end of the container, I get inconsistent results. Sometimes I get container.end(), sometimes I get the last element. I've illustrated this with the following code: #include <algorithm> #include <cstdio> #include <set> using namespace std; typedef set<int> tMap; int main(int argc, char** argv) { tMap::iterator i; tMap the_map; for (int i=0; i<10; i++) the_map.insert(i); #if EXPERIMENT==1 i = the_map.begin(); #elif EXPERIMENT==2 i = the_map.find(4); #elif EXPERIMENT==3 i = the_map.find(5); #elif EXPERIMENT==4 i = the_map.find(6); #elif EXPERIMENT==5 i = the_map.find(9); #elif EXPERIMENT==6 i = the_map.find(2000); #else i = the_map.end(); #endif advance(i, 100); if (i == the_map.end()) printf("the end\n"); else printf("wuh? %d\n", *i); return 0; } Which I get the following unexpected (according to me) behavior in experiment 3 and 5 where I get the last element instead of the_map.end(). [tim@saturn advance]$ uname -srvmpio Linux 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006 i686 athlon i386 GNU/Linux [tim@saturn advance]$ g++ --version g++ (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [tim@saturn advance]$ g++ -DEXPERIMENT=1 advance.cc [tim@saturn advance]$ ./a.out the end [tim@saturn advance]$ g++ -DEXPERIMENT=2 advance.cc [tim@saturn advance]$ ./a.out the end [tim@saturn advance]$ g++ -DEXPERIMENT=3 advance.cc [tim@saturn advance]$ ./a.out wuh? 9 [tim@saturn advance]$ g++ -DEXPERIMENT=4 advance.cc [tim@saturn advance]$ ./a.out the end [tim@saturn advance]$ g++ -DEXPERIMENT=5 advance.cc [tim@saturn advance]$ ./a.out wuh? 9 [tim@saturn advance]$ g++ -DEXPERIMENT=6 advance.cc [tim@saturn advance]$ ./a.out the end [tim@saturn advance]$ g++ -DEXPERIMENT=7 advance.cc [tim@saturn advance]$ ./a.out the end [tim@saturn advance]$ From the sgi website (see link at top), it has the following example: list<int> L; L.push_back(0); L.push_back(1); list<int>::iterator i = L.begin(); advance(i, 2); assert(i == L.end()); I would think that the assertion should apply to other container types, no? What am I missing? Thanks!

  Read the article

• Need help with BOOST_FOREACH/compiler bug

  - by Jacek Lawrynowicz

  I know that boost or compiler should be last to blame, but I can't see another explanation here. I'm using msvc 2008 SP1 and boost 1.43. In the following code snippet execution never leaves third BOOST_FOREACH loop typedef Graph<unsigned, unsigned>::VertexIterator Iter; Graph<unsigned, unsigned> g; g.createVertex(0x66); // works fine Iter it = g.getVertices().first, end = g.getVertices().second; for(; it != end; ++it) ; // fine std::pair<Iter, Iter> p = g.getVertices(); BOOST_FOREACH(unsigned handle, p) ; // fine unsigned vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) vertex_count++; // oops, infinite loop vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) vertex_count++; vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) vertex_count++; // ... last block repeated 7 times Iterator code: class Iterator : public boost::iterator_facade<Iterator, unsigned const, boost::bidirectional_traversal_tag> { public: Iterator() : list(NULL), handle(INVALID_ELEMENT_HANDLE) {} explicit Iterator(const VectorElementsList &list, unsigned handle = INVALID_ELEMENT_HANDLE) : list(&list), handle(handle) {} friend std::ostream& operator<<(std::ostream &s, const Iterator &it) { s << "[list: " << it.list <<", handle: " << it.handle << "]"; return s; } private: friend class boost::iterator_core_access; void increment() { handle = list->getNext(handle); } void decrement() { handle = list->getPrev(handle); } unsigned const& dereference() const { return handle; } bool equal(Iterator const& other) const { return handle == other.handle && list == other.list; } const VectorElementsList<T> *list; unsigned handle; }; Some ASM fun: vertex_count = 0; BOOST_FOREACH(unsigned handle, g.getVertices()) // initialization 013E1369 mov edi,dword ptr [___defaultmatherr+8 (13E5034h)] // end iterator handle: 0xFFFFFFFF 013E136F mov ebp,dword ptr [esp+0ACh] // begin iterator handle: 0x0 013E1376 lea esi,[esp+0A8h] // begin iterator list pointer 013E137D mov ebx,esi 013E137F nop // forever loop begin 013E1380 cmp ebp,edi 013E1382 jne main+238h (13E1388h) 013E1384 cmp ebx,esi 013E1386 je main+244h (13E1394h) 013E1388 lea eax,[esp+18h] 013E138C push eax // here iterator is incremented in ram 013E138D call boost::iterator_facade<detail::VectorElementsList<Graph<unsigned int,unsigned int>::VertexWrapper>::Iterator,unsigned int const ,boost::bidirectional_traversal_tag,unsigned int const &,int>::operator++ (13E18E0h) 013E1392 jmp main+230h (13E1380h) vertex_count++; // forever loop end It's easy to see that iterator handle is cached in EBP and it never gets incremented despite of a call to iterator operator++() function. I've replaced Itarator implmentation with one deriving from std::iterator and the issue persisted, so this is not iterator_facade fault. This problem exists only on msvc 2008 SP1 x86 and amd64 release builds. Debug builds on msvc 2008 and debug/release builds on msvc 2010 and gcc 4.4 (linux) works fine. Furthermore the BOOST_FOREACH block must be repeaded exacly 10 times. If it's repeaded 9 times, it's all OK. I guess that due to BOOST_FOREACH use of template trickery (const auto_any), compiler assumes that iterator handle is constant and never reads its real value again. I would be very happy to hear that my code is wrong, correct it and move on with BOOST_FOREACH, which I'm very found of (as opposed to BOOST_FOREVER :). May be related to: http://stackoverflow.com/questions/1275852/why-does-boost-foreach-not-work-sometimes-with-c-strings

  Read the article

• FreeType2 Bitmap to System::Drawing::Bitmap.

  - by Dennis Roche

  Hi, I'm trying to convert a FreeType2 bitmap to a System::Drawing::Bitmap in C++/CLI. FT_Bitmap has a unsigned char* buffer that contains the data to write. I have got somewhat working save it disk as a *.tga, but when saving as *.bmp it renders incorrectly. I believe that the size of byte[] is incorrect and that my data is truncated. Any hints/tips/ideas on what is going on here would be greatly appreciated. Links to articles explaining byte layout and pixel formats etc. would be helpful. Thanks!! C++/CLI code. FT_Bitmap *bitmap = &face->glyph->bitmap; int width = (face->bitmap->metrics.width / 64); int height = (face->bitmap->metrics.height / 64); // must be aligned on a 32 bit boundary or 4 bytes int depth = 8; int stride = ((width * depth + 31) & ~31) >> 3; int bytes = (int)(stride * height); // as *.tga void *buffer = bytes ? malloc(bytes) : NULL; if (buffer) { memset(buffer, 0, bytes); for (int i = 0; i < glyph->rows; ++i) memcpy((char *)buffer + (i * width), glyph->buffer + (i * glyph->pitch), glyph->pitch); WriteTGA("Test.tga", buffer, width, height); } array<Byte>^ values = gcnew array<Byte>(bytes); Marshal::Copy((IntPtr)glyph->buffer, values, 0, bytes); // as *.bmp Bitmap^ systemBitmap = gcnew Bitmap(width, height, PixelFormat::Format24bppRgb); // create bitmap data, lock pixels to be written. BitmapData^ bitmapData = systemBitmap->LockBits(Rectangle(0, 0, width, height), ImageLockMode::WriteOnly, bitmap->PixelFormat); Marshal::Copy(values, 0, bitmapData->Scan0, bytes); systemBitmap->UnlockBits(bitmapData); systemBitmap->Save("Test.bmp"); Reference, FT_Bitmap typedef struct FT_Bitmap_ { int rows; int width; int pitch; unsigned char* buffer; short num_grays; char pixel_mode; char palette_mode; void* palette; } FT_Bitmap; Reference, WriteTGA bool WriteTGA(const char *filename, void *pxl, uint16 width, uint16 height) { FILE *fp = NULL; fopen_s(&fp, filename, "wb"); if (fp) { TGAHeader header; memset(&header, 0, sizeof(TGAHeader)); header.imageType = 3; header.width = width; header.height = height; header.depth = 8; header.descriptor = 0x20; fwrite(&header, sizeof(header), 1, fp); fwrite(pxl, sizeof(uint8) * width * height, 1, fp); fclose(fp); return true; } return false; }

  Read the article

• iPhone SDK / Objective C Syntax Question

  - by Koppo

  To all, I was looking at the sample project from http://iphoneonrails.com/ and I saw they took the NSObject class and added methods to it for the SOAP calls. Their sample project can be downloaded from here http://iphoneonrails.com/downloads/objective_resource-1.01.zip. My question is related to my lack of knowledge on the following syntax as I haven't seen it yet in a iPhone project. There is a header file called NSObject+ObjectiveResource.h where they declare and change NSObject to have extra methods for this project. Is the "+ObjectiveResource.h" in the name there a special syntax or is that just the naming convention of the developers. Finally inside the class NSObject we have the following #import <Foundation/Foundation.h> @interface NSObject (ObjectiveResource) // Response Formats typedef enum { XmlResponse = 0, JSONResponse, } ORSResponseFormat; // Resource configuration + (NSString *)getRemoteSite; + (void)setRemoteSite:(NSString*)siteURL; + (NSString *)getRemoteUser; + (void)setRemoteUser:(NSString *)user; + (NSString *)getRemotePassword; + (void)setRemotePassword:(NSString *)password; + (SEL)getRemoteParseDataMethod; + (void)setRemoteParseDataMethod:(SEL)parseMethod; + (SEL) getRemoteSerializeMethod; + (void) setRemoteSerializeMethod:(SEL)serializeMethod; + (NSString *)getRemoteProtocolExtension; + (void)setRemoteProtocolExtension:(NSString *)protocolExtension; + (void)setRemoteResponseType:(ORSResponseFormat) format; + (ORSResponseFormat)getRemoteResponseType; // Finders + (NSArray *)findAllRemote; + (NSArray *)findAllRemoteWithResponse:(NSError **)aError; + (id)findRemote:(NSString *)elementId; + (id)findRemote:(NSString *)elementId withResponse:(NSError **)aError; // URL construction accessors + (NSString *)getRemoteElementName; + (NSString *)getRemoteCollectionName; + (NSString *)getRemoteElementPath:(NSString *)elementId; + (NSString *)getRemoteCollectionPath; + (NSString *)getRemoteCollectionPathWithParameters:(NSDictionary *)parameters; + (NSString *)populateRemotePath:(NSString *)path withParameters:(NSDictionary *)parameters; // Instance-specific methods - (id)getRemoteId; - (void)setRemoteId:(id)orsId; - (NSString *)getRemoteClassIdName; - (BOOL)createRemote; - (BOOL)createRemoteWithResponse:(NSError **)aError; - (BOOL)createRemoteWithParameters:(NSDictionary *)parameters; - (BOOL)createRemoteWithParameters:(NSDictionary *)parameters andResponse:(NSError **)aError; - (BOOL)destroyRemote; - (BOOL)destroyRemoteWithResponse:(NSError **)aError; - (BOOL)updateRemote; - (BOOL)updateRemoteWithResponse:(NSError **)aError; - (BOOL)saveRemote; - (BOOL)saveRemoteWithResponse:(NSError **)aError; - (BOOL)createRemoteAtPath:(NSString *)path withResponse:(NSError **)aError; - (BOOL)updateRemoteAtPath:(NSString *)path withResponse:(NSError **)aError; - (BOOL)destroyRemoteAtPath:(NSString *)path withResponse:(NSError **)aError; // Instance helpers for getting at commonly used class-level values - (NSString *)getRemoteCollectionPath; - (NSString *)convertToRemoteExpectedType; //Equality test for remote enabled objects based on class name and remote id - (BOOL)isEqualToRemote:(id)anObject; - (NSUInteger)hashForRemote; @end What is the "ObjectiveResource" in the () mean for NSObject? What is that telling Xcode and the compiler about what is happening..? After that things look normal to me as they have various static and instance methods. I know that by doing this all user classes that inherit from NSObject now have all the extra methods for this project. My question is what is the parenthesis are doing after the NSObject. Is that referencing a header file, or is that letting the compiler know that this class is being over ridden. Thanks again and my apologies ahead of time if this is a dumb question but just trying to learn what I lack.

  Read the article

• unsigned char* buffer (FreeType2 Bitmap) to System::Drawing::Bitmap.

  - by Dennis Roche

  Hi, I'm trying to convert a FreeType2 bitmap to a System::Drawing::Bitmap in C++/CLI. FT_Bitmap has a unsigned char* buffer that contains the data to write. I have got somewhat working save it disk as a *.tga, but when saving as *.bmp it renders incorrectly. I believe that the size of byte[] is incorrect and that my data is truncated. Any hints/tips/ideas on what is going on here would be greatly appreciated. Links to articles explaining byte layout and pixel formats etc. would be helpful. Thanks!! C++/CLI code. FT_Bitmap *bitmap = &face->glyph->bitmap; int width = (face->bitmap->metrics.width / 64); int height = (face->bitmap->metrics.height / 64); // must be aligned on a 32 bit boundary or 4 bytes int depth = 8; int stride = ((width * depth + 31) & ~31) >> 3; int bytes = (int)(stride * height); // as *.tga void *buffer = bytes ? malloc(bytes) : NULL; if (buffer) { memset(buffer, 0, bytes); for (int i = 0; i < glyph->rows; ++i) memcpy((char *)buffer + (i * width), glyph->buffer + (i * glyph->pitch), glyph->pitch); WriteTGA("Test.tga", buffer, width, height); } // as *.bmp array<Byte>^ values = gcnew array<Byte>(bytes); Marshal::Copy((IntPtr)glyph->buffer, values, 0, bytes); Bitmap^ systemBitmap = gcnew Bitmap(width, height, PixelFormat::Format24bppRgb); // create bitmap data, lock pixels to be written. BitmapData^ bitmapData = systemBitmap->LockBits(Rectangle(0, 0, width, height), ImageLockMode::WriteOnly, bitmap->PixelFormat); Marshal::Copy(values, 0, bitmapData->Scan0, bytes); systemBitmap->UnlockBits(bitmapData); systemBitmap->Save("Test.bmp"); Reference, FT_Bitmap typedef struct FT_Bitmap_ { int rows; int width; int pitch; unsigned char* buffer; short num_grays; char pixel_mode; char palette_mode; void* palette; } FT_Bitmap; Reference, WriteTGA bool WriteTGA(const char *filename, void *pxl, uint16 width, uint16 height) { FILE *fp = NULL; fopen_s(&fp, filename, "wb"); if (fp) { TGAHeader header; memset(&header, 0, sizeof(TGAHeader)); header.imageType = 3; header.width = width; header.height = height; header.depth = 8; header.descriptor = 0x20; fwrite(&header, sizeof(header), 1, fp); fwrite(pxl, sizeof(uint8) * width * height, 1, fp); fclose(fp); return true; } return false; } Update FT_Bitmap *bitmap = &face->glyph->bitmap; // stride must be aligned on a 32 bit boundary or 4 bytes int depth = 8; int stride = ((width * depth + 31) & ~31) >> 3; int bytes = (int)(stride * height); target = gcnew Bitmap(width, height, PixelFormat::Format8bppIndexed); // create bitmap data, lock pixels to be written. BitmapData^ bitmapData = target->LockBits(Rectangle(0, 0, width, height), ImageLockMode::WriteOnly, target->PixelFormat); array<Byte>^ values = gcnew array<Byte>(bytes); Marshal::Copy((IntPtr)bitmap->buffer, values, 0, bytes); Marshal::Copy(values, 0, bitmapData->Scan0, bytes); target->UnlockBits(bitmapData);

  Read the article

< Previous Page | 32 33 34 35 36 37 38 39 40  | Next Page >