|
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++.
|
|
|
|
|
I don't think its an abuse, thats how namespaces have to be used.
typedef std::vector<std::string> WidgetIds;
typedef std::map<std::string, int> WidgetPrices;
Will be global variables in second approach, are you OK with that ?
|
|
|
|
|
Madhu Nair wrote: typedef std::vector<std::string> WidgetIds;
typedef std::map<std::string, int=""> WidgetPrices;
Will be global variables in second approach, are you OK with that ?
What do you mean? Those are typedef's for std::vector and std::map and would be used like so:
fancy_widget::WidgetIds foo;
fancy_widget::WidgetPrices bar;
|
|
|
|
|
Yes and no.
Yes, they are globally accessible, but that was also true in the first approach, since they've been declared public.
No they are not global, because, technically, only things declared outside a struct, class or namespace are considered global. These symbols are local to the newly defined namespace. It's about as close to global that you can get though, since - similar to true global definitions - the declaration s of the elements of a namespaces may be spread out over the codebase, so you're not guaranteed to see everything that's in a namespace when you look at a namespace declaration.
This can be considered a disadvantage, but it is also an advantage, as you can later extend a namespace for internal use without having to change a header and thus the interface of whatever you're trying to encapsulate. You might also deliberatly spread different parts of the namespace over several headers in order to minimize dependencies and thus reduce compile times.
|
|
|
|
|
Hi,
asincero wrote: I can't think of any negatives to this approach
The only drawback is that a class can be used as template argument and a namespace cannot. If not relevant in your case, the namespace approach is indeeed cleaner.
cheers,
AR
When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)
|
|
|
|
|
A related question I have regarding the use of namespaces in C++ (assuming Visual Studio) is in the past, I've found using the "ClassWizards" (or whatever they call the current feature) put any new methods outside of the namespace curly brackets requiring me to move new methods into the namepace.
Did they finally fix that and if so what version of Visual Studio are you using that places new methods correctly in their namespace?
thanks.
|
|
|
|
|