-
July 22nd, 2013, 07:43 PM
#1
typedef and struct inside class definition?
Can typedef and struct be put inside a class like below? Thanks!
Code:
class classA {
private:
typedef void(classA::*aFnPtr_t) (); //pointer-to-member function
struct strctA {
int a;
int b[100];
};
typedef struct strctA strctA_t;
typedef void (classA::*bFnPtr_t)(strctA_t*); //pointer-to-member function
...
}
-
July 22nd, 2013, 10:23 PM
#2
Re: typedef and struct inside class definition?
If you use the correct syntax, yes. Why not try writing a test program to see if it even compiles? If it doesn't, you can state what exactly you are trying to do, then ask for help in getting it to work. Otherwise, you know that it might work, so you could post what you tried to ask for a critique.
-
July 23rd, 2013, 07:23 AM
#3
Re: typedef and struct inside class definition?
additionally.
typedefs defined inside a class are "part of the class", that is to say the typedef isn't visible/accessible outside the class functions unless you fully qualify it by class::typedefname
Additionally the typedef is also public, protected or private depending so it's access is also restricted to code outside the class.
The C++ template library makes heavy use of typedefs to achieve all sorts of handy features.
-
July 23rd, 2013, 08:02 AM
#4
Re: typedef and struct inside class definition?
Thank you both! The code compiles (with g++ tool) and runs fine under Cygwin. However under MinGW (also compiled with g++ tool that came with MinGW), a few simple double variables declared immediately after the typedef would very occasionally get corrupted. That's why I asked the original question. I just tried inserting some dummy variables in between the typedef and the "real" variables and the corruption seems to have stopped. (Earlier I moved the declaration of the "real" variables to later part of the class definition after "public:" that also changed the behavior.) Not saying it's a solution, just a temporary bandaid until I find the real source of the problem. Thanks!
-
July 23rd, 2013, 02:57 PM
#5
Re: typedef and struct inside class definition?
Originally Posted by acppdummy
Thank you both! The code compiles (with g++ tool) and runs fine under Cygwin. However under MinGW (also compiled with g++ tool that came with MinGW), a few simple double variables declared immediately after the typedef would very occasionally get corrupted.
Typedefs don't exist at runtime, so they cannot be the cause of your problem.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
July 23rd, 2013, 05:04 PM
#6
Re: typedef and struct inside class definition?
Originally Posted by acppdummy
The code compiles (with g++ tool) and runs fine under Cygwin. However under MinGW (also compiled with g++ tool that came with MinGW), a few simple double variables declared immediately after the typedef would very occasionally get corrupted.
That means the program is not running "fine", regardless of whether it seems to be working.
I just tried inserting some dummy variables in between the typedef and the "real" variables and the corruption seems to have stopped. (Earlier I moved the declaration of the "real" variables to later part of the class definition after "public:" that also changed the behavior.) Not saying it's a solution,
It is no solution at all. All you're doing is playing games with the executable binary and moving the bug to another location in the program.
When you remove or add totally innocous lines of code, and this removal/addition of lines just "fixes" things, then that is a sign that your program is corrupting memory. By removing or adding lines, all you're doing is changing the location of the memory corruption. By hiding the corruption, you made the problem worse, not better. You now have an unstable program with a hidden bug.
I would suggest you put those lines of code back so that the error is duplicated, and actually fix the problem. Moving lines of code to "fix" the problem is no fix, as all you're doing is masking the real problem.
just a temporary bandaid until I find the real source of the problem
C++ memory bugs are not fixed this way. You have no choice but to fix the problem you're seeing now with those lines that duplicate the problem in the code. A C++ programmer should be happy that problems can be duplicated -- the hardest problems are ones that you know are there, but can't be duplicated. In addition, you can't update or enhance your program any further since you don't know when that new code makes that bug magically appear again.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; July 23rd, 2013 at 08:54 PM.
-
July 24th, 2013, 02:56 AM
#7
Re: typedef and struct inside class definition?
Originally Posted by acppdummy
Not saying it's a solution, just a temporary bandaid until I find the real source of the problem.
For the future, in C++ 11 the meaning of "using" has changed and seems to supersede "typedef" as the preferred way of introducing aliases.
Last edited by razzle; July 24th, 2013 at 07:08 AM.
-
July 24th, 2013, 08:04 AM
#8
Re: typedef and struct inside class definition?
I would love to find the bug if I could. The program runs many thousands of loops. The corruption only occurs very occasionally in one or a couple of the loops. It would be a lot easier if the corruption happens in every single loop. All dynamic memory allocation happens before the looping starts, and destruction after the looping ends.
By the way I have some objects that allocate int arrays using "new" in the beginning of the program. Those objects live the entire lifetime of the program. Is it necessary to put delete[] in the destructor? In other words does the dynamically allocated memory get automatically released when the program ends? Thanks!
-
July 24th, 2013, 09:16 AM
#9
Re: typedef and struct inside class definition?
Originally Posted by acppdummy
I would love to find the bug if I could.
What is stopping you from debugging the program?
The program runs many thousands of loops. The corruption only occurs very occasionally in one or a couple of the loops. It would be a lot easier if the corruption happens in every single loop.
Well, you'll have to learn how to debug memory corruption issues, since debugging these types of problems are something that every C++ programmer must learn. The number of times the loop iterates or how long the program runs doesn't matter.
1) Is it the same loop iterations that cause the problem? If so, many debuggers have "hit count" breakpoints, where you can specify how many times a line is executed before the breakpoint that is set will be hit. If not that, then do you write information to a log pertaining to the current state of the variables?
2) Since you state that it occurs within the loop, do a static code analysis of the code within the loop. Is it uses constructs that could easily go out of bounds of the allocated memory? Things such as out of bounds array accesses, unchecked return values from functions (i.e. assuming a function "works", but the function actually fails, and your code is now using bad values), illegal or improper usage of certain C++ constructs, etc.
By the way I have some objects that allocate int arrays using "new" in the beginning of the program.
In this day and age of C++, allocating dynamic arrays using "new[]" is not needed. You have std::vector<> that does this work.
Those objects live the entire lifetime of the program. Is it necessary to put delete[] in the destructor?
Yes. However, using proper container classes relieves you of having to do this.
In other words does the dynamically allocated memory get automatically released when the program ends? Thanks!
For most operating systems, the memory is deallocated at program termination. But that is no excuse for sloppy programming. Many tools report a memory leak in your application on program termination, and any memory leaks are considered bad. If the leak happens on termination, then only an experienced C++ programmer (IMO) can have any say on why it's OK for the leak to occur.
Regards,
Paul McKenzie
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|