| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9
Comments:
<0> i got an error that there is a failure check
<0> in the ESP
<1> Ok, it does like that (I tried it earlier, but it didn't like the ..start symbol)
<1> Let me piddle a little with ld and tell it the entry point and all.
<0> Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.
<2> I've never used it, I just read the docs
<0> anyone plz
<2> zindo2 the error explanation seems quite clear
<0> but i didn't use any pointer to functions
<0> i call a method of an object
<0> wich is declared in my header file
<2> what compiler are you using?
<0> i'm using visual studio 2005
<0> may be the error come from here
<0> i have an object wich have a multiple inhertance
<0> and both parents have the same name of method
<3> that's a feature of the language
<3> anyway, zindo2 did you try recompiling everything? paste some relevant code to the paste site
<0> HKBUpload *hkUpload = (HKBUpload *) x;
<0> HttpUpload *htUpload = (HttpUpload *) x;
<3> oh, this is multithreaded... maybe you're calling a member function of an object that doesn't exist anymore
<0> x is an LPVOID
<0> and it points to a HKBUpload
<3> why don't you try boost::threads
<0> i'm trying to understand the error
<0> cuz when i used step by step
<3> your casts aren't very good
<4> sorry, got disconnected
<3> vavvjr:
<0> i've seen that the program goes to some other functions
<3> [20:47] <0> HKBUpload *hkUpload = (HKBUpload *) x;
<3> [20:47] <0> HttpUpload *htUpload = (HttpUpload *) x;
<3> where x is void*
<0> my second casting is not good
<3> what was the pointer before you stuffed it into a void* ?
<4> gezus and you crazy???
<0> HKBUpload *
<3> then why would you cast it to something else on the other end?
<0> but how can i call a method that belonging to the HttpUpload
<3> on the other hand, you don't need to stuff it in a void* anyway
<3> just store it somewhere typesafe and pick it up inside the threads
<0> rdragon, the ThreadProc use an LPVOID
<3> so what
<0> rdragon, the problem
<0> is
<3> the problem is your solution
<0> how to call a method of HttpUpload wich has the same name in the HKBUpload
<2> I don't think you can stuff method pointers into a void*
<0> no
<3> zindo2 that's not the problem at all
<0> it's objects pointer
<0> i have a cl*** X: public y, public z {};
<2> if you HAVE to cast, you've likely a design/architecture error somewhere
<0> both y and z have the method f()
<0> how to call each one separatly ?
<3> some_x.y::f(); and some_x.z::f();
<0> ok
<0> thanks a lot
<0> i think this will solve my problem
<3> but I doubt that's going to help you at all
<0> one second to see
<3> your problem is all that nonsense casting
<3> i recommend using boost::threads, first of all
<3> that'll allow you to type-safely send an object to a thread entry point
<0> now, all things go okey
<0> thanks :)
<3> yeah, settle with the crap solution
<0> no, my second casting was wrong
<0> i know that
<3> all of your c-style casts are wrong
<0> heuh ?
<5> morning
<0> what's a c++ casting ?
<3> [20:52] <@vawjr> if you HAVE to cast, you've likely a design/architecture error somewhere
<0> hehe
<6> O_o
<6> that's not nearly true....
<3> zindo2 it sounds like you're not learning c++ from a good source
<5> zindo2, static_cast<int> var; or something li'ke that
<2> oh it's VERY true
<6> it isn't
<3> Pegazus sure it is
<0> DWORD WINAPI ThreadProc(
<0> LPVOID lpParameter
<0> );
<0> no way to avoid that cast :(
<6> that's one good counter example :)
<3> of course there is
<2> yes, that's a design error
<3> no it's not
<0> hehehe :)
<6> O_o
<6> well
<5> rdragon, so casting is bad?
<2> the windows interface ****s donkey ****s
<0> may be
<3> the solution is to not rely on stuffing your types into that void*
<6> vawjr: the windows interface ****s donkey ****s -> i agree with you
<6> but it's not his error
<3> like I said earlier, <@rdragon> i recommend using boost::threads <@rdragon> that'll allow you to type-safely send an object to a thread entry point
<6> and he has no other way of doing it :)
<3> read what I wrote, then retract your statement
<2> and yes, they force you to lie to the compiler (that's what a cast is)
<0> rdragon, this is thanks to templates
<6> anyway, there are times you need to const_cast for making thigs nicer
<6> (check for example boost::iterator lib :))
<3> const_cast is the worst of all casts
<6> sometimes you call a function that takes a non const but you know that in that case it won't modify it
<3> and i would say has the least need
<6> so you need to const_cast
<3> Pegazus then you're working with broken libraries
<6> winapi is one :)
<6> and may be it isn't a broken library
<6> i mean
<6> a function that sometimes modify the parameter
<6> and sometimes doesn't
<3> well, it is, but besides that I think it is pretty const correct
<6> anyway: hi, does anyone know what's the optimal implementation of a multi read one write mutex or where to find it?
<3> if it sometimes modifies it, then you shouldn't be p***ing a const object to it
<3> and you certainly shouldn't be const_casting it to 'make it work'
<3> if the object should be modified, then it shouldn't be const to begin with
<2> Pegazus I thought I recalled there being a read/write mutex in boost::threads...and also a recen bug report against it
<6> rdragon: you may know that in that case it won't modify it
<3> Pegazus that's a dangerous ***umption
<2> Pegazus until someone changes the function
<3> I think they removed the read/write mutex
<6> that isn't a dangerous ***umption if the function is supposed to work like that -_-
<2> badly designed funciton
<6> sometimes you don't choose them
<3> in 1.33.1: "read_write_mutex has been removed due to problems with deadlocks"
<2> as I said desigh/architecture problem
<3> Pegazus you're arguing in circles
<6> and sometimes you must do tradeoffss
<6> check boost::iterator
<6> i told you
<6> there is a const cast inside there
<6> because if not you have to write 2 times the same function
<3> and there's probably a damn good reason
<2> perhaps it's for broken compilers
<6> yes
<6> no
<6> it isn't
<3> what is the reason then?
<6> to just write a function deference
<6> and not 2
<3> what file is it in?
<6> check the library...
<3> it's a big library
<6> -_-
<6> iterator isn't that big
Return to
#c++
or
Go to some related
logs:
#linux
#networking
#php
#skype
#MissKitten
hatharudhan
#c
#c++
#windows
volleyball tips/instructions
|
|