|
Or before you delete the file write garbage in it...
Rozis
|
|
|
|
|
That works as long as he erases the files he wants to delete (using his application.) If the program wants to erase all the deleted files and folders (they might be deleted by other programs) it still needs a way to get rid of all the traces of those files on the disk.
|
|
|
|
|
Hi
After debuging a MFC Application ,then closing it produce the following
message in the output window .
Dbug
Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information found.
"
"
"
Loaded 'C:\WINDOWS\system32\gdi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\comctl32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\advapi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\rpcrt4.dll', no matching symbolic information found.
What does it mean? Thanks in advance 
|
|
|
|
|
|
It simply shows u log that which of the dlls it used for running ur MFC application.
|
|
|
|
|
can we make class cant be derived at all? if yes how to make it. please let meknow?
Nice talking to you.  If you judge people, you have no time to love them. -- Mother Teresa
|
|
|
|
|
class foo sealed
{
};
use the 'sealed' keyword.
|
|
|
|
|
theCPkid wrote: use the 'sealed' keyword.
The ISO standard C++ has no such keyword.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
okay.. Thanks for the information.
Visual studio compiler supports this keyword [^] and above all,if a person happens to use VS, "it works" without "any additional implications".
Making the c'tor private will certainly stop the class from being inherited but it will also force the person to provide 'other' way of creating the class object.
I think OP wanted to stop inheriting not instantiation. And my suggestion only helped him do what he wanted - nothing more, nothing less. 
|
|
|
|
|
theCPkid wrote: Visual studio compiler supports this keyword [^] and above all,if a person happens to use VS, "it works" without "any additional implications".
That's plainly wrong. If you scroll down to the bottom of the page you linked to, you will see this:
Requirements (Read as "Additional implications"):
Compiler option: /clr
Which means that it is not a C++ program! It is a C++/CLI program, that targets the .NET framework.
theCPkid wrote: Making the c'tor private will certainly stop the class from being inherited but it will also force the person to provide 'other' way of creating the class object.
Of course yes. But so what? That's the only way as far as C++ (the real C++) is concerned.
theCPkid wrote: I think OP wanted to stop inheriting not instantiation. And my suggestion only helped him do what he wanted - nothing more, nothing less.
Your suggestion was just wrong here. It is a correct answer if the query was posted on a managed c++ forum.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: Which means that it is not a C++ program! It is a C++/CLI program, that targets the .NET framework.
Now certainly, it's david vs big-fat-goliath(that's you) given my insufficient knowledge about managed or unmanaged code but man, if you do not scroll to the end of page, you will see this line
"sealed is also valid when compiling for native targets (without /clr)"
I have nothing more to say on this and whatever you say after that is correct but can you confirm this by using 'sealed' keyword in native unmanaged application on your system. I feel it's working on my PC.
|
|
|
|
|
theCPkid wrote: Now certainly, it's david vs big-fat-goliath(that's you) given my insufficient knowledge about managed or unmanaged code
Certainly no! I'm not trying to talk you down or something like that. I'm merely stating the facts that I can pull off my head. My idea of visiting the forums and discussing with people is to teach them some, and learn some from them back.
theCPkid wrote: "sealed is also valid when compiling for native targets (without /clr)"
Probably MS has done something with *their* compiler to support this feature (read as added feature specific to their compiler, or an extension, because of which you won't be able to have the same code successfully compiled with another c++ compiler). It doesn't work just right on my machine (you're probably using some latest version of VS and that compiler support for understanding this keyword).
I only have 2003 installed here on this PC and it doesn't just work right. I will be able to derive classes from a class that has been declared 'sealed'.
theCPkid wrote: I feel it's working on my PC.
Now, what does that mean? Something like:
class c1 sealed{}; class c2:public c1{}; gives a compiler error? If yes, then I'm almost certain that it becomes Microsoft C++ compiler (insert version) specific. Because it doesn't even work right with the previous versions! Not to mention sealed is NOT a C++ keyword.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
class A sealed
{
};
class B: public A
{
};
error C3246: 'B' : cannot inherit from 'A' as it has been declared as 'sealed'
I use VS 2008.
Rajesh R Subramanian wrote: I only have 2003 installed here on this PC and it doesn't just work right. I will be able to derive classes from a class that has been declared 'sealed'.
Do you mean your compiler recognizes sealed keyword, allows compilation etc and still do not stop you from inheriting? hmmm.. may be you should tweak around a bit to find out how 'sealed' is being interpreted by your VS compiler.
In the msdn link I mentioned before, it is written sealed is valid even if /clr is not mentioned.
So, my suggestion is not entirely wrong. It works in at least one case. 
|
|
|
|
|
I do a rebuild all and it barfed all over. It doesn't even seem to know what does 'sealed' mean. Won't even compile. Which would be the case with every other c++ compiler.
(the previous build had ignored the changes I made to the code - happens every now and then).
theCPkid wrote: So, my suggestion is not entirely wrong. It works in at least one case. Laugh
Right.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Rajesh R Subramanian wrote: It doesn't even seem to know what does 'sealed' mean.
I just tried this with VC++ Express and it compiled just as theCPkid states, even though the MSDN document states that you need the /clr option - which I certainly did not use. Is this a bug or a new feature I wonder 
|
|
|
|
|
No it isn't a bug. It is some sort of an extension to their compiler.
Even though there is nothing called "sealed" in the c++ language, Microsoft seem to have added the ability to their native c++ compiler to understand and support this keyword (the idea must have come from .NET). It looks like only VS 2005 or above will support this keyword.
This cannot even be said to be "Microsoft Specific" (note that the documentation avoids using this term too), because it is restrictive to some versions of their compilers. Unfortunately if you would like to write portable code, using it is a very bad idea, because any other standard c++ compiler won't even know what sealed means. You will have to rewrite your code such that your class is not inheritable (and that will require you to change the whole class code, and the code that is using the class).
And if you want to write a class that is not inheritable, and if you use this feature, then the code is NOT c++. Because it won't even compile in any standards conformant c++ compiler.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
class CSealed
{
CSealed(){}
CSealed(const CSealed& ref){}
};
class some:public CSealed
{
};
int _tmain(int argc, _TCHAR* argv[])
{
some s;
return 0;
}
This won't compile: C2248!
Of course I assume that you know the other 'quirks' associated with keeping a class constructor as private. Let me know if you need more information.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Hi ,
Here is what Stroutstroup had suggested on the same thing you want to achieve:
Can I stop people deriving from my class?
Bjarne Stroustrup :Yes, but why do you want to? There are two common answers:
* for efficiency: to avoid my function calls being virtual
* for safety: to ensure that my class is not used as a base class (for example, to be sure that I can copy objects without fear of slicing)
In my experience, the efficiency reason is usually misplaced fear. In C++, virtual function calls are so fast that their real-world use for a class designed with virtual functions does not to produce measurable run-time overheads compared to alternative solutions using ordinary function calls. Note that the virtual function call mechanism is typically used only when calling through a pointer or a reference. When calling a function directly for a named object, the virtual function class overhead is easily optimized away.
If there is a genuine need for "capping" a class hierarchy to avoid virtual function calls, one might ask why those functions are virtual in the first place. I have seen examples where performance-critical functions had been made virtual for no good reason, just because "that's the way we usually do it".
The other variant of this problem, how to prevent derivation for logical reasons, has a solution. Unfortunately, that solution is not pretty. It relies on the fact that the most derived class in a hierarchy must construct a virtual base. For example:
class Usable;
class Usable_lock {
friend class Usable;
private:
Usable_lock() {}
Usable_lock(const Usable_lock&) {}
};
class Usable : public virtual Usable_lock {
// ...
public:
Usable();
Usable(char*);
// ...
};
Usable a;
class DD : public Usable { };
DD dd; // error: DD::DD() cannot access
// Usable_lock::Usable_lock(): private member
I thinks This solves your problem , If yes rate the answer as Good and close the thread.
Regards,
Kushagra
I hate to code but I luv to Develop
|
|
|
|
|
G Haranadh wrote: can we make class cant be derived at all? if yes how to make it. please let meknow?
Actually there is an article on CodeProject which can help you. -> Sealing Classes in C++[^]
Personally I like this[^] handy macro, which is generalized version of Stroustrop's solution [^].
Regards,
Nuri Ismail
modified on Saturday, October 24, 2009 12:12 PM
|
|
|
|
|
Hi all , i want to add the FilePath+FileName to the Scanner Driver so that the User App will Print :
Current File Name :MyCurrentFile.txt * for example *
you can download ( scanner *Driver +User App *) from here :http://www.box.net/shared/zm2d7cuyrm[^]
I tried with scanuk.h as follows :
typedef struct _SCANNER_NOTIFICATION {
ULONG BytesToScan;
ULONG Reserved;
UCHAR Contents[SCANNER_READ_BUFFER_SIZE];
PWSTR FileName;
} SCANNER_NOTIFICATION, *PSCANNER_NOTIFICATION;
many thanks
|
|
|
|
|
you provide a link for source code for scanner driver & applications well so nw give me workable link for that i need it so much ....please help me to get it otherwise i will b in trouble ..pls pls frnd..pls contact me on my email if u can bcoz i m nt using this forum to communicate.
|
|
|
|
|
I am attempting to write an application in VC 2008 under Vista 64. In the application, I create a Class and a pointer; the pointer is cast (void) and held in a map.
<CMap<int, int, void*, void*> myMap
m_pClassXYZ = new ClassXYZ;
m_pClassXYZ->Create(NULL, NULL, WS_CHILD, CRect(0, 0, 0, 0), this, nClsID, NULL);
p_vPtr = (void*)m_pClassXYZ;
//Note: Map holds pointers to multiple classes of different types and hence is cast void.
pmyMap->SetAt(n, p_vPtr);
When I want to use the pointer, it is cast back:
m_pClassXYZ = (ClassXYZ*)p_vPtr;
This seems to compile, link and execute without incident. On exit the application I want to destroy the Class(es) and free the memory:
m_pClassXYZ->DestroyWindow();
delete m_pClassXYZ;
The appropriate DLL's are part of the project and allow memory leak checking. I get the following in the Output pane when the application exits:
c:\..................\MyApp.cpp(164) : {192} client block at 0x00098F60, subtype c0,
88 bytes long. a ClassXYZ object at $00098F60, 88 bytes long
When I click on the leak statement, it takes me to the line with the "new" operator.
I understand the leak statement, just not why. I think that this worked in previous versions of Visual Studio.
Am I not destroying the class and freeing memory properly? If not, can someone please give me an idea of what I am doing wrong?
Thanks,
Barry
|
|
|
|
|
This how I would do the allocation into CMap.
CMap<int, int, void*, void*> myMap;
m_pClassXYZ = new ClassXYZ;
m_pClassXYZ->Create(NULL, NULL, WS_CHILD, CRect(0, 0, 0, 0), this, nClsID, NULL);
p_vPtr = (void*)m_pClassXYZ;
myMap.SetAt(n, p_vPtr);
The deallocation would be done as follows -
int nKey;
void* pValue;
POSITION pos = myMap.GetStartPosition();
while (pos)
{
myMap.GetNextAssoc(&pos, &nKey, &pValue);
myMap.RemoveKey(nKey);
m_pClassXYZ = (ClassXYZ*)pValue;
delete m_pClassXYZ;
}
|
|
|
|
|
Superman, you came to the rescue. Your reply cleared out all of those pesky client blocks. Thanks. I do have some normal blocks left, but I will start another thread to address them.
Barry
BTW - I too love work; I can lie down next to it all day long. 
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
