|
I cannot understand completely you code (maybe some <pre> TAGs probably will help),
however IMHO you may have some troubles if memory reallocation happens (and it can happen) in the global vector, beacause the pointers stored in your Line class loose sense.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
yeh i think its a memory reallocation issue. im new to this whole pointers thing, ill get it eventually!
|
|
|
|
|
Rajkumar_R wrote: First of all your approach of using STL classes for 3D drawing system is not so good.
STL is not a graphic API, but we still need to keep our data somewhere before sending it to OpenGL or DirectX.
|
|
|
|
|
Hi,
sure STL is not graphic API,
These data structure has tradeoffs for speed and also memory consumption is high.
consider accessing a item of vector; it involves more than one indirection of reference and more than one call path
vector<char> vecObj; char c = vecObj[3] is very slow compared to a simple
char Array[10]; char c = Array[3];
For 3D graphics, rendering millions of triangles in fraction of second,
the data structure that keeps the data should be fast,
When you get time try using directX, they use their own data structure's for these purpose which is usually a buffer, and also possibly they manage to keep data in hardware cache.
Best Regards
Raj
|
|
|
|
|
unfortunately time is something I dont have, this is a research project so I have to finish the program off by the end of the month at the latest so I can get onto writing a report.
fortunately I dont require millions of triangles to be rendered, only a few thousand. Its a simple 3d sketching package.
thanks for everyone's input
|
|
|
|
|
There is nothing wrong with using std::vector s. Contrary to what some people have been saying, in most cases using a vector is just as fast as using raw memory allocation functions.
Steve
|
|
|
|
|
Stephen Hewitt wrote: Contrary to what some people have been saying, in most cases using a vector is just as fast as using raw memory allocation functions.
Hey Stephen, I just stumbled upon this old thread. In general or specifically for business apps STL is more than adequate. However I do have some minor experience in Console Gaming development and for the graphics rendering I do believe the point being made about DirectX for example might be valid. Rendering, several years back when I was involved, was a huge bottleneck and some advances have been made in that area and I seem to remember reading about what Rajkumar_R is talking about in DirectX. For production graphics I would think one would certainly want to use the current approach being supported by any particular graphics platform.
led mike
|
|
|
|
|
Rajkumar_R wrote: vector<char> vecObj; char c = vecObj[3] is very slow compared to a simple
char Array[10]; char c = Array[3];
Nonsense. All of a std::vector s functions are small inline functions. Using a vector is, in most cases, just as efficient.
Steve
|
|
|
|
|
Hi Steve,
Thanks for your comments,
But I would like you to see the code in low level,
This is the dissasembly of code for vector and normal array
simple array
c = Array[2];
00411A2F mov al,byte ptr [ebp-0DAh]
00411A35 mov byte ptr [ebp-0A5h],al
vector
c = vecObj[2];
00411A1A push 2
00411A1C lea ecx,[ebp-0D0h]
00411A22 call std::vector<int,std::allocator<int> >::operator[] (4114ECh)
00411A27 mov al,byte ptr [eax]
00411A29 mov byte ptr [ebp-0A5h],al
and the call to operator [] disassembles to
reference operator[](size_type _Pos)
{
00411E40 push ebp
00411E41 mov ebp,esp
00411E43 sub esp,0CCh
00411E49 push ebx
00411E4A push esi
00411E4B push edi
00411E4C push ecx
00411E4D lea edi,[ebp-0CCh]
00411E53 mov ecx,33h
00411E58 mov eax,0CCCCCCCCh
00411E5D rep stos dword ptr es:[edi]
00411E5F pop ecx
00411E60 mov dword ptr [ebp-8],ecx
#if _HAS_ITERATOR_DEBUGGING
if (size() <= _Pos)
00411E63 mov ecx,dword ptr [this]
00411E66 call std::vector<int,std::allocator<int> >::size (41159Bh)
00411E6B cmp eax,dword ptr [_Pos]
00411E6E ja std::vector<char,std::allocator<char> >::operator[]+0A8h (411EE8h)
{
_DEBUG_ERROR("vector subscript out of range");
00411E70 mov esi,esp
00411E72 push 2F4h
00411E77 push offset string L"c:\\program files\\mic"... (41B8B0h)
00411E7C push offset string L"vector subscript out"... (41B868h)
00411E81 call dword ptr [__imp_std::_Debug_message (41F3D0h)]
00411E87 add esp,0Ch
00411E8A cmp esi,esp
00411E8C call @ILT+835(__RTC_CheckEsp) (411348h)
_SCL_SECURE_OUT_OF_RANGE;
00411E91 xor eax,eax
00411E93 jne std::vector<char,std::allocator<char> >::operator[]+80h (411EC0h)
00411E95 mov esi,esp
00411E97 push offset string L"("Standard C++ Libra"... (41B800h)
00411E9C push 0
00411E9E push 2F5h
00411EA3 push offset string L"c:\\program files\\mic"... (41B8B0h)
00411EA8 push 2
00411EAA call dword ptr [__imp___CrtDbgReportW (41F4D4h)]
00411EB0 add esp,14h
00411EB3 cmp esi,esp
00411EB5 call @ILT+835(__RTC_CheckEsp) (411348h)
00411EBA cmp eax,1
00411EBD jne std::vector<char,std::allocator<char> >::operator[]+80h (411EC0h)
00411EBF int 3
00411EC0 mov esi,esp
00411EC2 push 0
00411EC4 push 2F5h
00411EC9 push offset string L"c:\\program files\\mic"... (41B8B0h)
00411ECE push offset string L"std::vector<char,cla"... (41B778h)
00411ED3 push offset string L""out of range"" (41B750h)
00411ED8 call dword ptr [__imp___invalid_parameter (41F4D8h)]
00411EDE add esp,14h
00411EE1 cmp esi,esp
00411EE3 call @ILT+835(__RTC_CheckEsp) (411348h)
}
#endif /* _HAS_ITERATOR_DEBUGGING */
_SCL_SECURE_VALIDATE_RANGE(_Pos < size());
00411EE8 mov ecx,dword ptr [this]
00411EEB call std::vector<int,std::allocator<int> >::size (41159Bh)
00411EF0 cmp dword ptr [_Pos],eax
00411EF3 jb std::vector<char,std::allocator<char> >::operator[]+10Ch (411F4Ch)
00411EF5 xor eax,eax
00411EF7 jne std::vector<char,std::allocator<char> >::operator[]+0E4h (411F24h)
00411EF9 mov esi,esp
00411EFB push offset string L"("_Pos < size()", 0)"... (41B71Ch)
00411F00 push 0
00411F02 push 2F8h
00411F07 push offset string L"c:\\program files\\mic"... (41B8B0h)
00411F0C push 2
00411F0E call dword ptr [__imp___CrtDbgReportW (41F4D4h)]
00411F14 add esp,14h
00411F17 cmp esi,esp
00411F19 call @ILT+835(__RTC_CheckEsp) (411348h)
00411F1E cmp eax,1
00411F21 jne std::vector<char,std::allocator<char> >::operator[]+0E4h (411F24h)
00411F23 int 3
00411F24 mov esi,esp
00411F26 push 0
00411F28 push 2F8h
00411F2D push offset string L"c:\\program files\\mic"... (41B8B0h)
00411F32 push offset string L"std::vector<char,cla"... (41B778h)
00411F37 push offset string L""out of range"" (41B750h)
00411F3C call dword ptr [__imp___invalid_parameter (41F4D8h)]
00411F42 add esp,14h
00411F45 cmp esi,esp
00411F47 call @ILT+835(__RTC_CheckEsp) (411348h)
return (*(_Myfirst + _Pos));
00411F4C mov eax,dword ptr [this]
00411F4F mov eax,dword ptr [eax+8]
00411F52 add eax,dword ptr [_Pos]
}
while in release build,
c = vecObj[2];
004011EC mov ecx,dword ptr [esp+20h]
004011F0 cmp ecx,ebx
004011F2 je main+12Bh (4011FBh)
004011F4 sub eax,ecx
004011F6 cmp eax,2
004011F9 ja main+12Dh (4011FDh)
004011FB call ebp
please comment,
Thank you,
Best Regards
Raj
-- modified at 0:54 Tuesday 5th June, 2007
|
|
|
|
|
That's because you're looking at the code in a debug build (which means function inlining is disabled). I can also see you've got iterator debugging and range checking enabled. In short your comparison is flawed. Here's a disassembly for a release build (using MSVC6):
For the raw array:
16: int raw = IntRaw[0];
004010DC mov eax,dword ptr [esi]
For the vector:
20: int vec = IntVec[0];
0040113B mov eax,dword ptr [ebp]
Here's the whole program used:
#include "stdafx.h"
#include <vector>
#include <iostream>
int main(int argc, char* argv[])
{
using namespace std;
int *IntRaw = new int[10];
vector<int> IntVec(10, 0);
int raw = IntRaw[0];
cout << raw << endl;
int vec = IntVec[0];
cout << vec << endl;
return 0;
}
Steve
|
|
|
|
|
Hi,
I have posted already the release build disassembly. please check
|
|
|
|
|
As I mentioned, you've got iterator range checking enabled. See here[^] for details. Your comparison isn't fair because the raw array isn't doing any range checks. If you define _SECURE_SCL as 0 the range checking will be disabled and the code will be identical.
Steve
|
|
|
|
|
Hi,
if we disabled range checking it affects all STL containers we use .
Yes, the comparison is not fair so i said raw array and vector are different.
This is only a simply operator we have other operators/ interface that have more expensive operations.
A single additional instruction will be neglegible for application which uses it less frequently. IN 3D graphics application, point(vertex) is the building block. Millions of triangle for single 3D object will have 3*Millions of vertex. a single additional instruction will have 3*Million instruction this will reduce the performance.
I repeat I put simple example operator [], but for other interfaces we can't even set
_SECURE_SCL like definition to 0.
Yes STL is best. But I just want to ensure the above statement.
Mr. kevinbrydon may use this application for thousand of triangle today, he may use it for millions of triangle tomorrow.
Best Regards
Raj
|
|
|
|
|
Rajkumar_R wrote: if we disabled range checking it affects all STL containers we use .
That's exactly what I want to happen in a release build. In my opinion, and that of many others, checked iterators should not be enabled in release builds by default anyway. I use code like this in my precompiled header to get it to work this way:
#ifdef NDEBUG
#define _SECURE_SCL 0
#endif
I encourage you to do this and have another look at the release build's machine code. For most operations a vector 's performance will be the same as that of a raw array (as it was in the MSVC6 code I posted). All the member functions are simple inline functions.
Steve
|
|
|
|
|
I want to set 24 hr time format using Date Time Picker Control not 12 hr time format.Please give information about how to change it.
|
|
|
|
|
Hi,
use DateTime_SetFormat(win32) / CDateTimeCtrl::SetFormat(MFC)
and in the format string use HH(24hrs) instead of hh(12hrs)
eg: pCtrl->SetFormat(_T("hh-m-s")); will be pCtrl->SetFormat(_T("HH-m-s"));
Best Regards
Raj
|
|
|
|
|
Thanks,SetFormat() really work.
|
|
|
|
|
Hi everybody,
i already wrote a function which changes the view of a MDIFrame ( hide old view, show new view )
SetActiveView(New_View);
i add even a New_View->SetDlgCtrlID(AFX_IDW_PANE_FIRST);
and ::SetWindowLong(New_View->m_hWnd,GWL_ID,AFX_IDW_PANE_FIRST);
It works nearby perfect. Only if i minimize the frame.
The new view gets the OnSize-Message and the old view too ( 2 times)
So i've an effect of non-drawing on the new view.
I put a "if(isHidden) return;" in the OnSize-Handler of the old view ( isHidden is setted into the old view to TRUE during the view-changing ) it also don't resolve the problem
Big thanks for help
|
|
|
|
|
please be clear in your question...
|
|
|
|
|
I have 2 Views with the same Parent ( Frame )
One of them is active (ActiveView) and displayed ( ShowWindow(SW_SHOW) )
If i minimize the frame and restore it again, the two frames get the OnSize Message ...
Probably correct, that the two views fits all the time into the frame.
But if i restore the frame, the active view will not be drawn ...
Even an Invalidate() doesn't redraw the view
I hope you can understand my problem
|
|
|
|
|
I do a tool that need check wireless net connection;
some one said "use GetAdaptersInfo",but I do know how do that.
thank.
|
|
|
|
|
|
Hi all,
In a program I use "RemoveDirectory (LPCTSTR szName)" to remove a directory. However, this never seems to work. GetLastError () claims that "the process cannot access the file because it is being used by another process", which is not the case. I have no problem in removing the same directory from either a command-line or from the explorer. I am sure that the directory is empty (this is done in a preceeding bit of code in the same program).
Anyone any ideas?
Thanks in advance,
William
|
|
|
|
|
Wim Engberts wrote: I am sure that the directory is empty (this is done in a preceeding bit of code in the same program).
A missing FindClose(), maybe?
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
You are absolutely right! Never thought I'd need that after FindNext returned FALSE!
Thank you very much.
William
|
|
|
|
|