|
I meant to declare that the function can throw the exception, doesn't this syntax indicate that this is what the function does?
I tried it anyway just in case and it doesn't compile.
Jon
|
|
|
|
|
jon_80 wrote: I meant to declare that the function can throw the exception, doesn't this syntax indicate that this is what the function does?
Yes, it does. Though, it is not really necessary (it is more for readability than anything else). That said, attaching throw () to the end of a method definition declares that it will NOT throw.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
jon_80 wrote: I meant to declare that the function can throw the exception, doesn't this syntax indicate that this is what the function does?
I've not ever seen throw() used in a class definition like that.
jon_80 wrote: I tried it anyway just in case and it doesn't compile.
My bad. I did not notice that the method already had a body.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: I've not ever seen throw() used in a class definition like that.
You probably have, you just never realized it before. Many of the MFC classes have definitions that use it, but it is hidden behind a #define macro.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: ...but it is hidden behind a #define macro.
I'm looking in afxdb.h at CRecordset::Open() but I don't see any mention of an exception. How is this done?
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I'm on a Linux box at the moment, so I can't look it up. However, I do remember CFile having a constructor that throws an exception. If you look at the header file for it, you should see something at the end of the defintion that looks like _THROW() (which is #define'd as throw(...)). There is also a #define for _NOTHROW() (which is #define'd as throw()). The first means the function will throw an exception. The latter means the function cannot throw an exception (you will actually get a compiler error if you throw an exception from a function declared with the throw() directive.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: However, I do remember CFile having a constructor that throws an exception. If you look at the header file for it, you should see something at the end of the defintion that looks like _THROW() (which is #define'd as throw(...)).
From afx.h, I found:
CFile();
CFile(int hFile);
CFile(LPCTSTR lpszFileName, UINT nOpenFlags);
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: CFile(LPCTSTR lpszFileName, UINT nOpenFlags);
That is the one that throws the exception. I thought it had the macro beside it, but it might be on the Open method. Either way, if you search the MFC include directories for _THROW, you should see it.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: That is the one that throws the exception.
True, but I see no way of knowing this without looking at the constructor's implementation.
Zac Howland wrote: I thought it had the macro beside it, but it might be on the Open method.
Neither one. I don't find "throw" in any class definition.
"Money talks. When my money starts to talk, I get a bill to shut it up." - Frank
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: True, but I see no way of knowing this without looking at the constructor's implementation.
That is in the src directory ... can't remember the filename off the top of my head, but it isn't too difficult to search for.
DavidCrow wrote: Neither one. I don't find "throw" in any class definition.
I know I've seen it in some of the MFC definitions before, but when I do a search on my VS.Net 2003, I find it in the implementation of STL:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(26): #define _THROW0() throw ()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(27): #define _THROW1(x) throw (...)
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(28): #define _THROW(x, y) throw x(y)
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(39): #define _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(40): #define _THROW1(x)
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xstddef(41): #define _THROW(x, y) x(y)._Raise()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xtree(592): _THROW(out_of_range, "invalid map/set<T> iterator");
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xtree(913): _THROW(length_error, "map/set<T> too long");
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(866): istreambuf_iterator(streambuf_type *_Sb = 0) _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(871): istreambuf_iterator(istream_type& _Istr) _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(969): ostreambuf_iterator(streambuf_type *_Sb) _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(974): ostreambuf_iterator(ostream_type& _Ostr) _THROW0()
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xutility(1003): bool failed() const _THROW0()
Among a host of others.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
jon_80 wrote: bool readFile(char strFileToRead[MAX_SENTENCE_LENGTH + 1]) throw (CSentenceAr);
Microsoft's compiler doesn't distinguish between a specificed throw and a generic one. That is, what you have is equivalent to writing:
bool readFile(char strFileToRead[MAX_SENTENCE_LENTH + 1]) throw (...);
As a side note, you should NOT use the same class you are throwing from as the exception type you are throwing. It would then be possible to end up with an infinite throw problem -- which is very very bad.
Unless you have to define your own exception class for an assignment, you should use the standard exception class, or use MFC's CException class.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: Unless you have to define your own exception class for an assignment, you should use the standard exception class, or use MFC's CException class.
Or inherits a class from that. It allows you to add more flexibility.
|
|
|
|
|
True ... forgot to mention that as well. However, you rarely need any more information than what those classes already support, and even the other STL exceptions are mostly just blank classes derived from std::exception.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Oh ic. To be honest I wish I could use MFC, but the syllabus covers basic C++ and we have to abide by it for the major part, because I'm still at the lower end of the learning curve 
MFC has its own exceptions and they resemble so much the exceptions that I'm used to with VB for example.
hehe... I think that if I decide to become a software engineer and use C++, I'll need more than silicone
Jon
|
|
|
|
|
jon_80 wrote: To be honest I wish I could use MFC
Don't be too sure about that. While MFC does have its advantages in the Windows' world, it is virtually useless outside of it. STL is far more portable.
You keep posting code that should be written with STL classes, but you only use part of STL (mainly cin/cout). Don't be afraid of string, vector, and list (along with the rest of the containers and algorithms).
Coming from a VB background will be tough. Basically, try to forget everything VB does for you, because you won't find much of that in C++ -- most of it you will have to do yourself.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
jon_80 wrote:
<code> {
throw (CSentenceAr);
return false;
}</code>
You must throw an instance of class CSentenceAr, not the class name. Change the throw statement to:
throw CSentenceAr();
You must have a working default constructor for this class.
|
|
|
|
|
Would I be throwing a new instance that way? The idea is to throw back the same instance with the invalid data.
Jon
|
|
|
|
|
Dear all,
I have dialog with two buttons(one is for automatic logon and one is for UI logon).
when the user selects the UI logon the new dialog pops up with prompting username and password ,after user enter this data he clicks ok button to enter.
But when press automatic logon ,i modified code to fill the default username and password (in username and password edit box),after this generate IDOK notification ,So that its logs automatically with out UI.
But what i need is to hide this popup dialog(which prompts for username and password ) which comes when user press the automatic logon button( i tried to hide this window by using showwindow(hwnd,SW_HIDE) in WM_INIT notification (case WM_INITIALISE: ) in dialog procedure ,but this window flashs and disappears,Is their any way to HIDE this without showing this dialog to user when he press automatic logon)
Manjunath S
GESL
Bangalore
|
|
|
|
|
It would be cleaner if you could separate the logic of window creation from the logic of user input validation. This way, when automatical logging in, you only call the validation logic, without creating the window.
I assume that you know the difference between instantiating a C++ window object and actually creating a window. If not, I'll explain more.
Best,
Jun
|
|
|
|
|
Quickes way: Setup the dialog fields in OnInitDialog() and then call OnOk or OnBnClickedOk() ...it's a quick thing but i don't like it verry much.
A better way is to process the login info in a method not depending on UI. Just pass the login fields as params to your method. In this method, display the dialog if you need to (ie: your user did not check the autologin option or something). The best thing about this is that you can call the same method in your UI validation procedure afterwards.
|
|
|
|
|
The program is executing but it's crashing at the end with the above error.
Code:
#include <iostream>
#include <string.h>
using namespace std;
char* passwordEntry(int allowedSize)
{
const int size = 100;
if (allowedSize > size)
{
cout << "Password size is too large. Size limit is " << size << endl;
allowedSize = size;
}
char password[size];
cout << "Enter your password:";
cin.getline(password,size);
if (strlen(password)>allowedSize)
{throw password;}
return password;
}
void main ()
{
const int legalPasswordSize = 8;
char password[legalPasswordSize + 1];
try
{ strcpy(password, passwordEntry(legalPasswordSize)); }
catch (const char *pswd)
{
cout << "Password is invalid" << endl;
strcpy (password, "*********");
}
cout << "Password is stored as " << password << endl;
}
Jon
|
|
|
|
|
jon_80 wrote: char* passwordEntry(int allowedSize)
{
const int size = 100;
if (allowedSize > size)
{
cout << "Password size is too large. Size limit is " << size << endl;
allowedSize = size;
}
char password[size];
cout << "Enter your password:";
cin.getline(password,size);
if (strlen(password)>allowedSize)
{throw password;}
return password;
}
You return the address of a temporary variable. The scope of password is limited to the function, so when you return it, the memory is not protected anymore.
|
|
|
|
|
I think that I am returning a copy of the variable to a char*, is this the problem?
Jon
|
|
|
|
|
You return the address of the array of char (don't forget that char* is a pointer). This array is created locally in the function (so the memory is reserved in the function). When you reach the end of the function, the array comes out of scope (because its scope is limited to the function). Thus the memory will be freed automaticaly. The contents may still be the same but they are not protected anymore (meaning that anything can override your array). And of course, the pointer that you return still point at the same location (not protected).
You have to take care of the warnings generated by your compiler. Normally, this should have appeared in the warnings ('warning: returning address of temporary variable', or something like that).
|
|
|
|
|
Yes you're right I was overlooking the warning, thanks for the explanation.
Jon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
