|
goldenrose9 wrote: BYTE *pByte = new BYTE[64];
You are allocating the array, then it is your responsibility to keep the bounds as 0 and 64.
|
|
|
|
|
I think you mean 0 and 63.
I must get a clever new signature for 2011.
|
|
|
|
|
yes.. of course it is!! thanks for pointing about that small but BIG mistake..
|
|
|
|
|
My pleasure; it's your turn to catch me out next time.
I must get a clever new signature for 2011.
|
|
|
|
|
yes, 0 to 63,
but i was in search of a function that returns the bound of an array,
as in vb UBound() and LBound() function is used. Is there any similer function that helps to acheive bounds in c++
Some Day I Will Prove MySelf :: GOLD
|
|
|
|
|
Nope.
Otherwise you have to go for STL container classes in C++, collection classes in MFC, or your own array class to achieve this.
|
|
|
|
|
thanx.
Some Day I Will Prove MySelf :: GOLD
|
|
|
|
|
pByte as you declared is just a pointer. You are putting the semantics of an array into it by assigning the memory for it. But the compiler has no way of knowing what, exactly this pointer is pointing to at any time.
In other words, no, the compiler cannot know what the semantics of the memory is that any pointer is pointing to, nor can any function.
That said, the above is not entirely true: when you compile your program in debug mode and check what new (and delete ) actually do, you will find that, internally, the system's memory manager indeed does store information about the memory being allocated, including the information whether this memory is for an array of objects or just one object. Therefore, if you try to release an array using delete rather than delete [] , you will get a runtime error!
If you want to, you can replace the system's operator new and delete with your own implementations. These could then store additional information, such as the number of elements being allocated, and then you could implement a function UBound() that takes advantage of that hidden information.
|
|
|
|
|
hmm, never thought of that. Rather clever!
|
|
|
|
|
Stefan63 wrote: If you want to, you can replace the system's operator new and delete with your own implementations. These could then store additional information, such as the number of elements being allocated...
Which is essentially what happens in debug mode.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Since it is C++, why not make your own little class that stores the length of the array.
class Buffer {
public:
Buffer(unsigned nSize) : m_pBuffer(NULL), m_nLength(nSize) {
if (nSize > 0) {
m_pBuffer = new BYTE[nSize];
if (m_pBuffer == NULL) {
m_nLength = 0;
}
}
}
~Buffer() {
if (m_pBuffer != NULL) {
delete []m_pBuffer;
}
}
unsigned GetLength() {
return m_nLength;
}
BYTE &operator[](unsigned nIndex) {
if (nIndex >= m_nLength) {
}
return m_pBuffer[nIndex];
}
BYTE *operator*() {
return m_pBuffer;
}
private:
BYTE *m_pBuffer;
unsigned nLength;
};
Then you can use it like
Buffer bufData(64);
strcpy(*bufData, "hello world");
printf("The valid range is 0-%u\n", bufData.GetLength() - 1);
printf("The 2nd character is \'%c\'\n", bufData[1]);
You still need to call delete pData; if the buffer was created with Buffer pData = new Buffer(64);
|
|
|
|
|
Problem is, when you write things like this yourself, you always forget something . Like declaring GetLength() const for instance, and having a const accessor.
std::vector<BYTE> is the way to go.
|
|
|
|
|
VS provides the macro
#define _countof(array) (sizeof(array)/sizeof(array[0]))
[Note: this can't be used for arrays allocated via new.]
|
|
|
|
|
goldenrose9 wrote: how to get the upper bound and lower bound of an array
BYTE *pByte = new BYTE[64];
In C/C++ there is nothing like lower bound of array is zero. Upper bound is 63 as you specified 64 (bcoz array starts with zero so 64-1).
|
|
|
|
|
I have used CString's GetBuffer() in a function like
PathCompactPath(pDC->GetSafeHdc(),strMPGFilePath.GetBuffer(),oRc.Width());
becoz PathompactPath() accepts LPTSTR as 2nd argument. So I have to Get the pointer to the Cstring object.
I have also called ReleaseBuffer() after that but application get crashed and break into the Release function of CSimpleStringT class. In my project Getbuffer has been used ( somewhere even without using releasebuffer ) and it works. I don't know why it's not working.
|
|
|
|
|
MSDN[^] says that the lpszPath parameter should have MAX_PATH of space allocated.
This should also correct the crash.
PathCompactPath(pDC->GetSafeHdc(),strMPGFilePath.GetBuffer(MAX_PATH),oRc.Width());
strMPGFilePath.ReleaseBuffer();
|
|
|
|
|
My problem has solved.
Thank you very much.
|
|
|
|
|
Hi All
I try to run dos command through mfc vc++.I know run dos command through .bat file.But my question is
Can i run dos command directly from code?
Please help me
|
|
|
|
|
Which DOS command are you looking to run from your c++ code?
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
The system()[^] command can be used to execute an operating system function.
Also read about it here[^].
You could also use CreateProcess[^] if you are wanting to execute a program
|
|
|
|
|
|
MsmVc wrote: I try to run dos command through mfc vc++.
If you just want to run a command from you application, go fot the functions mentioned in earlier reply.
If you are aiming to run a command and show its output in a window in your application, you have to go for Pipe communication.
|
|
|
|
|
C WinAPI solution (you can adopt it in mfc easily i think):
#include <windows.h>
#include <stdio.h>
char * ExecuteCMD(char * command)
{
SECURITY_ATTRIBUTES sec;
PROCESS_INFORMATION pi;
STARTUPINFO si;
HANDLE hOutR, hOutW;
DWORD BTAvail;
char * Result = NULL;
char * cmdline = NULL;
char cmdpath[256];
OSVERSIONINFO OSVersionInfo;
DWORD Read = 0;
ZeroMemory(&pi, sizeof(PROCESS_INFORMATION));
ZeroMemory(&sec, sizeof(SECURITY_ATTRIBUTES));
sec.nLength = sizeof(SECURITY_ATTRIBUTES);
sec.bInheritHandle = TRUE;
sec.lpSecurityDescriptor = NULL;
if (CreatePipe(&hOutR, &hOutW, &sec, 0))
{
ZeroMemory(&si, sizeof(STARTUPINFO));
si.cb = sizeof(STARTUPINFO);
si.hStdOutput = hOutW;
si.dwFlags = STARTF_USESTDHANDLES|STARTF_USESHOWWINDOW;
cmdline = (char *) GlobalAlloc(GMEM_FIXED, (7 + lstrlen(command)));
lstrcat(lstrcpy(cmdline, " /a /c "), command);
OSVersionInfo.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
GetVersionEx (&OSVersionInfo);
if (OSVersionInfo.dwPlatformId == VER_PLATFORM_WIN32_NT)
{
GetEnvironmentVariable("ComSpec", cmdpath, 2048);
}
if (CreateProcess(cmdpath, cmdline, &sec, &sec, TRUE, NORMAL_PRIORITY_CLASS, NULL, NULL, &si, &pi))
{
WaitForSingleObject(pi.hProcess, INFINITE);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
PeekNamedPipe (hOutR, NULL, 0, NULL, &BTAvail, NULL);
if (BTAvail > 0)
{
Result = (char *) GlobalAlloc(GMEM_FIXED, BTAvail + 1);
ReadFile(hOutR, Result, BTAvail, &Read, NULL);
Result[BTAvail] = '\0';
OemToChar(Result, Result);
return Result;
}
}
}
return NULL;
}
int main(int argc, char **argv)
{
char *cmd = ExecuteCMD("dir");
puts(cmd);
}
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
Thanks for solution
Problem solved
|
|
|
|
|
I've been thinking of adopting a new style of namespace use. Well, new to me because I've never seen it used this way anywhere else. The common thing to do in C++ is to have one class to be declared per header file. The only other things that would be declared in the header would be closely related functions and types (helper functions, friend classes, typedefs, enums, etc.). Often, the header file is named after the class.
I propose declaring each class inside it's own namespace. The namespace would be named after the class, except in all lowercase with words seperated by underscores. Classes would be named using the traditional PascalCasingScheme. Related classes and functions would go inside this namespace. Any public nested classes, typedefs, and enums would be at namespace scope instead of being declared inside the class.
For example, this is the before:
class FancyWidget
{
public:
typedef std::vector<std::string> WidgetIds;
typedef std::map<std::string, int> WidgetPrices;
enum WidgetColors
{
RED,
WHITE,
BLUE
};
class Exception : public std::exception
{
...
};
class InvalidWidgetException : public Exception
{
...
};
...
};
and this is the after:
namespace fancy_widget
{
typedef std::vector<std::string> WidgetIds;
typedef std::map<std::string, int> WidgetPrices;
enum WidgetColors
{
RED,
WHITE,
BLUE
};
class Exception : public std::exception
{
...
};
class InvalidWidgetException : public Exception
{
...
};
class FancyWidget
{
...
};
}
I tend to make things that are closely related to a class nested inside the class declaration, friend classes in particular. However, this practice always led to a convoluted class declaration. Using this style moves it out of the class declaration, but still conveys a strong association with that class through the namespace.
I can't think of any negatives to this approach, hence why I'm posting this to the forum. I don't think the extra typing whenever you needed to use anything inside "fancy_widget" would be a bother and if it did there's always the "using" keyword. Anybody see anything wrong with doing this?
This sort of thing seems to be somewhat common in Python (except they frown upon using underscores in package names). Which is why I've started thinking about carrying it over into my C++.
|
|
|
|
|