|
Jeffry J. Brickley wrote:
a vector is considering the whole data-set as a single item
Very interesting. I certainly was not aware of that!
I have no need for it to be stored in one continuous block, providing I can iterate through it and (upon user actions) jump to sections of it (say 1/3rd into the list for example).
It looks like std::vector is probably not ideal for my needs.
Maybe I should be looking at std::list?
--
The Obliterator
|
|
|
|
|
Obliterator wrote:
It looks like std::vector is probably not ideal for my needs.
Maybe I should be looking at std::list?
There are pros and cons on every container, a list offers faster dynamic extention, minimal performance hit moving forwards and backwards through your data, great insertion times, but a larger hit on a search/seek/jump type operation. If your data access is random, you need constant rapid access to your data, a vector is the best container. Because it's memory is uniform and linear in structure, jumping around is VERY fast. If your data access is linear movement, forward or backward, a list makes more sense (not always, but usually). So the question is how often will the user move through the data? if you switch to a list container, you will want to make sure you remove any size() diagnostics, your performance will drop significantly using size() since it basically walks the entire list counting items.
<br />
Summary of Vector Benefits<br />
<br />
Vectors are somewhat easier to use than regular arrays. At the very least, they get around having to be resized constantly using new and delete. Furthermore, their immense flexibility - support for any datatype and support for automatic resizing when adding elements - and the other helpful included functions give them clear advantages to arrays.<br />
<br />
Another argument for using vectors are that they help avoid memory leaks--you don't have to remember to free vectors, or worry about how to handle freeing a vector in the case of an exception. This simplifies program flow and helps you write tighter code. Finally, if you use the at() function to access the vector, you get bounds checking at the cost of a slight performance penalty.<br />
<br />
List Summary<br />
The Good<br />
* Lists provide fast insertions (in amortized constant time) at the expensive of lookups<br />
* Lists support bidirectional iterators, but not random access iterators<br />
* Iterators on lists tend to handle the removal and insertion of surrounding elements well <br />
<br />
The Gotchas<br />
* Lists are slow to search, and using the size function will take O(n) time<br />
* Searching for an element in a list will require O(n) time because it lacks support for random access <br />
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
It's the reallocations that does it. Please see the vector::reserve() method. Constantly push_back() ing will yield a lot of reallocations, which is painfully slow.
Good music: In my rosary[^]
|
|
|
|
|
Thanks, I'm already using reserve() which definitely helps speed up the loading process.
But I still have to push_back() each entry in the array, unless there is an alternative?
--
The Obliterator
|
|
|
|
|
Obliterator wrote:
But I still have to push_back() each entry in the array, unless there is an alternative?
I think that you can use operator[] up to capacity() - 1 , but I'm not sure.
Good music: In my rosary[^]
|
|
|
|
|
hi, in order to "Enable3dControlsStatic();" would it be define in project setting as preprocessor definition "_AFXSTATIC" or somewhere else? Thanks!
|
|
|
|
|
MFC's AppWizard should have added the call for you automatically. Have you checked the app's InitInstance() method? It typically looks like:
#ifdef _AFXDLL
Enable3dControls();
#else
Enable3dControlsStatic();
#endif
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
|
Michael Dunn wrote:
The CTL3D functions haven't been relevant since 1995 are are of no use today.
How so? I would say the two 3D functions are relevant for all VC++ v6 applications. With MFC v5, I understand it's built in.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
CTL3D is for giving Windows 3.1 apps a 3-D look. (Only buttons look 3-D in Win3.1) All OSes from 95 on and NT 4 on have the 3-D look natively.
--Mike--
Visual C++ MVP
LINKS~! Ericahist | 1ClickPicGrabber | NEW~! CP SearchBar v3.0 | C++ Forum FAQ
Magnae clunes mihi placent, nec possum de hac re mentiri.
|
|
|
|
|
I do remember when we had to explicitly load Ctl3d.dll and Ctl3dv2.dll. It was amazing what a little 3D did to an application!
So why then does MFC's AppWizard give you the choice of 3D or not when the target platform is Win32? To my knowledge, MFC 1.0 is the only version that worked on 16-bit Windows. So it somewhat makes sense to leave the code in CWinApp::Enable3dControlsStatic() alone and let it do its check, but for VC++ v6 to still be concerned with it is what puzzles me.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
|
A very good site with code in Visual C++ about TCP/IP (icmp, finger, whoIs, scan Ports, MacAddress, ...)
www.ipmanager.com.ar
|
|
|
|
|
|
I don't think it is defined two times. Program used reference value. Check other possiblities..
Why do you want to use like this..
--> CWinApp& theApp = (* (static_cast (AfxGetApp())));
use like this..
CWinApp *pApp = AfxGetApp();
ASSERT(pApp != NULL);
" Action without vision is only passing time,
Vision without action is merely day dreaming,
But vision with action can change the world "
- Words from Nelson Mandela
Thanks & Regards,
Gopalakrishnan
|
|
|
|
|
thanks for your reply, the problem with this app is over here:
BOOL CAddSurchrgApp::InitInstance()
{
#ifdef _AFXDLL
Enable3dControls(); // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic(); // Call this when linking to MFC statically
#endif
CCommandLineInfo CmdLine;
CmdLine.setParamsUsed("C");
ParseCommandLine( CmdLine );
strcpy( m_szCycle, CmdLine.getCycle() );
if ( !CmdLine.isOkToProcess() ) //help will always make this call false so app will stop.
return FALSE;
try
{
CSurchrgDlg dlg;
m_pMainWnd = &dlg;
dlg.DoModal();
}
when it comes to CSurchrgDlg dlg;
the dlg get value {CSurchrgDlghWnd=0xccccccccc}, then it would crash at "m_pMainWnd = &dlg;" because of the access violation.....not sure when and where between those line dlg should get the proper value, thanks for your time!
|
|
|
|
|
valerie99 wrote:
when it comes to CSurchrgDlg dlg;
the dlg get value {CSurchrgDlghWnd=0xccccccccc},
We would need to see more of the CSurchrgDlg class in order to give you any helpful solution(s). What you have shown here is fine.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
The dlg info should come from CSurchrgDlg, but when I set breakpoint over CSurchrgDlg, it never stop before it hits the CSurchrgDlg dlg;...so I couldn't figure out where exactly it is from
class CAboutDlg : public CDialog
{
public:
CAboutDlg();
enum { IDD = IDD_ABOUTBOX };
protected:
virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
//}}AFX_VIRTUAL
// Implementation
protected:
DECLARE_MESSAGE_MAP()
};
CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD)
{
}
void CAboutDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
}
BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)
END_MESSAGE_MAP()
/////////////////////////////////////////////////////////////////////////////
// CSurchrgDlg dialog
CSurchrgDlg::CSurchrgDlg(CWnd* pParent /*=NULL*/)
: CDialog(CSurchrgDlg::IDD, pParent),
m_theApp (* static_cast<cwinapp*> (AfxGetApp()))
{
//{{AFX_DATA_INIT(CAddSurchrgDlg)
m_client_name = _T("");
m_reference = _T("");
m_status_message = _T("");
m_cycle = _T("");
m_percent_complete = _T("");
m_records_changed = _T("");
//}}AFX_DATA_INIT
// Note that LoadIcon does not require a subsequent DestroyIcon in Win32
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);
m_vecBuffer.reserve (BUFFER_SIZE);
}
void CSurchrgDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CAddSurchrgDlg)
DDX_Text(pDX, IDC_CLIENT, m_client_name);
DDX_Text(pDX, IDC_REFERENCE, m_reference);
DDX_Text(pDX, IDC_STATUSMESSAGE, m_status_message);
DDX_Text(pDX, IDC_CYCLE, m_cycle);
DDX_Text(pDX, IDC_PERCENT_COMPLETE, m_percent_complete);
DDX_Text(pDX, IDC_RECORDS_CHANGED, m_records_changed);
//}}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP(CSurchrgDlg, CDialog)
//{{AFX_MSG_MAP(CSurchrgDlg)
ON_WM_SYSCOMMAND()
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_BN_CLICKED(IDC_OK, OnOk)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
|
|
|
|
|
Is there anything in the OnInitDialog() method?
The only "odd" thing I see is this:
CSurchrgDlg::CSurchrgDlg(CWnd* pParent )
: CDialog(CSurchrgDlg::IDD, pParent),
m_theApp (* static_cast (AfxGetApp())) Try removing the initialization of m_theApp and see what that does.
What is m_vecBuffer ?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
thanks for you reply, I could remove the m_theApp and the app would still crash on the same spot.
the m_vecBuffer is defined like this :
std::vector<receiverec> m_vecBuffer;
in dlg.cpp const std::vector<receivebin>::size_type BUFFER_SIZE = 10000;
BOOL CSurchrgDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// Add "About..." menu item to system menu.
// IDM_ABOUTBOX must be in the system command range.
ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);
ASSERT(IDM_ABOUTBOX < 0xF000);
CMenu* pSysMenu = GetSystemMenu(FALSE);
if (pSysMenu != NULL)
{
CString strAboutMenu;
strAboutMenu.LoadString(IDS_ABOUTBOX);
if (!strAboutMenu.IsEmpty())
{
pSysMenu->AppendMenu(MF_SEPARATOR);
pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
}
}
// Set the icon for this dialog. The framework does this automatically
// when the application's main window is not a dialog
SetIcon(m_hIcon, TRUE); // Set big icon
SetIcon(m_hIcon, FALSE); // Set small icon
// TODO: Add extra initialization here
CWinApp& theApp = (* (static_cast<cwinapp*> (AfxGetApp())));
m_bCanceled = false;
m_strCycle = "";
//PostMessage( WM_COMMAND, IDC_OK );
m_pThread = AfxBeginThread((AFX_THREADPROC)Run, (LPVOID)this, THREAD_PRIORITY_NORMAL, 0);
return TRUE; // return TRUE unless you set the focus to a control
}
void CSurchrgDlg::OnSysCommand(UINT nID, LPARAM lParam)
{
if ((nID & 0xFFF0) == IDM_ABOUTBOX)
{
CAboutDlg dlgAbout;
dlgAbout.DoModal();
}
else
{
CDialog::OnSysCommand(nID, lParam);
}
}
|
|
|
|
|
valerie99 wrote:
m_pThread = AfxBeginThread((AFX_THREADPROC)Run, (LPVOID)this, THREAD_PRIORITY_NORMAL, 0);
Comment this out and see what happens.
Does the application crash when it starts or when it is exits?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
hi, David
If I comment the m_pThread out it will hang forever and with no message show on the dialog.
this app crash when it exits, but if I run another simular app, the dlg from
BOOL CXXXXXDlg::InitInstance()
{
CXXXXXDlg dlg;
would already have the value like {CXXXXXDlghWnd=0x00e90000}, but this one will have {CSurchrgDlghWnd=0xCCCCCCCC} instead, so I think it's because it didn't initialize right, looks like the dlg info is from CDialog, CWnd, but I couldn't find out where exactly it's calling CDialog and getting the info
|
|
|
|
|
valerie99 wrote:
...but this one will have {CSurchrgDlghWnd=0xCCCCCCCC} instead, so I think it's because it didn't initialize right...
With the breakpoint on the CSurchrgDlghWnd dlg; statement, CSurchrgDlghWnd.hWnd will likely have a value of 0xcccccccc. This is fine. With the breakpoint on the dlg.DoModal(); statement, CSurchrgDlghWnd.hWnd will likely have a value of 0x00000000. This is fine.
The problem at this point is that the secondary thread you are creating is still active when the application is exiting. What does this thread do? Does it communicate with the main thread or any UI component?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Thanks for following up
if I set breakpoint at dlg.DoModal();
{
CSurchrgDlg dlg;
m_pMainWnd = &dlg;
dlg.DoModal();
}
I will still have &dlg with value 0x0000000, dlg 0x0000000 and m_pMainWnd 0x0000000, that's why I keep thinking it's broken at the beginning
I will look more about the secondary thread. thanks!
-- modified at 18:31 Tuesday 20th September, 2005
|
|
|
|
|
If you don't mind me looking at your code (no proprietary or copyright issues), I would suggest packaging it up into a .zip file and e-mailing it to me and I'll take a look at it. Make sure to include the whole project so that I can just open the .dsw file, compile it, and see the problem.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|