- Is there a way to determine endianess in a constexpr-function ? - 1 Update
- C++ threshold for "stupid" sorting algorithms (O(n^2)) - 7 Updates
- Don't be fooled by cpp.sh - 13 Updates
- What is the data structure of a NULL? - 2 Updates
- invalid use of non-static member function - 2 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 01 05:46PM +0100 Is there a way to determine endianess in a constexpr-function which might return true for little endian and false for big endian? I guess not, but maybe I din't consider a trick here. |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jan 01 01:17PM +0100 In your experience, what is (roughly) a reasonable threshold (n) in terms of convenience of passing from stupid algorithms (bubblesort, gnomesort) to better and more complex ones ? I know this depends a lot also on HW. But to write down an order of magnitude, I'm talking about small data sets (some tens to at worst some hundredth, never above 1000). With such small figures, I was thinking that even the most simple O(n^2) bubble or gnome could be acceptable. But I've no experience in real comparison. The application is not performance intensive, at least for this operations which would be performed only a few times I did not mention that the algorithm HAS TO BE "stable" : not to move equally ranked items (in order to allow tables to be sorted by multiple keys) -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 01 01:25PM +0100 > In your experience, what is (roughly) a reasonable threshold (n) in > terms of convenience of passing from stupid algorithms (bubblesort, > gnomesort) to better and more complex ones ? Don't use the simpler algorithms. Algthough they might be faster on a few elements, their runtime doesn't count then because there are just a few elements. |
| Bo Persson <bo@bo-persson.se>: Jan 01 01:34PM +0100 On 2020-01-01 at 13:17, Soviet_Mario wrote: > terms of convenience of passing from stupid algorithms (bubblesort, > gnomesort) to better and more complex ones ? > I know this depends a lot also on HW. It also depends on the data that is to be sorted. For example, if the data is already almost correctly sorted, that will be the best case for bubblesort but the worst case for quicksort. So, it depends. Bo Persson |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jan 01 02:09PM +0100 On 01/01/2020 13:34, Bo Persson wrote: > For example, if the data is already almost correctly sorted, > that will be the best case for bubblesort but the worst case > for quicksort. I won't even be able to write a stable version of quick sort :\ -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Bo Persson <bo@bo-persson.se>: Jan 01 03:16PM +0100 On 2020-01-01 at 14:09, Soviet_Mario wrote: >> For example, if the data is already almost correctly sorted, that will >> be the best case for bubblesort but the worst case for quicksort. > I won't even be able to write a stable version of quick sort :\ No, of course not. Just saying that there are cases where a "stupid" algorithm can be O(n) and a "smart" one be O(n^2). And that it can be data dependent, and not just depend on the size. That might make it hard to find a useful general threshold. Bo Persson |
| Robert Wessel <robertwessel2@yahoo.com>: Jan 01 09:24AM -0600 On Wed, 1 Jan 2020 13:17:09 +0100, Soviet_Mario <SovietMario@CCCP.MIR> wrote: >I did not mention that the algorithm HAS TO BE "stable" : >not to move equally ranked items (in order to allow tables >to be sorted by multiple keys) Generally the O(n**2) sorts are considered usable up a few tens of items. And use insertion sort, not bubble sort (simpler algorithm, twice as fast on average). But you're posting this is a C++ forum. std::stable_sort short be your first choice for such a requirement. The first question is why *not* use the library function? If you think it's only for containers, that's wrong, you can use std::begin and std::end to process a normal array. |
| Soviet_Mario <SovietMario@CCCP.MIR>: Jan 01 05:12PM +0100 On 01/01/2020 16:24, Robert Wessel wrote: > items. And use insertion sort, not bubble sort (simpler algorithm, > twice as fast on average). > But you're posting this is a C++ forum. std::stable_sort short be gulp ! I did not even know it existed ... I will try to see if I'm able to apply to struct data (where the sorting is to be done by a specialized comparison operator o function) yes a built-in function would be a lot appreciated. I used to use vectors <type> on some IDEs .... but on some others, QT for example, now I only find another kind of vector template, requiring not only a type, but also an "allocator" (and I don't know what to pass as argument, I'd just prefer the general purpose allocator). Dunno why only these new vectors are provided. > your first choice for such a requirement. The first question is why > *not* use the library function? I did not know about :) > If you think it's only for > containers, that's wrong, you can use std::begin and std::end to > process a normal array. I find it more readable to be able to use operator [] (int Index) actually -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 31 04:06PM -0800 On 12/31/2019 4:14 AM, David Brown wrote: >> I must be missing your main point, however there is a nice case where >> casting is "okay"?: >> ________________________ [...] >> { >> int a; >> }; [...] > And in this case, I believe it is perfectly valid - the address of a > struct is guaranteed (in C, and I think also in C++ for POD with no > virtual stuff) to be the address of its first member. Agreed. Thanks David. Fwiw, perhaps: https://en.cppreference.com/w/cpp/types/is_pod can come in handy... ;^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 31 04:14PM -0800 On 12/31/2019 8:51 AM, David Brown wrote: > Nonsense. No one uses "/Wall" (if that is the right option) on MSVC > because it really means "enable all warnings supported by the compiler" > and generates a great deal of noise for most code. What if one likes looking at all the warnings, and creates a little game called, no warnings, altered code... joking around here. ;^) Most gcc and clang |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 31 04:16PM -0800 On 12/31/2019 8:58 AM, Paavo Helde wrote: >> it generates a lot of nonsense-warnings > Are you kidding? -Wall is one of the most basic options one always uses > with gcc (together with -Wextra and a bunch of other warning flags). Heck, what about -ansi and/or -pedantic... ;^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 31 04:52PM -0800 On 12/31/2019 4:14 PM, Chris M. Thomasson wrote: > On 12/31/2019 8:51 AM, David Brown wrote: >> On 31/12/2019 15:45, Bonita Montero wrote: [...] > What if one likes looking at all the warnings, and creates a little game > called, no warnings, altered code... joking around here. ;^) Well, actually, not joking. [...] |
| "Öö Tiib" <ootiib@hot.ee>: Dec 31 05:01PM -0800 On Wednesday, 1 January 2020 02:16:26 UTC+2, Chris M. Thomasson wrote: > > Are you kidding? -Wall is one of the most basic options one always uses > > with gcc (together with -Wextra and a bunch of other warning flags). > Heck, what about -ansi and/or -pedantic... ;^) Examples that one posts are good idea to try with -Wall -Wextra -pedantic or to explicitly tell with what options those have or haven't been tried. Everybody do typos, best of us at rate 0.1 per line and so it reduces confusion in communications. or |
| boltar@nowhere.org: Jan 01 09:07AM On Tue, 31 Dec 2019 16:42:30 GMT >> Possibly not a good idea if a virtual function table is anywhere in that >> object. Otherwise it would be no different to a C struct. >Why? Is this a trick question? Because where the VFT is placed is compiler dependant and it will make a difference on what line up wheres in the union with the other types. >>>Depends on compiler... >> Name one compiler that doesn't. >All that headers usually have #ifdef __cplusplus ... Name one compiler that doesn't. |
| boltar@nowhere.org: Jan 01 09:09AM On Tue, 31 Dec 2019 17:06:52 +0000 >> that is what templates were invented for. They're also more flexible than >> variants. >std::variant is a template. ITYM its a class that uses templates. However, congratulations on completely missing the point. Again. |
| boltar@nowhere.org: Jan 01 09:13AM On Tue, 31 Dec 2019 18:11:11 +0100 >> variants. >I think you are /seriously/ confused. I am not convinced you know >enough C++ or programming to understand how little you know. No, you're just as thick as Leigh who didn't get the point either but you're too arrogant to realise. >> Many? As I've asked in another post - name a single one that doesn't. >I don't know if there are any that don't support it. Thats because there arn't any because all C++ compilers are also C compilers. >know that the C++ standards specifically say that it is not allowed. So >I think it is reasonable to say "Many C++ compilers support it", but >there is no justification for claiming it applies to all. Variable length C99 arrays arn't in the C++ standard but I've yet to come across a C++ compiler that didn't support them either. |
| boltar@nowhere.org: Jan 01 09:17AM On Tue, 31 Dec 2019 18:14:28 +0000 >templates for polymorphic code. Their main purpose is to allow values >of a limited set of alternative types to be passed in a type safe way. >Secondly, variants are constructed from templates. Templates are not There's nothing more amusing than people who think they're smart attempting to demonstrate it by stating the bleeding obvious. That makes 3 of you now :) So the chevrons with the types following the variant class name are a template def are they? Gosh, thanks for the heads up there Einstein, I never knew! LOL :) Happy New Year you bunch of muppets :) |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 01 03:48PM +0200 > Is this a trick question? Because where the VFT is placed is compiler dependant > and it will make a difference on what line up wheres in the union with the > other types. No shit, Sherlock! Are we now finally getting somewhere? Of course, if there might be an unknown number of vtable pointers and stuff in the beginning of the object, its fields might not line up with other union members and one cannot cast it (e.g. via union type punning) to other union type willy-nilly. That's EXACTLY what everybody has tried to explain you for several days already: one is allowed to access ONLY the ACTIVE member of the union at any time moment. Good that you are starting to understand it now. |
| Robert Wessel <robertwessel2@yahoo.com>: Jan 01 09:09AM -0600 >Variable length C99 arrays arn't in the C++ standard but I've yet to come >across a C++ compiler that didn't support them either. MSVC. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 01 05:34PM +0200 On 1.01.2020 2:16, Chris M. Thomasson wrote: >> Are you kidding? -Wall is one of the most basic options one always >> uses with gcc (together with -Wextra and a bunch of other warning flags). > Heck, what about -ansi and/or -pedantic... ;^) -ansi is a synonym for -std=c++98, this is too old. Suggesting at least -std=c++11. -pedantic is likely a good idea. |
| Daniel <danielaparker@gmail.com>: Jan 01 08:11AM -0800 > The whole point of a union is not to save memory, its to write as one type > and read as another Not according to K&R, 1st edition. K&R write "This is the purpose of a union — to provide a single variable which can legitimately hold any one of several types. union u_tag { int ival; float fval; char *pval; } uval; The variable uval will be large enough to hold the largest of the three types, regardless of the machine it is compiled on — the code is independent of hardware characteristics. Any one of these types may be assigned to uval and then used in expressions, so long as the usage is consistent: the type retrieved must be the type most recently stored. It is the responsibility of the programmer to keep track of what type is currently stored in a union; the results are machine dependent if something is stored as one type and extracted as another." |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Dec 31 11:30PM -0500 On 12/31/19 11:46 AM, Ned Latham wrote: > �� Tiib wrote: >> Ned Latham wrote: ... > News to me. Might be because I'm a lazy reader or because my references > are out of date: Kernigan and Ritchie for C (ANSI 2) and Stroustrup > (Edition 3) for C++. Both 1990s. Yes, those sources are thirty years out of date. bool didn't even exist in K&R C, and if conditions were and are handled differently. In first edition of K&R C, it says "The unary negation operator ! converts a non-zero or true operand into 0, and a zero or false operand into l." However, the second edition came out shortly before the C89 was approved, and used wording closer to that of the soon-to-be approved standard: "The operand of the ! operator must have arithmetic type or be a pointer, and the result is 1 if the value of its operand compares equal to 0, and 0 otherwise." (A.7.4.7). The key issue may is the phrase "compares equal to". What happens when a pointer value is compared for equality with 0? Comparison for equality is covered by A.7.10, and for the special case where a pointer is "compared to a constant integral expression with a value of 0", it cross-references A.6.6. That paragraphs indicates that comparison operators are one way in which an integral constant expression with a value of 0 gets converted to pointer type, and it specifies that "This produces a null pointer that is equal to another null pointer of the same type, but unequal to any pointer to a function or object." Thus, !array has the value !(array==0), and array==0 has a value of true if array is a null pointer, and 1 if it does not, completely independent of how null pointers are represented. That is exactly the way the same issue is handled in all later versions of the C standard. My copy of Stroustrup disappeared a long time ago. My copy of the C++98 standard was saved on a hard disk which crashed. The oldest version of the standard I can locate is C++2011. As of that version, the relevant issues were addressed in the same fashion as in the current version: the unary ! is described in terms of inverting the result of a conversion to bool, and the rules for conversion to bool specify that null pointer values get converted to false. Thus, the result is guaranteed to be false for null pointer values, regardless of how they are represented. I'm curious: how does the description of these issues in your copy of Stroustrup differ from those descriptions? With the preceding C standard and the following C++ standards so carefully written to produce results that are independent of how null pointers are represented, it would seem very odd if that version of C++ was defined in a way which did depend upon the representation. >> It does not say that bit-wise checks are made, > If NULL == 0, bitwise checks aren't required, just a check of the > Z flag of the register that received the return. How would that work? If null pointer values are, for instance, represented by having all bits set to 1 (as has actually been done by at least one implementation), NULL == 0 will still be true - the standard requires it to be. I suspect that your comments are specific to a particular architecture, one for which "all bits 1" would not be a suitable choice for null pointers. It was a very natural choice on the platform where that representation was actually used. |
| David Brown <david.brown@hesbynett.no>: Jan 01 05:01PM +0100 On 31/12/2019 20:20, Keith Thompson wrote: > In C, NULL can be defined as 0 or as ((void*)0). In C++, ((void*)0) is > not a valid definition of NULL, because C++'s definition of "null > pointer constant" is more strict than C's. True. My point was just an example of how NULL could be defined so that the code that Melzzzzz thought would not compile, could be valid. > 0 could be a null pointer constant, but C++14 restricted this to > integer literals. ((void*)0) hasn't been a valid C++ null pointer > constant going back at least to C++98.) Yes. In C, "((void*) 0)" is a common definition for NULL because it is more expressive and restrictive in its valid uses than 0. In C++, "nullptr" is typically used now, with "0" being the only (AFAIK) portable definition that is valid in many C and C++ standards. Particular compilers can, of course, have their own definitions. Many gcc installations define it as __null. > But yes, NULL might be usable in a context that requires an integer > value depending on how the implementation defines it. Of course it > would be silly to depend on that. Agreed. |
| Andrew Z <formisc@gmail.com>: Dec 31 10:32PM -0800 On Tuesday, December 31, 2019 at 11:22:25 AM UTC-5, Manfred wrote: > The last argument of setup_task is expected to be an object of type > TickType_t, but a pointer to member function is passed instead: > "outlet.GetCycleTicks" should be "outlet.GetCycleTicks()" Manfred, Alf, thank you for the reply. void setup_task( void (*DeviceTask)(void*), char* TaskName, EventGroupHandle_t eventGroup, void (*Callback_Fn)(TimerHandle_t), TickType_t cycle_ticks ) { .. } setup_task( outlet.OutletToggleTask, (char*)"Outlet Task", eventGroup, outlet.OutletCallback, outlet.GetCycleTicks ); why is the outlet.GetCycleTicks is considered to be a pointer, but the eventGroup is not? changing outlet.GetCycleTicks to outlet.GetCycleTicks() or a number doesn't change the compile time error. I'm still digesting what Alf said above... |
| Andrew Z <formisc@gmail.com>: Dec 31 11:03PM -0800 On Tuesday, December 31, 2019 at 12:34:59 AM UTC-5, Alf P. Steinbach wrote: > function `static` in the class, or make it a free function. > [snip] > - Alf Alf, thank you. im not sure i can use the "Static" for Toggle. Toggle resets the bit in the eventgroup ( freertos ) and switches an instance of the outlet on/off. <butchered> void Zap::OutletToggleTask( void *Params) { EventBits_t bits; while (1) { bits = xEventGroupWaitBits(eventGroup,TIME_BIT,pdTRUE, pdFAIL,pdMS_TO_TICKS(15000)); if (bits == 1) { toggle(channel,_switch); ... } .... } } i started writing this code with free functions, when i realized that i can wrap all these functions into an objects and have the concise and clean code... well, best plans of mice and men... not sure what to do.... |
| 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