- TDD can be useful even when it doesn't achieve what you want - 6 Updates
- C++ complex.h protability - 12 Updates
- String integer id - 6 Updates
- "²" - stray '\262' in program - 1 Update
| legalize+jeeves@mail.xmission.com (Richard): Feb 22 05:07AM [Please do not mail me a copy of your followup] Wouter van Ooijen <wouter@voti.nl> spake the secret code >But that doesn't seem to be this page >http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd , or did I >somehow misread that page? I looked at that page after your post. I don't know why he doesn't mention refactoring on there. My guess is that he's focused on when and how you can introduce new functionality under strict TDD rules because this is the part that most people get wrong when they try TDD. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 22 07:44PM On 22/02/2016 05:07, Richard wrote: > mention refactoring on there. My guess is that he's focused on when > and how you can introduce new functionality under strict TDD rules > because this is the part that most people get wrong when they try TDD. TDD and classic refactoring are in conflict. TDD is bollocks pure and simple. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Feb 23 08:58AM +1300 Mr Flibble wrote: > TDD and classic refactoring are in conflict. TDD is bollocks pure and > simple. How is your considered critique coming along? -- Ian Collins |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 22 08:13PM On 22/02/2016 19:58, Ian Collins wrote: >> TDD and classic refactoring are in conflict. TDD is bollocks pure and >> simple. > How is your considered critique coming along? I do hope you are writing that whilst saying it out loud in Stewie Griffin's voice. /Flibble |
| Wouter van Ooijen <wouter@voti.nl>: Feb 22 09:18PM +0100 Op 22-Feb-16 om 8:44 PM schreef Mr Flibble: >> and how you can introduce new functionality under strict TDD rules >> because this is the part that most people get wrong when they try TDD. > TDD and classic refactoring are in conflict. Explaining the conflict would be more usefull than just asserting that there is a conflict. And why the 'classic'? You see to imply that TDD is not in conflict with some other type of refactoring? > TDD is bollocks pure and simple. Again, providing details is more usefull than a simple assertion. And as a lengthy discussion has shown me, it is usefull to state what you think TDD is exactly. I would agree with you when TDD == (the three rules without refactoring), but that seems to be a strawman. Wouter van Ooijen |
| Ian Collins <ian-news@hotmail.com>: Feb 23 09:19AM +1300 Mr Flibble wrote: >> How is your considered critique coming along? > I do hope you are writing that whilst saying it out loud in Stewie > Griffin's voice. Who? -- Ian Collins |
| "Öö Tiib" <ootiib@hot.ee>: Feb 21 03:41PM -0800 On Monday, 22 February 2016 00:51:43 UTC+2, Marcel Mueller wrote: > the target platform. > By the way, what is the difference between typedef and using in this > context? No differences in that context. (7.1.3.2): ... It has the same semantics as if it were introduced by the typedef specifier. ... Lot of programmers prefer 'using' because alias declaration is superset of 'typedef' specifier and it is considered easier to read. typedef void meh_t(); using doh_t = void(); static_assert(std::is_same<meh_t,doh_t>(), "should be no difference"); |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 22 12:50AM +0100 On 21.02.2016 23:51, Marcel Mueller wrote: > This might work. I have to test it. I have to check whether the code > references the type complex<> directly somewhere else. > If it works it is the best solution so far. Such a direct technical fix can appear to be best, but when I offered this purely technical solution in the first follow up to your posting (Ian's presentation of what to write nicely complemented my earlier explanation of what to fix and how – I forgot to make that concrete!), > It doesn't define the name used. Should be just `<complex>`. > • Use of unqualified template `complex`. > Should be `std::complex`. … I went on to mention some higher level solutions. These solutions include ditching the current approach, and at an even higher level, they include considering whether the driving constraints for the problem, e.g. support for early 1990's compilers, stem from e.g. a sociopolitical issue, or really a purely technical issue. > [snip] > By the way, what is the difference between typedef and using in this > context? Only clarity of notation. Which I think is important. ;-) Cheers & hth., - Alf |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 21 08:44PM -0500 On 2/21/2016 5:43 PM, Marcel Mueller wrote: >> Wrong, wrong, wrong. All C compilers from the very beginning just >> included whatever file was listed. > s/compiler/runtime/; Wrong. Compilers. Header files have nothing to do with runtime. > All my complilers from the mid 90's can't deal with namespaces. Neither > Borland supported them nor IBM VAC++ and AFAIR gcc 2.9.5 did not support > it either. Sorry you had compilers which were not standards compliant. That does not mean it wasn't part of the standard. > C++11 code because still some common Linux Distros do not support it > because they use gcc 4.7 which at least requires a compiler option and > even with this option sometimes it does not work. Yes, it takes time for compiler developers to write code. Whether the compiler is up to date with the standard or the distro includes a standards-compliant compiler is immaterial to whether the item is part of the standard or not. > No, it is only about 15 years old. But some of the supported compilers > did not know about namespaces at this time. > Marcel It's not anyone else's fault that you were using non-standards compliant compilers. Namespaces were in the standard, and there were compilers supporting it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Christian Gollwitzer <auriocus@gmx.de>: Feb 22 08:16AM +0100 Am 21.02.16 um 16:48 schrieb Alf P. Steinbach: >> Any suggestions, other than reworking all the old code for newer >> standard compliance? > I suggest switching to another FFT-library, one that works. :) I'm not sure how serious you are with this suggestion. For one thing, FFTW is /the/ FFT library, because it uses a superoptimization approach to achieve very high performance. Especially if you need lengths which are not powers of 2, FFTW is hard to beat. Second, I haven't seen a library which does not define its own complex numbers, because a long time in the C/C++ world complex numbers were not supported overly well, as opposed to Fortran. Just a few weeks ago, we found that neither gcc nor clang can vectorize loops with complex numbers. All 3rd party libraries I know of use a struct mycomplex { double real; double imag; } It is nonsense to make these members private in <complex> with trivial getters and setters. I have never seen an implementation which uses polar coordinates or the like. Christian |
| Robert Wessel <robertwessel2@yahoo.com>: Feb 22 02:54AM -0600 On Sun, 21 Feb 2016 14:25:50 -0500, Jerry Stuckle >would work if there was a file abc.xyz in the path. The *convention* at >the time was to have header files with an extension of .h. But it was >*never* a compiler requirement. That's at least partially incorrect. Early (pre-Unix System Services) C compilers for MVS would not, mainly because there was no way to specify an extension (including a ".H") on the actual source member being included. The ".H" would be dropped, and the file would be searched for from a list of (usually) PDS's defined in the search list (and usually two separate lists for system and user includes). |
| "Öö Tiib" <ootiib@hot.ee>: Feb 22 02:06AM -0800 On Monday, 22 February 2016 09:16:37 UTC+2, Christian Gollwitzer wrote: > >> standard compliance? > > I suggest switching to another FFT-library, one that works. :) > I'm not sure how serious you are with this suggestion. Smiley indicates that it was not serious suggestion. Serious suggestion (that you snipped) seemed to be to fix FFTW and to submit a patch to it. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 22 07:38PM +0100 On 22.02.16 02.44, Jerry Stuckle wrote: > It's not anyone else's fault that you were using non-standards compliant > compilers. I enumerated *all existing* compilers for the platform at this time in the past. > Namespaces were in the standard, and there were compilers > supporting it. In theory. Marcel |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 22 02:14PM -0500 On 2/22/2016 1:38 PM, Marcel Mueller wrote: >> supporting it. > In theory. > Marcel In practice. I used them. Both on Windows and Linux/Unix. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Cholo Lennon <chololennon@hotmail.com>: Feb 22 04:36PM -0300 On 02/21/2016 10:44 PM, Jerry Stuckle wrote: >> it either. > Sorry you had compilers which were not standards compliant. That does > not mean it wasn't part of the standard. It's depends on what you define as C++ standard. Normally we tend to use the ISO C++ as a reference (1998 or later). The ARM document (where namespaces are described) is not considered "the" C++ standard. BTW, what was your compiler that implemented namespaces in the early 90's? As Marcel Mueller said, my compilers in those years didn't have support for namepaces (Borland/Microsoft) -- Cholo Lennon Bs.As. ARG |
| Ian Collins <ian-news@hotmail.com>: Feb 23 08:53AM +1300 Cholo Lennon wrote: > It's depends on what you define as C++ standard. Normally we tend to use > the ISO C++ as a reference (1998 or later). The ARM document (where > namespaces are described) is not considered "the" C++ standard. There weren't any standards compliant compilers in the early 90s because there wasn't a standard! -- Ian Collins |
| Cholo Lennon <chololennon@hotmail.com>: Feb 22 05:03PM -0300 On 02/22/2016 04:53 PM, Ian Collins wrote: >> namespaces are described) is not considered "the" C++ standard. > There weren't any standards compliant compilers in the early 90s because > there wasn't a standard! Well, that was I was trying to say (in a complex manner btw) ;-) Regards -- Cholo Lennon Bs.As. ARG |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 22 03:16PM -0500 On 2/22/2016 2:53 PM, Ian Collins wrote: >> namespaces are described) is not considered "the" C++ standard. > There weren't any standards compliant compilers in the early 90s because > there wasn't a standard! Just because there wasn't an ISO standard at the time doesn't mean there wasn't a standard. It started with Stroustrup's book. Modifications followed from that. People think that ISO is the only organization which can issue standards. Nothing is further from the truth. If they come out with a standard, it is generally recognized world-wide. But when they haven't, there can still be standards. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| malcolm.mclean5@btinternet.com: Feb 22 06:59AM -0800 I want a flyweight class that is a "string id". That is to say, it consists of a 64 bit number which is also a string of up to seven characters, used for passing about human-readable ids that the machine can process as integers. However how do I write it so that it's easy to make it a constexpr, whilst still being convenient to call. (The ids will mostly be known at compile time, only rarely will you have a situation when the user enters a string and it ends up being turned into a dynamic id). Particularly I would like to be able to switch on the id and have human-readable names in the case conditions. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 22 05:30PM +0100 > convenient to call. (The ids will mostly be known at compile time, only rarely will > you have a situation when the user enters a string and it ends up being turned > into a dynamic id). Is this a correct understanding? • Each 64-bit id is usually chosen by the programmer. • There is a (unspecified) two-way mapping between 64-bit id and 7-character human readable string. • You're asking how to compute the unspecified mapping at compile time. > Particularly I would like to be able to switch on the id and have human-readable names > in the case conditions. Is this a correct understanding: • Particularly you want a `constexpr` string → number computation? Which just seems like a user defined literal. And is this a correct understanding: • You are free to choose a suitable mapping, and the criterion "human-readable" is also a very loose one? Cheers, - Alf |
| malcolm.mclean5@btinternet.com: Feb 22 09:04AM -0800 On Monday, February 22, 2016 at 4:30:45 PM UTC, Alf P. Steinbach wrote: > * There is a (unspecified) two-way mapping between 64-bit id and > 7-character human readable string. > * You're asking how to compute the unspecified mapping at compile time. The idea is that the id is an unsigned 64 bit integer, which is also an asciiz string of seven characters plus null. So if the id is "charlie" then the id is 99 (ascii c) * 2**56 + 104 * 2**48 and so on. So if there's some question about the ids, you can analyse the binary or print the value out as a string, and you've got a human-meaningul enumeration value, e.g. "charlie", "andy", "anne" and "eddie" rather than 1, 2, 3, 4. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 22 07:03PM +0100 > So if there's some question about the ids, you can analyse the binary or > print the value out as a string, and you've got a human-meaningul enumeration > value, e.g. "charlie", "andy", "anne" and "eddie" rather than 1, 2, 3, 4. Well, that's directly supported by the language, so it's in a sense trivial. Of course it helps to know what to look for, namely user defined literals. I already mentioned that. General discussion of user defined literals in the FAQ: <url: https://isocpp.org/wiki/faq/cpp11-language#udls> Technical info, nearly as good as the standard: <url: http://en.cppreference.com/w/cpp/language/user_literal>. Relevant tips: • For precondition checking you can use the `?:` conditional operator, with e.g. throw statements. And yes that works nicely for compile time checking, because `throw` isn't `constepxr`. • Also, for precondition checking it can be good idea to defer the main work to a separate implementation function (that just assumes valid preconditions). • Remember to cast each `char` value to unsigned. • To check whether you really get a compile time value, use it in a context that requires compile time value. Switch `case` is of course one such context. Others include array size, and just as initialization of a `constexpr` variable. • For a C++11 solution you need to recursion to avoid a nasty complex expression. For C++14 I believe you can use a loop. I'd just use recursion here anyway, because it's very clear for this, and concise. Cheers & hth., - Alf |
| Barry Schwarz <schwarzb@dqel.com>: Feb 22 11:41AM -0800 On Mon, 22 Feb 2016 06:59:14 -0800 (PST), >into a dynamic id). >Particularly I would like to be able to switch on the id and have human-readable names >in the case conditions. For values known at compile time, #define should do what you want. For example, the name Ann is 0x41 for the A and 0x6e for each n so #define Al 0x416e6e /* or possibly 0x416e6e0000000000 */ will allow you to code switch (id){ case Ann: ... -- Remove del for email |
| Ian Collins <ian-news@hotmail.com>: Feb 23 09:13AM +1300 Barry Schwarz wrote: >> Particularly I would like to be able to switch on the id and have human-readable names >> in the case conditions. > For values known at compile time, #define should do what you want. This is comp.lang.c++, cont comp.lang.c! -- Ian Collins |
| David Brown <david.brown@hesbynett.no>: Feb 22 09:43AM +0100 On 21/02/16 14:30, Mr Flibble wrote: >> Windows too. > I cannot do it on Windows ergo my assertion still stands mate: it would > not be a useful addition to the language. You can always try something like <https://github.com/SamHocevar/wincompose> I am not suggesting that making this ² operator is a good idea - it's not easily readable, and too few compilers support extended identifiers properly (I don't know of any other than clang). All I am saying is that a lot of people /can/ type such characters fairly easily, and those that can't (because they are limited by Windows) can add third-party software to get such features. In most cases, of course, the benefit of extended identifiers is for non-English language programmers to be able to use identifiers in their own language - typing with their normal keyboard layout. |
| 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