From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public From: "Robert Martin" Subject: Re: Software landmines (loops) Date: 1998/09/07 Message-ID: <6t0q1h$m5b$1@hirame.wwa.com>#1/1 X-Deja-AN: 388699756 Organization: WorldWide Access - Midwestern Internet Services - www.wwa.com X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-07T00:00:00+00:00 List-Id: Mike Spille wrote in message <35F0484A.2108A9F@tisny.com>... >Robert Martin wrote: >> >> >> int f(char* name) // returns status value >> { >> int status = 0; >> if (File* f = fopen(name, "r")) >> { >> if (char* buffer = malloc(80)) >> { >> DoSomethingUseful(f,buffer); >> free(buffer); >> } >> else // malloc failure >> { >> Log("malloc failure"); >> status = -2; >> } >> fclose(f); >> } >> else // fopen failure >> { >> Log("Failure to fopen"); >> status = -1; >> } >> return status; >> } >> >> Perhaps you think this is cumbersome. I don't. Cumbersome is a rather >> subjective term. >> > >I find it quite cumbersome, and error prone to boot. I'd do it as: > >int f(char* name) // returns status value >{ > char buf[80]; > FILE* f = fopen(name, "r"); > if (f == NULL) { > Log("Failure to fopen"); > return (-1); > } > > DoSomethingUseful(f,buf, sizeof(buf)); > fclose (f); >} > >That is, use a stack-based buffer and pass in the size of the char array to >do something useful so it doesn't walk off the end of the buffer by mistake >(assuming that DoSomethingUseful is smart enough to include a size argument). Come one Mike, I was using the program as an example. It's not a real program. If you like I'll add the requirement that the buffer *must* come from the heap because stack and heap memory run at different speeds, and the 'DoSomethingUseful' function needs the heap speed memory. (Sounds crazy but one of my clients has a platform with just such a constraint). As for passing in the size, you have a point -- but its completely irrelevant to the topic at hand. In short, you are clutching at straws. >My point? I focused on what the routine was supposed to do, not on a >methodology, And apparently not on what we were discussing. We were not discussing whether buffers should be stack or heap based. We were not discussing whether size variables should be passed along with buffers. We were discussing whether or not se/se makes a function cumbersome. I used an example to make a point, and you side stepped the point. >(And I think it's more readable :-) Which makes my point about subjectivity for me. -- Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan