- Unit testing (Re: Putting project code in many different files) - 17 Updates
- Commenting code considered harmful - 8 Updates
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 08 04:53PM On Sun, 2016-02-07, David Brown wrote: > On 07/02/16 14:20, Paavo Helde wrote: >> On 7.02.2016 14:42, Wouter van Ooijen wrote: ... > platform, it's easy to handle things like starting processes and > capturing their outputs, and it's easy to do text manipulation and > comparisons. Shell scripts are fine for the simple stuff, IME shell scripts are fine for a lot of complex stuff too, if you standardize on /bin/bash and don't go for the lowest common denominator. It has some pretty impressive abstractions relating to processes and pipelines which Python lacks. I don't do Windows; I can imagine Python being a better choice if you don't already have an investment in the Unix ecosystem. Python is also a decent general-purpose language; Bash is not. > marvellous at controlling the build process, but once things get more > advanced you'll be glad you picked python over eye-watering grep, awk > and sed recipes. I do the awk and sed stuff with Perl one-liners. Awk and sed are probably nice, but there are dialects, and I know Perl fairly well. And yes, I see what you mean by "eye-watering". /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| scott@slp53.sl.home (Scott Lurndal): Feb 08 05:30PM >> comparisons. Shell scripts are fine for the simple stuff, >IME shell scripts are fine for a lot of complex stuff too, if you >standardize on /bin/bash and don't go for the lowest common Standardize on the posix shell for the most portability. The posix shell (and BASH) have standardized most of the features of the Korn Shell (ksh). ksh does handle floating point far better than BASH. e.g. $ printf '%f\n' $(( 3.5 * 3.5 )) works fine on ksh, but doesn't work on bash. |
| legalize+jeeves@mail.xmission.com (Richard): Feb 08 06:38PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >frameworks. If the tests pass, the make succeeds. If the fail, the >make files. >Read up on them and you might learn something. This is what I've always taught people to do with their builds and unit testing when I've taught test-driven development in C++. -- "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> |
| legalize+jeeves@mail.xmission.com (Richard): Feb 08 06:39PM [Please do not mail me a copy of your followup] Wouter van Ooijen <wouter@voti.nl> spake the secret code >I didn't express myself clear enough. I want a way to *test* the things >that should result in a compilation failure. This mostly arrises with >template stuff. There might be something in the framework of unit tests that clang uses for this. -- "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> |
| legalize+jeeves@mail.xmission.com (Richard): Feb 08 06:46PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >I don't know of any existing tools specifically designed for testing >compile fails. [...] I've been writing enhancements to clang-tidy by adding what they refer to as 'checks'. These identify things in your source code and propose refactorings to make those things go away. clang-tidy checks emit their messages as warnings or errors. They look very much like messages from the compiler. clang-tidy checks are tested by running them against some source code that is annotated with expected warning/error messages and the expected changes made to the source code by the check to fix the problem. This sounds very much like the sort of thing Wouter van Ooijen wants to achieve: - given an input file that invokes a template in a specific way - expect to see a specific compiler error message - no other compile error messages should be present This is exactly the way the integration tests for clang-tidy work. Take a look here: <https://github.com/llvm-mirror/clang-tools-extra/tree/master/test/clang-tidy> These are the input files to the mechanism I described above. I've written the tests and checks for: - modernize-redundant-void-arg - readability-simplify-boolean-expr - readability-redundant-control-flow <https://gist.github.com/LegalizeAdulthood/933c867c563303ce047f> If you want to see them in action, then do: git clone git@github.com:llvm-mirror/llvm cd llvm/tools git clone git@github.com:llvm-mirror/clang cd tools git clone git@github.com:llvm-mirror/clang-tools-extra extra cd ../../.. mkdir build cd build cmake -G "Unix Makefiles" .. make check-clang-tools Warning: this will grind away for quite some time before the tests run :) -- "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> |
| legalize+jeeves@mail.xmission.com (Richard): Feb 08 06:47PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >If you are using visual studio, you can place the script (be it Python >or Expect or similar) that tests for compilation fails as a pre-build >step rather than a part of the build. I generally recommend post-build step, rather than pre-build step. YMMV -- "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> |
| legalize+jeeves@mail.xmission.com (Richard): Feb 08 06:49PM [Please do not mail me a copy of your followup] David Brown <david.brown@hesbynett.no> spake the secret code >platform, it's easy to handle things like starting processes and >capturing their outputs, and it's easy to do text manipulation and >comparisons. One nit: Python isn't cross platform when it comes to specific expectations on line endings, but otherwise yeah I agree. clang-tidy's integration tests use a combination of hand-written C++ utilities for clang (FileCheck, for instance) and python scripts to glue it all together. -- "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> |
| Ian Collins <ian-news@hotmail.com>: Feb 09 08:07AM +1300 Richard wrote: >> or Expect or similar) that tests for compilation fails as a pre-build >> step rather than a part of the build. > I generally recommend post-build step, rather than pre-build step. The reason I suggested pre-build was the last team I worked with who used visual studio as their IDE used CxxTest for their unit tests. CxxTest uses a Python script to generate the test runner and the IDE's command line processor couldn't handle the parameter syntax. Hence the pre-build script! -- Ian Collins |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 07:35PM On 08/02/2016 18:38, Richard wrote: >> Read up on them and you might learn something. > This is what I've always taught people to do with their builds and > unit testing when I've taught test-driven development in C++. TDD (especially in C++ land) is toxic. /Flibble |
| Ian Collins <ian-news@hotmail.com>: Feb 09 09:05AM +1300 Mr Flibble wrote: >> This is what I've always taught people to do with their builds and >> unit testing when I've taught test-driven development in C++. > TDD (especially in C++ land) is toxic. Have you written your critique of Uncle Bob's paper yet? Or are you still stuck in the "if I repeat bollocks enough it will become true" loop? -- Ian Collins |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 08:14PM On 08/02/2016 20:05, Ian Collins wrote: >> TDD (especially in C++ land) is toxic. > Have you written your critique of Uncle Bob's paper yet? Or are you > still stuck in the "if I repeat bollocks enough it will become true" loop? Likewise if you repeat an axiom enough times it will remain an axiom and if you repeat a fact enough times it will remain a fact. Follow the axioms mate and you will discover the facts. /Flibble |
| Wouter van Ooijen <wouter@voti.nl>: Feb 08 09:20PM +0100 Op 08-Feb-16 om 7:46 PM schreef Richard: > propose refactorings to make those things go away. clang-tidy checks > emit their messages as warnings or errors. They look very much like > messages from the compiler. (snip) Thanks, that was the kind of tip I was looking for! Wouter van Ooijen |
| Ian Collins <ian-news@hotmail.com>: Feb 09 09:22AM +1300 Mr Flibble wrote: > Likewise if you repeat an axiom enough times it will remain an axiom and > if you repeat a fact enough times it will remain a fact. Follow the > axioms mate and you will discover the facts. I'm still waiting for a coherent argument as to why TDD is bad. So where are the facts? -- Ian Collins |
| David Brown <david.brown@hesbynett.no>: Feb 08 09:29PM +0100 On 08/02/16 17:53, Jorgen Grahn wrote: > I do the awk and sed stuff with Perl one-liners. Awk and sed are > probably nice, but there are dialects, and I know Perl fairly well. > And yes, I see what you mean by "eye-watering". It's okay with a bit of one-liners - I have a few sed commands in my standard Makefiles that are a mixture of internet searches and trial-and-error, with only the barest hint of my knowing what I'm doing. But you only need to figure out these things once. The key points in Python's favour are cross-platform (I work mostly in Linux, but not exclusively, and it's easier to get Windows folk to run Python scripts than bash scripts), readability, and convenience when you need to do something slightly more programmatic. But of course, the best tool for the job depends on many factors. I was merely suggesting a tool that could help for someone who wants to avoid a full suite of unixy tools like bash, sed, awk, etc. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 08 10:32PM +0200 On 8.02.2016 22:14, Mr Flibble wrote: > Likewise if you repeat an axiom enough times it will remain an axiom and > if you repeat a fact enough times it will remain a fact. Follow the > axioms mate and you will discover the facts. Do you want to claim that "TDD is toxic" is an axiom? That's fine, because one can freely select another axiom (like "TDD is a cure"), as long as the whole system stays consistent. For example, by changing one axiom in Euclidean geometry one gets Riemann's geometry which is totally different, but equally correct. And no, you do not derive facts from axioms, this method has been abandoned already for a century or two at least. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 08:46PM On 08/02/2016 20:32, Paavo Helde wrote: > Riemann's geometry which is totally different, but equally correct. > And no, you do not derive facts from axioms, this method has been > abandoned already for a century or two at least. False. You can *partly* derive facts from axioms; if a fact consisted solely of axioms it would be an axiom not a fact. /Flibble |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 08 11:01PM +0200 On 8.02.2016 22:46, Mr Flibble wrote: > False. You can *partly* derive facts from axioms; if a fact consisted > solely of axioms it would be an axiom not a fact. If something can be derived from axioms only, then it is called a (proven) theorem, not an axiom. A fact is something you observe, not nothing you derive. When facts contradict your theory, then you have chosen wrong axioms or applied the theory to the real life in a wrong way. |
| Juha Nieminen <nospam@thanks.invalid>: Feb 08 09:18AM >> clear from the implementation itself how and why the algorithm works. >> In that case it's good to explain the algorithm. > when its algorithm you give its name Not all algoritms may have a unique name (as there is not necessarily one unique way of implementing a certain algorithm). Also, you might not know the name of an algorithms (or even if it has one.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| "Öö Tiib" <ootiib@hot.ee>: Feb 08 02:23AM -0800 On Monday, 8 February 2016 11:18:32 UTC+2, Juha Nieminen wrote: > Not all algoritms may have a unique name (as there is not necessarily one > unique way of implementing a certain algorithm). Also, you might not know > the name of an algorithms (or even if it has one.) +1 Also even if we know the name it might be unneeded clutter. Compare "container.mostSignificantDigitRadixSortInPlace()" with "container.sort()". The choice of algorithm is implementation detail of container, does not matter to user and also may change. It is interesting only to developer who maintains the sorting algorithm. |
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Feb 08 05:29AM -0800 W dniu poniedziałek, 8 lutego 2016 11:23:27 UTC+1 użytkownik Öö Tiib napisał: > > Not all algoritms may have a unique name (as there is not necessarily one > > unique way of implementing a certain algorithm). Also, you might not know > > the name of an algorithms (or even if it has one.) well i personally didnt met this case, algorithms i used were always known one and got names > The choice of algorithm is implementation detail of container, does not matter to > user and also may change. It is interesting only to developer who maintains the > sorting algorithm. we are talking about comments (not function names) it is better to said //this is Cohen–Sutherland line clipping than write whole description where you can found it in hundreds of pages books etc |
| Reinhardt Behm <rbehm@hushmail.com>: Feb 08 10:44PM +0800 Prroffessorr Fir Kenobi wrote: > well i personally didnt met this case, > algorithms i used were always known one and > got names So you never developed a new algorithm yourself which at that point in time is nowhere else documented? -- Reinhardt |
| "Öö Tiib" <ootiib@hot.ee>: Feb 08 06:46AM -0800 On Monday, 8 February 2016 15:30:10 UTC+2, Prroffessorr Fir Kenobi wrote: > //this is Cohen–Sutherland line clipping > than write whole description > where you can found it in hundreds of pages books etc I prefer just web link to some more stable site like https://en.wikipedia.org/wiki/Cohen%E2%80%93Sutherland_algorithm |
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Feb 08 07:48AM -0800 W dniu poniedziałek, 8 lutego 2016 15:45:05 UTC+1 użytkownik Reinhardt Behm napisał: > > got names > So you never developed a new algorithm yourself which at that point in time > is nowhere else documented? i dont think so, Sometimes i had written more complex proceduress take for example a code that reads rectangle part of texture and draws it on a screen with zoom and rotation (it is called 'rotozoomer' in demoscene, sometimes i expanded it to use a precomputed 2d-vector texture of distortion before drawing (that made nonlinear distortions like various windowglass artifacts etc) Maybe more such kind things but i wouldnt call it algorithms, it was not so much hard to understand (if some piece was harder it had a name) Overall it is probably not much fortunate to learn some general techniques form source you working on, where they got external world description - it is much more fortunate if a coder knows it from outside than come and see it here he understands it Im not sure if a given code should act as a tutorial |
| Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Feb 08 07:50AM -0800 W dniu poniedziałek, 8 lutego 2016 15:46:50 UTC+1 użytkownik Öö Tiib napisał: > > where you can found it in hundreds of pages books etc > I prefer just web link to some more stable site like > https://en.wikipedia.org/wiki/Cohen%E2%80%93Sutherland_algorithm name is better imo |
| Paul N <gw7rib@aol.com>: Feb 08 12:23PM -0800 On Thursday, February 4, 2016 at 12:43:52 PM UTC, Alf P. Steinbach wrote: > > 3-base calculations there is: "why are we doing it like this? why use > > 3-base numbers here?". > That's because the NIM game with 3 heaps has a simple solution in base 3. Drifting off-topic, but - are you sure about this? NIM (assuming you can only take from one pile at a time) has a simple solution in binary, regardless of the number of piles. It works best for the less-common "last man wins" version but can be easily tweaked for the more common "last-man-loses" version. If you're allowed to take from up to two piles per turn, then base 3 does offer the solution (regardless of the number of piles). But this is much rarer - and it can't easily be tweaked for the "last-man-loses" version, as far as I know. |
| 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