- best way to pass a multiple dimension variable to a method - 3 Updates
- Overuse of 'auto' - 15 Updates
- Sum an array in a lambda. - 2 Updates
| Lynn McGuire <lynnmcguire5@gmail.com>: Dec 21 02:37PM -0600 What is the best way to pass a multiple dimension variable to a method in C++ ? For instance, in C you could do the following: double xyz [5] [2] [14]; ... amethod (xyz, ...); Thanks, Lynn |
| Richard Damon <Richard@Damon-Family.org>: Dec 21 05:10PM -0500 On 12/21/22 3:37 PM, Lynn McGuire wrote: > amethod (xyz, ...); > Thanks, > Lynn You can do the same thing in C++ with a primative array, or you can define a container that acts like a multidimensional object, or you can use something like a vector of vectors (or array object of array objects) |
| Lynn McGuire <lynnmcguire5@gmail.com>: Dec 21 04:18PM -0600 On 12/21/2022 2:37 PM, Lynn McGuire wrote: > amethod (xyz, ...); > Thanks, > Lynn I am looking at https://www.educba.com/3d-arrays-in-c-plus-plus/ and https://stackoverflow.com/questions/8767166/passing-a-2d-array-to-a-c-function Thanks, Lynn |
| David Brown <david.brown@hesbynett.no>: Dec 21 01:42PM +0100 On 21/12/2022 12:14, Juha Nieminen wrote: > to make! > So many controversial code style guidelines out there. How dare they! > They must be taken down! I guess I was right. And I guess Keith is right that progress in this thread appears impossible. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 21 02:56PM > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> This thread is getting a bit _hot_. > In all honesty I cannot really understand why. I think it started quite hot! The subject, "Overuse of 'auto'", hints at polemic. Maybe you intended to explain what you consider to be "overuse", but I couldn't find that in the OP. Without some attempt to differentiate between reasonable use and excessive use, the post sets up conflict form the very start: "Ever used auto? I bet you were wrong to do so!" it seems to say. (Note "seems" -- I know that's not what you said, but it's how it reads without more detail than you gave). You then give an example that certainly got my back up: auto foobar = someFunction(a, b); This is obviously impenetrable, but I'd say that's because of every single word /other/ than the auto -- it's possible that the auto is the /only/ sensible part of such a line! If it were auto parser = parse::sequence(parse_function_expression, parse_arguments); then the auto is (to my mind) a justifiable choice. Equally (and I am trying to fair here) there are choices for foobar, someFunction, a and b for which the auto does indeed hide information that would otherwise help the reader. (Note that I am speculating on the existence of a combinator parsing library in C++. The fact that the reader may no know how this sort of thing works can't be used to argue that the code is unreadable. It's simply not possible to write code that can be understood by people who don't know the techniques being used. Comments will help, but only up to a point.) > Nothing of what I have written is in any way controversial or worthy > of heavy opposition. That stance was clear from the start, but that's not going to promote discussion. It became clear, quite quickly, that some of what you were saying was, at least mildly, controversial. At that point, a change in tone to "Oh, that surprises me -- can you explain why you think knowing the type is sometimes unhelpful?" would have led, I feel, to a more productive debate. > commonly agreed eg. in coding style guidelines (at least the part > of avoiding excessive use of acronyms and using full words instead > which, ironically, seems to be the biggest source of contention here.) There you go again! Avoiding excessive use of anything is obviously wrong so the real question -- the only interesting question -- is what, if any, uses would not count as excessive, and what, if any, uses might actually help? > There's nothing controversial or horrendous about it, so why all this? > I honestly cannot understand. I hope I have given you some ideas about that. -- Ben. |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 03:31PM >I think it's rather telling that what I am saying can be quite easily >found in many coding style guidelines out there, including those used >by big companies. Appeals to authority are a logical fallacy. https://en.wikipedia.org/wiki/Argument_from_authority >You'd have very hard time finding a single coding >style guideline that's saying what you are saying there, that says >that abbreviations and acronyms are preferred over full words. David never said that. And I suggest that the vast majority of programmers have never worked for Microsoft, and thus have never been subject to such "coding style guidelines". David's points are valid. Understandable code doesn't rely on slavish devotion to some written recommendations. |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 03:38PM >because it's not telling *what* it's indexing, just that it's an index >variable... but even that is better than just 'i'. Perhaps not orders >of magnitude better, but still better. So, how about this? unsigned char *bp = (unsigned char *)d_mp->get_ioaddr(bufaddr); ulong remaining = bufsize; unsigned char *ap; ... ap = u_write_buffer = (unsigned char *)malloc(bufsize); if (ap == NULL) { unlock(); d_logger->log("%s Unable to allocate %lu bytes: %s\n", u_dlp_name, bufsize, strerror(errno)); set_rd(iocb, IOT_WITH_EXCEPTIONS, RD_NOT_READY); return false; } for (;remaining > 0; bp++) { if (iocb->ascii_xlate()) { *ap++ = c_ebcdic::to_ascii(*bp); } else { *ap++ = *bp; } remaining--; if (is_control(*bp)) break; } Readable? Unreadable? Anyone working on the code would know implicitly that "rd" is an abbreviation for Result Descriptor; anyone who doesn't know that shouldn't be mucking about in the code in the first place. Context is important. |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 03:40PM >>except for one abbreviation: creat(). >Yes, that is a bit of an odd one. Perhaps they thought that "create" would be >a name people would want to use a lot for their own function names. IIRC, "creat" actually came from the assembler version of the system call name. |
| Muttley@dastardlyhq.com: Dec 21 03:58PM On Wed, 21 Dec 2022 15:40:17 GMT >>Yes, that is a bit of an odd one. Perhaps they thought that "create" would be >>a name people would want to use a lot for their own function names. >IIRC, "creat" actually came from the assembler version of the system call name. Still begs the question of why they left off the 'e'. Probably lost in the mists of time. |
| Richard Damon <Richard@Damon-Family.org>: Dec 21 11:12AM -0500 >> IIRC, "creat" actually came from the assembler version of the system call name. > Still begs the question of why they left off the 'e'. Probably lost in the > mists of time. I seem to have vague memories of some legacy system with 5 character external name limit. This could just be a name chosen to match what was used before. |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 04:23PM >>IIRC, "creat" actually came from the assembler version of the system call name. >Still begs the question of why they left off the 'e'. Probably lost in the >mists of time. https://en.wikiquote.org/wiki/Ken_Thompson Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e." https://unix.stackexchange.com/questions/10893/what-did-ken-thompson-mean-when-he-said-id-spell-creat-with-an-e It appears to have been an attempt to save space in source files at a time when disk space was scarce. |
| Muttley@dastardlyhq.com: Dec 21 04:58PM On Wed, 21 Dec 2022 16:23:22 GMT >he-said-id-spell-creat-with-an-e >It appears to have been an attempt to save space in source files at a time when >disk space was scarce. Hmm. That doesn't seem credible even back then. How many times would it be used in any given program? Couldnt have saved more than a few bytes at most. You could achieve far more savings making user functions and variable names shorter. |
| Richard Damon <Richard@Damon-Family.org>: Dec 21 12:02PM -0500 > used in any given program? Couldnt have saved more than a few bytes at most. > You could achieve far more savings making user functions and variable names > shorter. My memory was that it allowd the storing of a symbol table with entries of 5 6-bit characters in a 32 bit word, with 2 status bits. Making that field larger WOULD significantly increase the size of the symbol tables. |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 05:16PM >I seem to have vague memories of some legacy system with 5 character >external name limit. This could just be a name chosen to match what was >used before. I've seen folks refer to the 6 character unix linker limit, but the limit was 8 characters in the v6 compiler. Later compilers would prefix external symbols with an underscore, but that was long after creat was added to unix. Best I can tell, dropping the second 'e' from creat was simply to make it easier to type on a teletype. |
| scott@slp53.sl.home (Scott Lurndal): Dec 21 05:18PM >My memory was that it allowd the storing of a symbol table with entries >of 5 6-bit characters in a 32 bit word, with 2 status bits. Making that >field larger WOULD significantly increase the size of the symbol tables. But v6 C supporte 8 character identifiers using 7-bit ASCII, so I don't think that's the case. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 21 05:22PM > I seem to have vague memories of some legacy system with 5 character > external name limit. This could just be a name chosen to match what > was used before. My recollection was of a limit of 6 characters, but external names had an _ added to the front of them making the limit effectively 5. However, that does not explain the missing e, since all systems I can recall allowed longer names -- they just ignored the extras. The limit explains short prefixes like the "f" for the file operations because file_open and file_close would both appear as _file_ to the linker, but it does not directly explain the missing e in creat. -- Ben. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 21 10:24AM -0800 > Muttley@dastardlyhq.com writes: >>On Tue, 20 Dec 2022 20:29:02 +0200 >>Paavo Helde <eesnimi@osa.pri.ee> wrote: [...] >>Yes, that is a bit of an odd one. Perhaps they thought that "create" would be >>a name people would want to use a lot for their own function names. > IIRC, "creat" actually came from the assembler version of the system call name. That doesn't really explain anything. The system call could still have been called "create", whether it was in assembler or C. (I've seen speculation that the linker imposed a 6-character limit on external identifiers, and "creat" was transformed to "_creat", but that doesn't seem plausible given that there are other system calls with 6-character names.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Dec 21 08:31PM On Wed, 21 Dec 2022 11:14:15 +0000, Juha Nieminen wrote: > to make! > So many controversial code style guidelines out there. How dare they! > They must be taken down! Use of language in code should reflect the nouns (objects) and verbs (operations). If using CamelCase abbreviations and acronyms are fine as long as you do NOT capitalise them: the Foo and Bar in FooBar should be separate nouns/verbs, e.g. GprsConnectionManager and not GPRSConnectionManager. /Flibble |
| Joseph Hesse <joeh@gmail.com>: Dec 21 10:56AM -0600 On 12/20/22 11:29, Öö Tiib wrote: > auto fp = [] (int *x) > ... so array length information is lost and range > based for has no idea what range you mean. In the following program, the array definition and range based for loop are in the same scope so it appears that the range based for loop sees the size of the array. The following program compiles with the gnu compiler and runs correctly. I am surprised that it works. ========================================= #include <iostream> #include <vector> using namespace std; int main(){ int x[4] = {1, 2, 3, 4}; int sum = 0; for(const int &i : x) sum += i; cout << "sum = " << sum << '\n'; return 0; } |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Dec 21 10:32AM -0800 > cout << "sum = " << sum << '\n'; > return 0; > } Why are you surprised? In `auto fp = [] (int x[])`, x is an array parameter, which is treated as a pointer parameter. That equivalence applies only to function parameters. In your example, you just have an array object. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment