|
I'm not sure if it's an educational thing - I've seen programmers go thread happy several times over my career. There's something intrinsically seductive about parallel programming to loads of programmers even when it's not needed.
Actually, having thought about it a bit more it might be an educational thing, but not related to teaching programming for once. A couple of years ago I did an MSc in Software Engineering and the Operating Systems module was obsessed with threads, scheduling and all things to do with multiprogramming. We spent twice as long on that as we did on either device management and file systems which are far more important.
So I'll settle for the people writing OS textbooks and the lecturers who teach it. The language teachers aren't responsible for that, they're just obsessed with pointers and intrinsic arrays.
Cheers,
Ash
|
|
|
|
|
Yes, I don't really have any evidence for this but I just find it strange that people with (apparently) fairly limited understanding of some basic aspects of programming are already working with threads. Particularly when, as would seem in this case, there is absolutely no point in creating a thread just to run a function.
It's time for a new signature.
|
|
|
|
|
Richard MacCutchan wrote: Particularly when, as would seem in this case, there is absolutely no point in creating a thread just to run a function.
My personal opinion only.... It is that there is no realistic examples for teaching programming. Since the problem for threading serves no purpose related to threading, nor the example for single process systems, the result is a complete lack of understanding of when and how to use threading.
I have seen as many thread happy people, and people deathly afraid of threads. Even one programmer who swore up and down that mutexes were required in threads to speed it up. All mutex operations supposedly would speed up your threads and coding without mutexes would automatically devolve back to a single process operation because the mutex was the key to multi-processing.... 
_________________________
John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Shhhhh.... I am not really here. I am a figment of your imagination.... I am still in my cave so this must be an illusion....
|
|
|
|
|
I'm working with very large files and i need to be able to get a 64bit stream position.
ofstream::tellp() returns a streampos, which according to msdn is typedef fpos<mbstate_t> streampos;
Whatever i try and cast the result to, it's wrong for files over 4GB- it's being truncated at 32 bits.
What is odd is that according to mssn, fpos<t> stores a byte offset of type streamoff, and a conversion state of type T. streamoff (according to msdn) is a long in win32 and an __int64 in win64. I am building under win32 but the debugger shows the private _Fpos member of fpos<t> to be of type __int64.
So, irritatingly, the 64 bit value is there in the fpos (i can see in the debugger, it's correct) but i can't get the value out.
Any ideas? there must be a way of getting a 64bit file pos in win32.
|
|
|
|
|
|
What happens when you use the seekpos member of std::fstream::pos_type (i.e. the thing returned by tellp)?
As far as I can tell that's a 64 bit value (long long on VC++ 2010). Not sure how standard that is as I don't deal with large files much.
Cheers,
Ash
PS:
Something like:
std::fstream fs( ... );
std::fstream::pos_type pt( fs.tellp() );
fpos_t fpt( pt.seekpos() );
EDIT: Looks like this is about as portable as a brick. According to the standard about all streampos has to do is support conversion to/from an int and be comparable with another streampos.
modified on Tuesday, June 22, 2010 12:23 PM
|
|
|
|
|
yeah, it's rubbish, isn't it. pos_type has an int64 member, but there's no operator overload to get that out -only an int.
|
|
|
|
|
Hi!
I've received an error message:
1>e:\criccegui\main.cpp(75) : error C2661: 'CEGUI::SubscriberSlot::SubscriberSlot' : no overloaded function takes 2 arguments
1>e:\criccegui\main.cpp(76) : error C2661: 'CEGUI::SubscriberSlot::SubscriberSlot' : no overloaded function takes 2 arguments
1>e:\criccegui\main.cpp(77) : error C2661: 'CEGUI::SubscriberSlot::SubscriberSlot' : no overloaded function takes 2 arguments
1>e:\criccegui\main.cpp(78) : error C2661: 'CEGUI::SubscriberSlot::SubscriberSlot' : no overloaded function takes 2 arguments
The code corresponding to the error is:
play_btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&InitialMenu::playHandler, this));
options_btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&InitialMenu::optionsHandler, this));
credits_btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&InitialMenu::creditsHandler, this));
exit_btn->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&InitialMenu::exitHandler, this));
I've checked many time the function CEGUI::SubscriberSlot::SubscriberSlot(). It takes two arguments only.
How to resolve these errors?
|
|
|
|
|
OK, maybe I'm blind or undercaffienated but I'm not seeing any mention of SubscriberSlot(...) in the code you posted. 
|
|
|
|
|
Sorry!
It's here. Actually I've to Subscribe to a member function.
template<typename T>
SubscriberSlot(bool (T::*function)(const EventArgs&), T* obj) :
d_functor_impl(new MemberFunctionSlot<T>(function, obj)) {}
another form:
template<typename T>
SubscriberSlot(const FunctorReferenceBinder<T>& binder) :
d_functor_impl(new FunctorReferenceSlot<T>(binder.d_functor))
{}
|
|
|
|
|
This is showing how SubscriperSlot is templated, but you need to post the code that declares one. Even better would be the code that actually generated the errors you showed. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
I am geeting error while lanching application
"mfc90.dll is not a valid Windows image. Please check this against your installation diskette. "
What is the issue?
|
|
|
|
|
john5632 wrote: mfc90.dll is not a valid Windows image
Replace with a new DLL(mfc90.dll). The Dll that you are using might be corrupted.
|
|
|
|
|
In addition on what Mohan said, also check for viruses.
That's a very common DLL, and looks strange it is "not a windows valid image".
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Hi all,
I have a form view there I am having checkbox buttons.
Now i want to change the background color of the button.
I am using OnCtlColor() fn but it is not working.
|
|
|
|
|
Try this
CBrush m_brushBK;
In OnInitialUpdate function
m_brushBK.CreateSolidBrush(RGB(200,200,0));
In the OnCtlColor function
HBRUSH CtestDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
if(pWnd->GetDlgCtrlID()==IDC_CHECK1)
{
return m_brushBK;
}
else
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
return hbr;
}
}
|
|
|
|
|
OK thank you it is working
|
|
|
|
|
Hi all,
I have a camera service that records video to file running on windows mobile. But I will need to change it to record to buffer. It will be a service run in background.
And I may have some others application (on the same device) that need to access to this buffer and display the video in real time. I'm thinking about a RTSP server on mobile, but it will be very complex. So I just need a solution to transfer a video buffer between applications on the same device.
Can you give me any idea?
Thanks,
|
|
|
|
|
How about thorough a socket with TCP/IP or maybe UDP?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
That's why I'm thinking about RTSP server. But it's too complex. I just need something simple
|
|
|
|
|
The other application(s) that would connect to your app, are those also written by you (so you can make up any way to connect you wish) or you want to do some generic, standardized way?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
The other applications/clients could be written by me and could be write be someone else, we have some clients that will use this service. I prefer a standard way, but the speed is in priority (because these applications are for mobile phone). So I'm interested in a specific solution too.
|
|
|
|
|
Well, if you are allowed to come up with the protocol yourself then what's wrong with communicating through a socket? It shouldn't be that hard to come up with a simple, easty to implement way to connect and transfer data, of course i have no real overview of your project so i can't know.
Other methods that come to my mind are named pipes or shared memory, don't know if any of these is available on the mobile platform or not.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I'm wondering about the speed, I need that should be in real time, like when you see the mobile phone camera.
I don't know if I have to compress video before send it to socket. If I have to, so I need to compress and decompress video, the speed will be slow, I think.
If I don't compress them, so the data packet should be very big, I don't know if I can make a stream.
I see that youtube, dailymotion ... doing a stream. So I think the 2nd solution should be ok. That why in the first post I talk about a simple RTSP server.
I prefer a common buffer/shared memory like when you make a communication between threads in one application, this solution is more efficient and simple. But I don't know if we can do the same way with some independent applications.
|
|
|
|
|
Hmm, i just checked the GlobalAlloc method and found out that GMEM_SHARE is obsolete and ignored by the method (and is provided for backwards compatibility with 16 bit windows), i guess i was living in the past, as i could have sworn this would still work. Anyways, here's[^] a list of (some) interprocess communication methods, maybe one of these could be used on a mobile device too.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
