- Auto-incrementing or auto-decrementing values at compile-time - 7 Updates
- [Jesus Loves You] Bible boring to you? Try this... - 2 Updates
- special string-implementation - 3 Updates
- Why do some people hate namespace prefixes? - 4 Updates
- Doxygen-generated docs of the macros I sometimes use (plus more, but I just started documenting) - 1 Update
| leigh.v.johnston@googlemail.com: Apr 19 01:40AM -0700 On Thursday, April 18, 2019 at 10:37:19 PM UTC+1, jacobnavia wrote: > Before coding (and also before posting rubbish) he should TURN HIS BRAIN > ON... > But apparently he can't. I agree Jacob, the vaguely on topic but useless posts are obviously an attempted ruse by Hodgin to cover-up and/or legitimise his off topic religious spam. He thinks if he posts a mixture of technical (but shite) and non-technical (but shite) posts he can claim he isn't purely a god bothering spammer. He probably also hopes for opportunity to engage people in god bothering in pseudo-technical threads that he starts. Some words that perfectly summarise Hodgin and his behaviour: EGREGIOUS, TRANSPARENT, IRRITATING. /Leigh |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 19 05:47AM -0700 > I agree Jacob, the vaguely on topic but useless posts are obviously an > attempted ruse by Hodgin to cover-up and/or legitimise his off topic > religious spam... Both of you will learn soon enough the significance of the messages I post. One type of message I post is far more important than the other to both of you, and the posts I write on the C/C++ language and its related fields are the lesser important type by a very wide margin. -- Rick C. Hodgin |
| Richard Damon <Richard@Damon-Family.org>: Apr 19 09:13AM -0400 On 4/18/19 3:51 PM, Rick C. Hodgin wrote: > I can see doing this in an external tool, but is there some way to do > it in C/C++? > And if not, does anyone have any idea for a good syntax on how to do it? This is NOT an operation that seems valid for a compiler, as the compiler should NEVER go back and change the source code. It might make sense for a developement platform (like an IDE). Personally, it defies the rule against magic numbers, so what I would do is have something like an enum in the header defining the interface to the function, defining the return values for the error codes, and when I need to add a new error code, I add an entry to the enum and return that entry. This says that calling code has names for the various error codes, rather than having to be littered with all the magic numbers. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 19 09:25AM -0400 On 4/19/2019 9:13 AM, Richard Damon wrote: > This is NOT an operation that seems valid for a compiler, as the > compiler should NEVER go back and change the source code. I've had that thought, but I've also had the thought that the tools we use should be accommodating to the needs of some required syntax and operations at times. We shouldn't have to diversify very far for some features that are oft-used. I use that pattern in pretty much every function I write that is visible outwardly through an API. And it becomes tedious to have to manually set the values. Being as I code that way pretty much every day, it seems that it would be of benefit. > It might make sense for a developement platform (like an IDE). I can see that applying to specific things, like in Windows we have to make sure return handles are not set to the INVALID_HANDLE_VALUE constant, but that same constant isn't valid on other OSes... so there would be value there for having platform-dependent features added to the development platform. But for cases that transcend OS barriers, I think it would be more desirable to have a language-level solution. > need to add a new error code, I add an entry to the enum and return that > entry. This says that calling code has names for the various error > codes, rather than having to be littered with all the magic numbers. I am unaware of the rule of magic numbers. I think the ability to receive source code, and have it have a user- specified (in source code) request to assign something mechanically rather than manually, and then re-write the altered source code back out, is a desirable feature that the language should possess, especially when the language is recognizing that it's working in concert with a live developer who is coding at various times, and the compiler is not just seeing static code that is more or less stable from a mature code base. Having this new ability would allow us to introduce a slew of features which bake-in on the first compile, and are then viewed as constants after that. The machine would do it reliably, and we wouldn't have to get bogged down in defining extra minutia details. -- Rick C. Hodgin |
| Richard Damon <Richard@Damon-Family.org>: Apr 19 12:37PM -0400 On 4/19/19 9:25 AM, Rick C. Hodgin wrote: >> entry. This says that calling code has names for the various error >> codes, rather than having to be littered with all the magic numbers. > I am unaware of the rule of magic numbers. The basic rule is that a 'magic number' should appear at most once in any program, generally to assign it to some named constant of some sort to be used elsewhere. Basically, if you have code that does something like: if(error == -2) ... You have a magic number there and you need to dig into the documentation to have any idea what that number means (there is nothing inherent in the value -2 that tells you what the error would be). A second problem with magic numbers is that if you need to change what the value is of that magic number at its source (perhaps you started with two distinct sets of error codes with overlapping values, and now you need them to be distinct), you now need to go through you whole source code and change the value, and determine if that use of the value was this magic value, or some other magic value, or maybe something that just happened to have that value mathematically. If every use of that magic number used a symbolic name, than changing it is easy, you just need to change the value assigned to that symbolic name. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 19 12:52PM -0400 On 4/19/2019 12:37 PM, Richard Damon wrote: > You have a magic number there and you need to dig into the documentation > to have any idea what that number means (there is nothing inherent in > the value -2 that tells you what the error would be). Got it. -- Rick C. Hodgin |
| Joe Pfeiffer <pfeiffer@cs.nmsu.edu>: Apr 19 05:16PM -0600 > I can see doing this in an external tool, but is there some way to do > it in C/C++? > And if not, does anyone have any idea for a good syntax on how to do it? This really doesn't seem like a good idea to me. Not only are you using "magic numbers", you're using magic numbers you haven't defined yourself, and whose value will change if additional if's get added at some later time. I'd much rather use an enum and typedef typedef enum {SUCCESS, OOPS, FATAL_ERR, ...} ReturnCode; |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 19 06:26AM -0700 If you find traditional Bibles boring to read, perhaps this new design by a couple millennials will make it more appealing: A Modern Attractive Bible https://www.foxnews.com/faith-values/bible-millennial-instagram-generation -- Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 19 09:05PM +0100 On 19/04/2019 14:26, Rick C. Hodgin wrote: > design by a couple millennials will make it more appealing: > A Modern Attractive Bible > https://www.foxnews.com/faith-values/bible-millennial-instagram-generation And Satan invented fossils, yes? /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 19 04:40PM +0200 I often asked myself if there is something like basic_string, but with a template-parameter for the size of an an internal buffer which holds the string instead of allocating the content on the heap. Optionally this could include allocating storage for strings which exceed the internal capaciy (otherwise the string could throw an exception if it will be grown beyond the limit) Such a class could have a number of non-member operator-overloads for adding strings and whatever (thereby yieding a usual basic_string of course). And a number of member-operators like += which operate on the internal buffer. When correctly used, f.e. for strings which are temporary and could reside on the stack anyway, this type of strings with an internal buffer could increase the performance of string-handling significantly. On the other side, there are many standard-library facilities that only accept a basic_string so this type of string would be incompatible. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 19 08:40PM +0200 Am 19.04.19 um 16:40 schrieb Bonita Montero: > I often asked myself if there is something like basic_string, but with a > template-parameter for the size of an an internal buffer which holds the > string instead of allocating the content on the heap. std::array<char,N>? > could include allocating storage for strings which exceed the internal > capaciy (otherwise the string could throw an exception if it will be > grown beyond the limit) Some string implementations have handling for fast in place storage for short strings. > When correctly used, f.e. for strings which are temporary and could > reside on the stack anyway, this type of strings with an internal buffer > could increase the performance of string-handling significantly. Have a look at the short string optimization. > On the > other side, there are many standard-library facilities that only accept > a basic_string so this type of string would be incompatible. Exactly. And converting strings over and over (with allocations) can be much more impact than the optimization gain. As long as there is no need to pass /mutable/ strings to library functions the use of const char* is the least common denominator. It is quite easy to provide zero copy conversion operators to this type for any string implementation. Marcel |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 19 08:58PM +0200 >> template-parameter for the size of an an internal buffer which holds the >> string instead of allocating the content on the heap. > std::array<char,N>? Thats much less than the functionality I have in mind. >> grown beyond the limit) > Some string implementations have handling for fast in place storage for > short strings. Short stings woulf fit only for very short strings. >> a basic_string so this type of string would be incompatible. > Exactly. And converting strings over and over (with allocations) can be > much more impact than the optimization gain. There would be no additional conversions. > As long as there is no need to pass /mutable/ strings to library > functions the use of const char* is the least common denominator. Maybe, but there are other cases. Memory-allocation is simply slow. > It is quite easy to provide zero copy conversion operators to this > type for any string implementation. An overloaded += and other operatoes also wouldn't copy if the capacity would be suffient. |
| Ike Naar <ike@faeroes.freeshell.org>: Apr 19 05:27PM > than he is probably a very inexperienced C++ programmer. For most C++ > programmers, std:: adds nothing as a prefix to string in terms of > readability. The problem is that other namespaces may have defined 'string' as well. So if you see unadorned 'string' it's not clear whether std::string, foo::string or bar::string was intended. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 19 07:32PM +0200 > The problem is that other namespaces may have defined 'string' as well. Yes, and main() of course also! I'll bet my right hand on that. |
| Bart <bc@freeuk.com>: Apr 19 07:09PM +0100 On 19/04/2019 18:27, Ike Naar wrote: > The problem is that other namespaces may have defined 'string' as well. > So if you see unadorned 'string' it's not clear whether std::string, > foo::string or bar::string was intended. Why are those other modules also defining 'string'? Which is known to be a built-in type. If they are alternatives to std::string, then wouldn't it make it an easier plug-in replacement if you don't have to go around changing all those "std::" to "foo::"? Besides I thought the IDEs that everyone uses could tell which library any unadorned "string" belonged to. (I've developed some languages with namespaces. But I hardly ever used such a qualifier. In a first version, there was a natural search order so that if 'string' was seen, it would look first in std, next in foo (or equivalents). A qualifier was needed to specify which one. In the next version, a qualifier, ie. a module prefix, would only be needed if 'string' was ambiguous, ie. more than one exported 'string' was visible from that place in the code.) |
| scott@slp53.sl.home (Scott Lurndal): Apr 19 06:21PM >> foo::string or bar::string was intended. >Why are those other modules also defining 'string'? Which is known to be >a built-in type. Perhaps because the code was written long before there was a concept of namespaces (or a class called 'string') in C++? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 19 08:02AM +0200 <url: https://alf-p-steinbach.github.io/cppx-core-DOxygen-generated-documentation/d3/d7c/macro-use_8hpp.html#a4b12dc76791ce4947182d07bd9b0ea20> I wonder if there's some way to /portably/ automate copying of e.g. image files referenced by markdown files, to the relevant place in the Doxygen output folder? For now I chose to just not add those image files manually. Maybe there is some better way of using Doxygen for a GitHub project? I just generate to a folder that I've set GIT to "ignore", and use that folder as GitHub project on its own, presented as GitHub pages. I've not yet experimented with GitHub sub-projects, could that be useful for docs? Cheers!, - Alf |
| 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