|
You can use
#include <strstream>
const int number = 47;
std::stringstream stream;
stream << number;
std::string numberAsString = stream.str(); This way, you are using the power of the STL for you, and are avoiding literally thousands of error possibilities when fiddeling around with char-pointers and string lenghts.
The std::string would fit in nicely with the std::vector (or any oher standard container), and as a plus you can get the content as a plain old C-String by calling its c_str()-member.
Just to bring regular C++ to the mind, instead of this ugly 30+years old C code floating around here.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal. George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
Hello,
I'm having a problem with my double precision variables right now, and I'm hoping someone out there will be able to give me a hint as to what's going on. The details are going to be a little sketchy simply because of the size and complexity of the application.
I have a function that tests to see if the double precision code is behaving properly. This function looks something like this.
void TestMath()<br />
{<br />
double kappa = -2.5316332141755993e-008;<br />
double cx;<br />
cx = (double)1.0 / (double)kappa;<br />
<br />
if (cx != -39500192.000000000){<br />
BREAK("MATH IS WORKING");<br />
}<br />
}
When this function is called from the main body of my application, it never hits the break. However, if the function is called from a thread I have spawned using CreateThread(), the break does get hit.
The value for cx should be -39500192.776766039, but it's being set to -39500192.000000000
And if I add the line
double cx2 = 1.0 / -2.5316332141755993e-008;
cx2 always equals -39500192.776766039 regardless of where I'm making the call.
Using the IDE and checking the value for kappa indicates that it's value is correctly being stored.
And again, if the function is called from a spawned thread, cx is evaluated to be
-39500192.776766039
To create the thread, I'm simply calling
handle = CreateThread( NULL, 0,(LPTHREAD_START_ROUTINE)threadProcess, parameter, 0, NULL);<br />
And the function declaration for the thread looks like this.
DWORD WINAPI threadProcess(void *param)
Does anyone have any suggestions as to what could be causing this behavior?
Thanks,
Adam
|
|
|
|
|
Found it!
So, one of the details that I left out was that I am using DirectX for GPGPU math processing as well as for displaying 3d objects.
It turns out that if you create a D3DDevice without the behavior flag D3DCREATE_FPU_PRESERVE, the following happens:
Without this flag, Direct3D defaults to setting the FPU to single-precision round-to-nearest mode. Using this flag with the FPU in double-precision mode will reduce Direct3D performance.
Don't you just love how moments after you post about a problem, your thinking changes just enough to allow you to find the culprit?
Thanks for forum,
Adam
|
|
|
|
|
Nice post. Maybe it'll save someone else the trouble. Thanks for sharing it.
David
|
|
|
|
|
Hello,
when we login to email account(gmail.com) on internet browser, the browser sends data with sockets(packets), in the packet should have the email accounts password.
I am wondering that someone does know hot to retrieve the password from the packet? or somebody has any idea?
this is not hacking or anything else, this is just to better understand how sockets work.
thanks for any help
|
|
|
|
|
Gofur Halmuratov wrote: this is not hacking or anything else, this is just to better understand how sockets work.
Hmm...it has nothing to do with sockets.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Gofur Halmuratov wrote: this is not hacking or anything else, this is just to better understand how sockets work.
That's like trying to learn to read and write English by studying paper and pens.
Steve
|
|
|
|
|
it's not possible; well, nothing is impossible, but so hard you'd better do something else with your time.
the data is encrypted, with RSA.
|
|
|
|
|
I'm not sure if the thread title is really accurate, but it's the best description I can think of.
I'm in the process of creating the GUI part of a software synthesizer (VST). The synthesizer will reside in a dll. An application called the host will load the dll and run the synthesizer. I've chosen MFC for putting together the GUI elements for the synthesizer. My approach has been to test out the GUI elements in an MFC dialog based application. I've reached a point where I now I have most of the GUI work done, and I've been attempting to integrate it with the syth engine. This has meant basically copying relevant MFC files over to my synth dll project. I've made sure that I've set up the project so that it links to MFC in a shared library.
The idea is that when the host asks me for an synth editor, I pass it a class encapsulating an MFC dialog. The dialog displays all of the synth controls.
So for so good, but I've run into a problem in that I get this compile error:
Linking...
mfcs42d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in vstplugmain.obj
There's a conflict between the main function that is implemented in vstplugmain.cpp and the main function implemented some where in the bowels of the MFC library. I've been googling like crazy, but have not found a solution to resolve the conflict.
vstplugmain.cpp is the file that exports the main function. It's the function that the host interacts with when it loads the dll.
Is there something fundamentally wrong with this approach in that I won't be able to use MFC in a dll that exports its own main function?
[EDIT]
Hmm, the error goes away when I statically link to MFC.
[/EDIT]
-- modified at 16:30 Wednesday 3rd October, 2007
|
|
|
|
|
Leslie Sanford wrote: The idea is that when the host asks me for an synth editor, I pass it a class encapsulating an MFC dialog. The dialog displays all of the synth controls.
My approach would be to create an MFC enabled dll and add both the gui and the classes from the synth dll to it. I would tend to use either an MFC extension dll or an inproc COM server with MFC support, but a normal dll with MFC support should do as well.
Nathan
|
|
|
|
|
In addition to Nathan's reply...
This Link[^] has info on choosing MFC DLL types and for
each type, info on proper initialization.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: This Link[^] has info on choosing MFC DLL types and for
each type, info on proper initialization.
Thanks, Mark. That link is very informative.
Since MFC defines it's own DLLMain, I have to get rid of the one provided by the third-party library I'm using for this project. I don't like doing that because it means altering the source code, but I can live with it if it means getting things compiled.
Another problem is that host applications that use my dll pass it an HWND handle. I'm suppose to use this as a parent window and instantiate a child window. This child window provides a UI for interacting with the synth my dll represents. This UI resides within a window displayed by the host application.
However, from the link above:
If the DLL opens modeless dialogs or has a main frame window of its own, the application's main
message pump must call a routine exported by the DLL that in turn calls the
CWinApp::PreTranslateMessage member function of the DLL's application object.
I'm not sure I understand the above, but if it means that I have to require the host application to call a specified function in my dll, all bets are off. I can't make that requirement as the protocol for how hosts and dlls interact within the domain I'm working in is already set. I'm in no position to require a host to do anything.
My attempts to instantiate a CDialog derived class have failed. I've tried using CWnd::FromHandlePermanent to incapsulate the HWND handle given to me by the host application in order to pass it to the CDialog's constructor. But CWnd::FromHandlePermanent returns NULL.
So I may have bet on the wrong horse in using MFC for this project. My goal was to leverage MFC's classes in building a GUI exported from my dll. I may need to do a major rewrite.
|
|
|
|
|
Leslie Sanford wrote: I'm not sure I understand the above, but if it means that I have to require the host application to call a specified function in my dll
Yeah, that's the only way to get messages to windows in a regular DLL linked
to MFC.
If you have an initialization function that hosts are required to call, you could fire up
another UI thread and run all the DLL's windows on that.
Are your host applications always MFC or can they be straight Win32?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Are your host applications always MFC or can they be straight Win32?
They can be either. I have no way of knowing beforehand if a host is MFC based, so I have to take that into account when writing the dll.
I've managed to get CWnd::FromHandle to work in so far as I can create a CDialog based object that the host can display. But I'm getting all kinds of memory access exceptions and memory leaks. I created a test project with the simplest functionality the host requires so that I can narrow down any problems. So far I haven't been able to pinpoint where the memory problems are occurring.
Others have apparently used MFC to do what I'm attempting to do without problems, but I'm having trouble getting this to work, so I'm currently investigating rewriting my custom controls using straight Win32. It may not be quite as hard as I had thought.
|
|
|
|
|
Leslie Sanford wrote: I've managed to get CWnd::FromHandle to work in so far as I can create a CDialog based object that the host can display.
hmm I'm not clear what you're doing.
What HWND are you obtaining a CWnd for? Are you doing this in your DLL?
There's a couple important issues with this:
1) Windows messages need to get routed to the MFC message system
2) Except with an MFC extension DLL, you can't pass any MFC objects
directly or indirectly across the exe/dll boundary.
These two are the problems most likely to break this scenario, if that helps
you any
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: What HWND are you obtaining a CWnd for? Are you doing this in your DLL?
The HWND handle is given to me by the host. In response, I'm suppose to create a child window using the specified handle as the parent and display it. The user interacts with the child window making edits to the data in the dll. Something like:
void Editor::open(void *ptr)
{
HWND parent = (HWND)ptr;
myEditorDlg = new CMyEditorDlg(CMyEditorDlg::IDD, CWnd::FromHandle(parent));
myEditorDlg->ShowWindow(SW_SHOWNORMAL);
myEditorDlg->UpdateWindow();
}
open is called by the host. On windows ptr is a HWND handle.
Mark Salsbery wrote: There's a couple important issues with this:
1) Windows messages need to get routed to the MFC message system
2) Except with an MFC extension DLL, you can't pass any MFC objects
directly or indirectly across the exe/dll boundary.
This is what I gathered from the link to the webpage you posted. But someone on another group posted code supposedly doing just that (it looks close to what I posted above). When I tried it, I thought it worked at first, but a closer look and I realized I was getting all kinds of memory errors/exceptions.
|
|
|
|
|
Does CMyEditorDlg create itself in the constructor?
If not, you're missing a create call so ShowWindow and UpdateWindow
will probably assert.
Leslie Sanford wrote: But someone on another group posted code supposedly doing just that
I'm skeptical...the window may draw initially, but how is it going to get
window messages?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: I'm skeptical...the window may draw initially, but how is it going to get window messages?
That's what I get for quoting the code from memory. Here's the actual code I'm testing. It's adapted from the post I mentioned on another forum:
bool MyAudioEditor::open(void *ptr)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
ASSERT(m_pPlugView == NULL);
m_pPlugView = new CPlugView();
systemWindow = ptr;
if(m_pPlugView->Create((UINT)CPlugView::IDD, CWnd::FromHandle((HWND)systemWindow)))
{
m_pPlugView->ShowWindow(SW_SHOWNORMAL);
return true;
}
return false;
}
|
|
|
|
|
That's cool. I still don't know how the window will receive messages
after the ShowWindow() call though
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Leslie Sanford wrote: They can be either. I have no way of knowing beforehand if a host is MFC based
In that case, an extension DLL is out. That leaves a regular DLL linked
to MFC as the only option.
Passing any MFC object across the exe/dll boundary cannot be done
(it wouldn't make sense anyway, since the host may not be using MFC).
That means message routing is going to be your problem. There will
be no message pump in the DLL. The DLL will need to create its own
UI thread, since you can't count on the host to pump messages to the DLL.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I want to create a application with multiple dialogs such that clicking on the first dialog lands me to the next dialog after closing the previous one..
DoModal doesnt help....as it keeps the parent dialog box open....
Plzzzzzzz help me...
It is very urgent for me.....
mitra.tamoghna@gmail.com
Tom
|
|
|
|
|
are you looking for a Wizard type CPropertySheet ?
|
|
|
|
|
Hi all. Im trying to break a server message up into segments. So i figured i could use strtok(). Problem is the sockets i have setup are defined to STL string for C++ so i cant use strtok() obviously. So i found a tokenizer from this site. But i cant seem to use it for my socket project properly.
The message looks like this:
<br />
:user.client computer1 sysinfo :sync1 smtp.startup <br />
Instead of processing the entire server message, im trying to get the last two words after the last colon (i.e. sync1 smtp.startup)
Note: I got the tokenizer from this url: http://www.codeproject.com/cpp/stringtok.asp
Any suggestions? Thanx in advance!
|
|
|
|
|
|
Thanx for the suggestion, I would try it but i cant seem to find the download link for boost/tokenizer.hpp
EDIT:
Never mind, found it :P
|
|
|
|