| Bonita Montero <Bonita.Montero@gmail.com>: Oct 23 07:55AM +0200 > Or for the few cases where passing a fixed size doesn't work, you can > make the receiver function a template function. (In fact, you showed > how to do it up-thread.) Do you really think someone would accept instantiating a function for each array-length and still don't having variable lengths at runtime? |
| "Öö Tiib" <ootiib@hot.ee>: Oct 22 11:30PM -0700 On Wednesday, 23 October 2019 08:55:57 UTC+3, Bonita Montero wrote: > > how to do it up-thread.) > Do you really think someone would accept instantiating a function for > each array-length and still don't having variable lengths at runtime? You move goal-posts in each post. If you need fixed length array then use (reference of) std:;array. If you need variable length array then use (reference of) std::vector. If you need sub-range of elements of array then use two iterators. Raw array does not solve difference between those needs in any way. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 23 12:14AM -0700 On Tuesday, October 22, 2019 at 4:10:35 PM UTC+1, Keith Thompson wrote: > > slightly more grotesque in nature to the people who find it grotesque > > in the first place. > That's called trolling. Please don't do that. No it's not. It would be trolling if I was doing something wrong and then trying to make the wrong thing look more grotesque. The irony here is that I think you are the biggest troll here. 'Troll' being a less severe word than I intend. What you do is very intricate and falls below some people's radars. Of course we have posts from time to time here like the guy who said the F word in the past few hours, but that's far less harmful than what you've been doing for a few years (including your personal email follow-up's). With that said, I don't think you realise what you're doing. > So you use "auto" and "-> int" to make it deliberately incompatible > with pre-2011 C, and you use "(void)" whose only purpose is to make it > compatible with C. Yes to the first one. With regard to the second one, I always use "(void)" instead of "()" in function declarations/definitions; I just like the feel of it. Plus, if that 'void' was mandatory then we never would have had the problem of object definitions resembling function declarations. |
| David Brown <david.brown@hesbynett.no>: Oct 23 10:04AM +0200 On 23/10/2019 09:14, Frederick Gotham wrote: > like the feel of it. Plus, if that 'void' was mandatory then we never > would have had the problem of object definitions resembling function > declarations. I think the idea of deliberately using the "auto -> int" syntax as a way of being incompatible with pre-C++11 is absurd. Use that syntax if it improves your code in some way. If you really want to force incompatibility with C++03 despite not having any /useful/ post-C++03 syntax, there are better ways to limit the compatibility than to write uglier code. But regarding "void" to mark empty parameters, I think that is fine. In my own projects, it is rare to be pure C++ - I almost invariably have some C modules as well, and empty parameters in a function declaration has a different meaning in C and C++. Using "void" gives the same meaning in both languages, and is thus my preference. There are plenty of times in C and C++ where some parts of the syntax or code can be omitted without affecting the behaviour, and people have different preferences or standards there. Some people like to write "unsigned", others prefer "unsigned int", and so on. Use whatever makes the code clearer, easier to read, more likely to be right, and less likely to be wrong - based on the kind of code you are writing and the people who will be working with it. But pick /good/ reasons for doing it, especially if you are straying from popular convention - "just to be incompatible" is /not/ a good reason. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 23 01:08AM -0700 On Wednesday, October 23, 2019 at 9:04:23 AM UTC+1, David Brown wrote: > syntax, there are better ways to limit the compatibility than to write > uglier code. > But regarding "void" to mark empty parameters, I think that is fine. If you are trying to induce emesis in me then you're going the right way about it. |
| David Brown <david.brown@hesbynett.no>: Oct 23 11:02AM +0200 On 23/10/2019 10:08, Frederick Gotham wrote: >> uglier code. >> But regarding "void" to mark empty parameters, I think that is fine. > If you are trying to induce emesis in me then you're going the right way about it. Are you deliberately trying to alienate people in this group who have given you useful advice? Making posts like a small child who has found a dictionary is one way to achieve that. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 23 02:32AM -0700 On Wednesday, October 23, 2019 at 10:02:32 AM UTC+1, David Brown wrote: > Are you deliberately trying to alienate people in this group who have > given you useful advice? Making posts like a small child who has found > a dictionary is one way to achieve that. Thanks for asking me to explain myself. Back when I was 15 and in school, I had an English teacher who told us that a particular bird was ugly. I think he was referring to the raven or the crow, can't remember exactly which one. I do distinctly remember though that he followed up the statement with "and that's an objective view". Like my old English teacher, I don't think that you are able to comprehend the fact that there are things that you don't like. Since my way of defining the 'main' function works just the same as your way, it seems we simply have a case here of a human being not liking when people do things other ways. Hence my reference to vomit. |
| David Brown <david.brown@hesbynett.no>: Oct 23 12:18PM +0200 On 23/10/2019 11:32, Frederick Gotham wrote: >> given you useful advice? Making posts like a small child who has found >> a dictionary is one way to achieve that. > Thanks for asking me to explain myself. I didn't. > Hence my reference to vomit. Hence my reference to making posts like a small child. End of thread, I think. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 23 03:38AM -0700 On Wednesday, 23 October 2019 12:32:54 UTC+3, Frederick Gotham wrote: > Back when I was 15 and in school, I had an English teacher who told us that a particular bird was ugly. I think he was referring to the raven or the crow, can't remember exactly which one. I do distinctly remember though that he followed up the statement with "and that's an objective view". > Like my old English teacher, I don't think that you are able to comprehend the fact that there are things that you don't like. Since my way of defining the 'main' function works just the same as your way, it seems we simply have a case here of a human being not liking when people do things other ways. > Hence my reference to vomit. Success or failure in this world usually *depends on* if other people like or dislike what you do. Being deliberately grotesque is not what (software) engineering is about. However if you start to vomit because someone disliked your choice to be deliberately grotesque ... then whom you anticipate to like that reaction? |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 23 01:11PM +0200 > If you need variable length array then use (reference of) std::vector. > If you need sub-range of elements of array then use two iterators. > Raw array does not solve difference between those needs in any way. A pointer and a size_t or a start and an end-pointer fits all cases. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 23 04:34AM -0700 On Wednesday, October 23, 2019 at 11:39:10 AM UTC+1, Öö Tiib wrote: > (software) engineering is about. However if you start to vomit because > someone disliked your choice to be deliberately grotesque ... then > whom you anticipate to like that reaction? People who live and let live. |
| Bo Persson <bo@bo-persson.se>: Oct 23 01:46PM +0200 On 2019-10-23 at 13:11, Bonita Montero wrote: >> If you need sub-range of elements of array then use two iterators. >> Raw array does not solve difference between those needs in any way. > A pointer and a size_t or a start and an end-pointer fits all cases. That's because your "a start and an end-pointer" *is* the "use two iterators" case. :-) Bo Persson |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 23 01:49PM +0200 > That's because your "a start and an end-pointer" *is* the "use two > iterators" case. :-) Don't you understand? When you have a function that takes a start and end pointer you can refer to a vector, array or std::array. But you can't when you're fixed to std::vector<T>::iterator. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 23 04:39PM +0300 On 23.10.2019 14:49, Bonita Montero wrote: > Don't you understand? When you have a function that takes a start and > end pointer you can refer to a vector, array or std::array. But you > can't when you're fixed to std::vector<T>::iterator. That's why in all STL algorithms the iterator type is a template parameter. |
| Bo Persson <bo@bo-persson.se>: Oct 23 03:40PM +0200 On 2019-10-23 at 13:49, Bonita Montero wrote: > Don't you understand? When you have a function that takes a start and > end pointer you can refer to a vector, array or std::array. But you > can't when you're fixed to std::vector<T>::iterator. Who said you should be "fixed to" some type? template<class iterator> void f(iterator start, iterator end); will work for any pair of iterators, *including* your pointers. Bo Persson |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 23 03:47PM +0200 >> end pointer you can refer to a vector, array or std::array. But you >> can't when you're fixed to std::vector<T>::iterator. > That's why in all STL algorithms the iterator type is a template parameter. And this helps a function to accept all the three above types? |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 23 03:48PM +0200 > template<class iterator> > void f(iterator start, iterator end); > will work for any pair of iterators, *including* your pointers. Of course, but for the above three types this pure syntactic sugar. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 22 11:59PM -0700 So I was playing around with aligned_storage, and I had something like: aligned_storage< max(sizeof(A), sizeof(B)), max(alignof(A), alignof(B)) >::type buf; But then this wouldn't compile because "max" isn't a constexpr. So next I decided I'd just use a MAX macro instead. So then I was perusing a reference of the C++11 standard library and I came across aligned_union, which seemed to be exactly what I needed, as the previous code would become: aligned_union<1, A, B>::type buf; I'm curious though. . . How does aligned_union work fine in C++11 if max didn't become a constexpr until C++14 ? Is this simply a case of "The Standard says it has to work"? |
| "Öö Tiib" <ootiib@hot.ee>: Oct 23 01:12AM -0700 On Wednesday, 23 October 2019 09:59:14 UTC+3, Frederick Gotham wrote: > aligned_union<1, A, B>::type buf; > I'm curious though. . . > How does aligned_union work fine in C++11 if max didn't become a constexpr until C++14 ? I am not 100% sure but I trust that max can't work because max is required to return reference to one of its arguments. C++11 allowed reference constant expressions only to designate objects of static storage duration or functions. The sizeof invocations are not producing objects of static storage duration. The later standards relaxed those requirements in major ways. > Is this simply a case of "The Standard says it has to work"? That aligned_union was likely implementable already in C++98. |
| David Brown <david.brown@hesbynett.no>: Oct 23 11:14AM +0200 On 23/10/2019 10:12, Öö Tiib wrote: > or functions. The sizeof invocations are not producing objects of static > storage duration. The later standards relaxed those requirements in > major ways. A simple "(a > b) ? a : b" will be a constant expression in C++, as long as "a" and "b" are constant expressions, so I guess aligned_union uses something like that directly rather than std::max. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 23 02:26AM -0700 On Wednesday, October 23, 2019 at 10:14:56 AM UTC+1, David Brown wrote: > A simple "(a > b) ? a : b" will be a constant expression in C++, as long > as "a" and "b" are constant expressions, so I guess aligned_union uses > something like that directly rather than std::max. It's a variadic template, so you can do this: aligned_union<1,HWND,char*,double,ifreq,std::string>::value buf; I dunno how they'd pull that off without a 'max' that takes multiple arguments. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 23 03:18AM -0700 On Wednesday, 23 October 2019 12:26:50 UTC+3, Frederick Gotham wrote: > It's a variadic template, so you can do this: > aligned_union<1,HWND,char*,double,ifreq,std::string>::value buf; > I dunno how they'd pull that off without a 'max' that takes multiple arguments. By using (a > b) ? a : b recursively like lot of variadic templates do. |
| Bo Persson <bo@bo-persson.se>: Oct 23 12:46PM +0200 On 2019-10-23 at 11:26, Frederick Gotham wrote: > It's a variadic template, so you can do this: > aligned_union<1,HWND,char*,double,ifreq,std::string>::value buf; > I dunno how they'd pull that off without a 'max' that takes multiple arguments. The implementors can of course write their own constexpr _Max that only works for std::size_t and returns by value. No reference support needed. Bo Persson |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 22 11:52PM -0700 On Tuesday, October 22, 2019 at 9:10:24 PM UTC+1, Jorgen Grahn wrote: > Things get complicated once you have a Supervisor supervising things > which /pretend/ to work, when everyone knows they are really asleep on > the job. I don't want to complicate the Supervisor, and so I'm happy to put the gas_monitor process to sleep. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 23 02:52AM -0700 On 10/22/2019 11:52 PM, Frederick Gotham wrote: >> which /pretend/ to work, when everyone knows they are really asleep on >> the job. > I don't want to complicate the Supervisor, and so I'm happy to put the gas_monitor process to sleep. But, won't the Supervisor just try to restart it? Locking a non-recursive mutex twice in the same thread is an error. This can be solved multiple ways. The easy way is to create the Supervisor as a service/ daemon. Robust mutexs can be used to detect when a process dies. |
| 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