Printable View
I'd like a discussion about the stuff I quoted from your post in my previous one.Quote:
We could start a new thread if anyone wants to discuss this more and enlighten me.
I don't think I could contribute much to this, though I would like to. The few things I know are just from stuff that I read, nothing I experienced myself.
If you could point me to (web-)resources on the subject, i'd really appreciate it.
Oh come on..... You have to be kidding me......Quote:
Here is a real-life example from MFC COleDateTime class. Note that it would be extremly difficult to code this without the goto.
That example is so easy to do without a goto. It doesn't take much effort at all to modify that example to do the exact same thing without the goto.
Example:
For those who say they need goto for the purpose of a clean-up section, you can easily use the above method instead of a goto.Code:static BOOL _TmFromOleDate(DATE dtSrc, struct tm& tmDest)
{
// The legal range does not actually span year 0 to 9999.
if (dtSrc > MAX_DATE || dtSrc < MIN_DATE) // about year 100 to about 9999
return FALSE;
long nDays; // Number of days since Dec. 30, 1899
long nDaysAbsolute; // Number of days since 1/1/0
long nSecsInDay; // Time in seconds since midnight
long nMinutesInDay; // Minutes in day
long n400Years; // Number of 400 year increments since 1/1/0
long n400Century; // Century within 400 year block (0,1,2 or 3)
long n4Years; // Number of 4 year increments since 1/1/0
long n4Day; // Day within 4 year block
// (0 is 1/1/yr1, 1460 is 12/31/yr4)
long n4Yr; // Year within 4 year block (0,1,2 or 3)
BOOL bLeap4 = TRUE; // TRUE if 4 year block includes leap year
double dblDate = dtSrc; // tempory serial date
// If a valid date, then this conversion should not overflow
nDays = (long)dblDate;
// Round to the second
// dblDate += ((dtSrc > 0.0) ? HALF_SECOND : -HALF_SECOND);
nDaysAbsolute = (long)dblDate + 693959L; // Add days from 1/1/0 to 12/30/1899
dblDate = fabs(dblDate);
double dblTimePart = dblDate - floor(dblDate);
double dblSecsInDay = dblTimePart * 86400.0F;
nSecsInDay = (long)(dblSecsInDay);
double deltaSecs = dblSecsInDay - (double)nSecsInDay; // milliseconds
if(deltaSecs > 0.999000F)
nSecsInDay++;
// Calculate the day of week (sun=1, mon=2...)
// -1 because 1/1/0 is Sat. +1 because we want 1-based
tmDest.tm_wday = (int)((nDaysAbsolute - 1) % 7L) + 1;
// Leap years every 4 yrs except centuries not multiples of 400.
n400Years = (long)(nDaysAbsolute / 146097L);
// Set nDaysAbsolute to day within 400-year block
nDaysAbsolute %= 146097L;
// -1 because first century has extra day
n400Century = (long)((nDaysAbsolute - 1) / 36524L);
// Non-leap century
if (n400Century != 0)
{
// Set nDaysAbsolute to day within century
nDaysAbsolute = (nDaysAbsolute - 1) % 36524L;
// +1 because 1st 4 year increment has 1460 days
n4Years = (long)((nDaysAbsolute + 1) / 1461L);
if (n4Years != 0)
n4Day = (long)((nDaysAbsolute + 1) % 1461L);
else
{
bLeap4 = FALSE;
n4Day = (long)nDaysAbsolute;
}
}
else
{
// Leap century - not special case!
n4Years = (long)(nDaysAbsolute / 1461L);
n4Day = (long)(nDaysAbsolute % 1461L);
}
if (bLeap4)
{
// -1 because first year has 366 days
n4Yr = (n4Day - 1) / 365;
if (n4Yr != 0)
n4Day = (n4Day - 1) % 365;
}
else
{
n4Yr = n4Day / 365;
n4Day %= 365;
}
// n4Day is now 0-based day of year. Save 1-based day of year, year number
tmDest.tm_yday = (int)n4Day + 1;
tmDest.tm_year = n400Years * 400 + n400Century * 100 + n4Years * 4 + n4Yr;
for(;;)//end less loop
{
// Handle leap year: before, on, and after Feb. 29.
if (n4Yr == 0 && bLeap4)
{
// Leap Year
if (n4Day == 59)
{
/* Feb. 29 */
tmDest.tm_mon = 2;
tmDest.tm_mday = 29;
break; //goto DoTime;
}
// Pretend it's not a leap year for month/day comp.
if (n4Day >= 60)
--n4Day;
}
// Make n4DaY a 1-based day of non-leap year and compute
// month/day for everything but Feb. 29.
++n4Day;
// Month number always >= n/32, so save some loop time */
for (tmDest.tm_mon = (n4Day >> 5) + 1;
n4Day > _afxMonthDays[tmDest.tm_mon]; tmDest.tm_mon++);
tmDest.tm_mday = (int)(n4Day - _afxMonthDays[tmDest.tm_mon-1]);
break;
}
//DoTime: Not needed
if (nSecsInDay == 0)
tmDest.tm_hour = tmDest.tm_min = tmDest.tm_sec = 0;
else
{
tmDest.tm_sec = (int)nSecsInDay % 60L;
nMinutesInDay = nSecsInDay / 60L;
tmDest.tm_min = (int)nMinutesInDay % 60;
tmDest.tm_hour = (int)nMinutesInDay / 60;
}
return TRUE;
}
Second Example:
Yet another execuse for goto put to rest.Code:std::string foofoo(void)
{
std::string ReturnValue;
for(;;)//end less loop
{
//Put your main function code here
//Use break to exit and get to your cleanup section
//End of your main function code
break;
}
//Do clean up here
return ReturnValue;
}
There's absolutely no need for a goto.
For every example you can post for a need for a goto, any moderate C++ expert can post a replacement method that can do the same without the goto.
Ok, that last post didn't come out right. Let me see if I can repost without the stupid smily face.
Code:std::string foofoo(void)
{
std::string ReturnValue;
for( ; ; )//end less loop
{
//Put your main function code here
//Use break to exit and get to your cleanup section
//End of your main function code
break;
}
//Do clean up here
return ReturnValue;
}
You have missed the point. Anything that can be done with a while, switch, if, for can be done with a goto. Just because a keyword is unnecessary does not mean it should leave the language.
Unless there is ONLY one person (and that person is NEVER going to change) who will ever maintain the code, I disagree.Quote:
Originally posted by galathaea
I was not using the goto as a generic then block, but I have little qualms over its use in this way. The main problem would be pollution of label name space, but even that is little concern these days if you have a good naming convention. ...
I would think you would strongly encourge your programmers to agree on a standard, and whatever they did agree on, I would guess it wouldn't be what you posted in your example.
Regards,
John Flegert
As an addition, look in this forum. There is currently a topic asking for comments about if, then, else. I don't see anyone suggesting using goto.
I am trying to show that all of the fears of goto are fears of bad design principles. If you agree on a particular set of design principles, then you can use any keywords you feel comfortable with and not confuse any future development. I still don't feel that any of the comments against the use of goto have had anything to do with the problems goto may present to a development cycle. They have all seemed to me to be bad design principles in general. It is my position that the ONLY thing that a development group should have to agree on is their design principles. This is the classic linguistic argument against word-related syntax being the focus of a linguistic debate and the argument for a complete grammar related debate on form.
Again, goto has nothing to do with design. Absolutely nothing. It is an implementation detail and a maintenance nightmare, but in no way is it a design issue.Quote:
I am trying to show that all of the fears of goto are fears of bad design principles.
History has shown goto to be bad. If you so happen to think we're smarter now than in the past, go ahead and use it. Please, use it. It may very well be the only way to prove us right.
There is no implementation reason not to use it. It directly causes no runtime problems. All the problems it causes are maintenance related. You ask for implementation reasons not to use it. Well, there are none. That does not mean it should be used.
Jeff
But all of the reasons against using goto seem to be based on the use of bad design. What I have been saying is that the implementation of a branching structure is never a problem if one is following good design principles. I do understand the difference between design and implementation. It is precisely the linguistic differentiation that I have been making! If you are using a good set of design principles, I have been arguing that the implementation is immaterial to "goodness" or "badness" of maintainability. This was the reason for the shift of computer language theory from keyword-based syntax of the 50s and 60s to a form-based analysis of grammars in the Object Oriented generation.Quote:
Again, goto has nothing to do with design. Absolutely nothing. It is an implementation detail and a maintenance nightmare, but in no way is it a design issue.
Implementation is crucial to maintainability. Software changes. Not matter how well it's designed, there is always a bit of evolution involved. It grows and changes. Bugs are fixed, features are added. That method you wrote 10 years ago, the one with the goto in it, may have gone through many modifications. Software is not something you write well once and leave sit. That's a nice thought, but it doesn't work that way. If it was so, then the use of goto would hardly be an issue. But it's is not so, and it is an issue.Quote:
the implementation is immaterial to "goodness" or "badness" of maintainability.
Jeff
Are there any problems with maintainability of a goto statement when the code is updated in a manner that follows good design principles? The design principles that I think are most relevant are:
- Variables (in any language) should be declared/initialized at the start of the code block in which they are used (a "Declared Use" idiom).
- Code blocks (in any language) should be as atomic as possible (an "Encapsulation" idiom).
- A naming convention for all identifier types should be agreed upon by the developers before production (a "Namespace Maintenance" idiom).
- The execution flow of a code block should follow in its reading the originally designed flow for the functionality desired (a "Flow Maintenance" idiom).
The point is that I do understand that the implementation will change as development progresses over the products lifetime. But, as long as design principles are followed, the implementation should never affect maintainability. This was the reason for the switch in linguistic research to form in the first place, ie. to provide for keyword independent rules that allow the creation of useable and maintainable code. If goto is an exception, then it is important to find out why because this would invalidate the current state of this line of research.
I am glad this thread is pursuing these issues, because it is very important to the entire field of general design principles, and I hope there will be more posting from all of those who have an interest in expanding this field.
So I will repeat my question. Are there any problems with maintainability of a goto statement when the code is updated in a manner that follows good design principles?
galathaea,
You mentioned 4 design principles above.
Let's look at your "if (...) goto here; ... here:" vs
the standard "if(...){}" syntax.
using if (...) goto here; ... here:"
- you can not even declare std::vector to be used inside the block.
- you can not do a "int i=0" , inside a block
- you can do the following inside of the block:
but the i remains in scope after the block.Code:int i;
i=0;
doesn't the above violate the first 2 rules you gave ?
This is why you should either declare the variable at the head of the block, or create a new block inside. This was the point of my switch example earlier. The design principles are not followed, and goto had nothing to do with these problems. I am wondering if, by FOLLOWING the design principles, one can do anything mischeivous with goto.
So if you declare a new block inside, what
exactly is the point of the goto and the label ?
Removing what is in bold above leaves the standard "if() {}".Code:if (...) goto here;
{
...
}
here:
Then later you need to add an "else" block - it really starts
to get to be a mess. Sorry, but this use of goto of your is
definitely bad.
(You'll notice I am saying this particular use of goto is
bad, not all uses. But it is uses like this that have
caused people to want to never use them.)
That's a big 'if'. That's not something that is easily guaranteed, no matter how many code reviews you do. I would guess that most products don't and won't follow these principles.Quote:
am wondering if, by FOLLOWING the design principles, one can do anything mischeivous with goto.
Theoretically, you may have a point. In practice, I believe the use of goto will degrade the maintainability of a product because when not following the principles you mentioned, goto will be a more serious problem than other flow of control structures.
Jeff