- Unit testing (Re: Putting project code in many different files) - 8 Updates
- Minecraft - 10 Updates
- Let's talk about multiple inheritance and interfaces. - 4 Updates
- Let's talk about multiple inheritance and interfaces. - 1 Update
- enum class, auto - 2 Updates
| 4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 30 11:21AM On 28/01/2016 23:34, Jerry Stuckle wrote: [...] >Once that class passes, it > can be used in testing other classes. What do you mean? > In fact, you may not even have A when you're testing B. If you place > them in the same file, once you finish with A, you need to go back and > test B again, because it's file has changed. What?! -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 30 02:12PM On Fri, 2016-01-29, 4ndre4 wrote: > On 28/01/2016 22:22, Jorgen Grahn wrote: > [...] >> I still would like to see "4ndre4"'s argument, too. For reference, the claim was simply ...also, don't forget that for unit testing reasons, having one class per file is a convenient solution. > class per file. Normally, if I have my Validator class in my > Validator.h/.cpp, I want my ValidatorTest.h/.cpp and that covers ONLY > the functionality in my Validator class. Ok, so it's convenient because it's 1+1+1: three things that belong together instead of just a pair. I agree -- for most cases. But sometimes (let's say 5%) some other consideration makes following the convention suboptimal. [Philosophy alert] I seem to be more willing to make exceptions than many programmers (or perhaps more explicit about it). To me, a convention needs to be broken as soon as it's not a good fit. That, to me, actually makes the convention /more/ useful, because when you see it, you know it's fitting. Or you could say that I want the edge cases to stand out, not masquerade as normal cases. All that is also related to the quote "a foolish consistency is the hobgoblin of little minds" -- except I wish Ralph Waldo Emerson had phrased it in a less insulting way. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: Jan 30 08:23AM -0800 On Friday, 29 January 2016 12:02:49 UTC+2, JiiPee wrote: > all classes you create? or several namespaces? I have not used > namespaces so much, but obviously for one library I used one > namespace.... but how about for the project? I like every class to be in some named namespace. I like different namespace for each module. Sometimes I will have nested namespaces when there are sub-modules. |
| 4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 30 05:49PM On 30/01/2016 14:12, Jorgen Grahn wrote: [...] > I agree -- for most cases. But sometimes (let's say 5%) some other > consideration makes following the convention suboptimal. Such as? -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra) |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 30 01:09PM -0500 On 1/30/2016 6:21 AM, 4ndre4 wrote: >> Once that class passes, it >> can be used in testing other classes. > What do you mean? Once you have tested B and are sure it works, you can use it in other tests. For instance, if A is derived from B or has B as a member, before you can thoroughly test A you have to ensure B works. >> them in the same file, once you finish with A, you need to go back and >> test B again, because it's file has changed. > What?! Yes. Good quality control dictates that any time a file is changed, tests on everything in that file must be repeated. Someone may say they didn't change B, and they may not have - intentionally, at least. But you don't know for sure without testing, and not testing is how bugs sneak into "working code". -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| 4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 30 06:16PM On 30/01/2016 18:09, Jerry Stuckle wrote: [...] > Once you have tested B and are sure it works, you can use it in other > tests. For instance, if A is derived from B or has B as a member, > before you can thoroughly test A you have to ensure B works. No, it doesn't matter. The order you run the tests does not really matter on classes. And you don't strictly "use" other classes in unit tests. Collaborations between classes should be mocked. The tests for class B can run independently from those for class A, even though A inherits from B. > Yes. Good quality control dictates that any time a file is changed, > tests on everything in that file must be repeated. Why should Something.cpp be ever changed or even touched, if I am running the tests contained in SomethingTest.cpp? -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra) |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 30 09:01PM +0200 On 30.01.2016 20:09, Jerry Stuckle wrote: > Once you have tested B and are sure it works, you can use it in other > tests. For instance, if A is derived from B or has B as a member, > before you can thoroughly test A you have to ensure B works. I think this holds more at the development stage (and assuming B is not mocked), not at the later stage when hidden bugs get revealed by any reason. And this does not contradict putting other classes in the same file in any way. >>> In fact, you may not even have A when you're testing B. If you place >>> them in the same file, once you finish with A, you need to go back and >>> test B again, because it's file has changed. But of course. All the unit tests run anyway automatically each time when anything changes in the repository. So there is no problem with testing B again, this will be done uncountable times. Cheers Paavo |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 30 05:28PM -0500 On 1/30/2016 1:16 PM, 4ndre4 wrote: > tests. Collaborations between classes should be mocked. The tests for > class B can run independently from those for class A, even though A > inherits from B. It does matter, and it's not at all unusual for a class to have other classes as members. You start out testing single classes. Then you can test classes which include the first class. And you can run the tests for class B independent of class A - but since A is derived from B, you can't test A without knowing B is working. >> tests on everything in that file must be repeated. > Why should Something.cpp be ever changed or even touched, if I am > running the tests contained in SomethingTest.cpp? Please read the thread. We are talking about when there are multiple classes in one file. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Lynn McGuire <lmc@winsim.com>: Jan 29 08:20PM -0600 On 1/29/2016 1:40 PM, Ian Collins wrote: >> I wonder what happened to the proposal since it was proposed in Jan of 2014? >> I suspect that the compiler writers are squashing this as much as possible as it would be a large addition to the compilers. > Would it? I don't see anything there tat would require language support. It would be a new library. Don't all of the compiler vendors supply their own versions of the standard libraries? Lynn |
| Ian Collins <ian-news@hotmail.com>: Jan 30 04:53PM +1300 Lynn McGuire wrote: >>> I suspect that the compiler writers are squashing this as much as possible as it would be a large addition to the compilers. >> Would it? I don't see anything there tat would require language support. It would be a new library. > Don't all of the compiler vendors supply their own versions of the standard libraries? Not all, no. The two I use day to day both use the GNU standard library. -- Ian Collins |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 30 08:04AM On Sat, 2016-01-30, Ian Collins wrote: >>>>> an essentially cleaned up version of Cairo to the standard >>>>> library. >>>>> <url: https://isocpp.org/blog/2014/01/n3888> ... >> Don't all of the compiler vendors supply their own versions of the >> standard libraries? > Not all, no. The two I use day to day both use the GNU standard library. And besides it would be easy to say "we ship all of the standard library minus the GUI stuff". Then some other group could provide that part separately. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| bartekltg <bartekltg@gmail.com>: Jan 30 10:54AM +0100 On 28.01.2016 23:35, Öö Tiib wrote: > As far I know the C++ standards committee does not like to specify > language or library subsets and prefers the implementations to implement > the whole language. Do you use threads, dynamic memory and heavy foating point random number generators on tiny microcontrollers? No, you do not. But these still are included in the standard. Also, the standard prefers U2 as integer number implementation;-) bartekltg |
| "Öö Tiib" <ootiib@hot.ee>: Jan 30 08:17AM -0800 On Saturday, 30 January 2016 11:55:13 UTC+2, bartekltg wrote: > > the whole language. > Do you use threads, dynamic memory and heavy foating point random > number generators on tiny microcontrollers? I indeed do use threads and dynamic allocations. The <random> in C++ is relatively lightweight but I don't need it typically. > No, you do not. But these still are included in the standard. What you mean? Over 70% of things that can run software sold today are MCU, so someone got to program these buggers and that is fairly frequent need. The typical MCU that are used now are way more powerful than the computers that I did learn to program on decades ago, are dirt cheap and take next to no power. See http://www.eetimes.com/document.asp?doc_id=1322014&print=yes Majority of market is WiFi, then Bluetooth. In most of programs I don't use most of standard library since I do not need it for resolving particular problem. I may need them in next. However graphics as such does not make sense whatsoever about most MCU so it should be separate library not standard C++ library. > Also, the standard prefers U2 as integer number implementation;-) I failed to decipher what you mean. U2? Bono, Edge, Adam, Larry? |
| David Brown <david.brown@hesbynett.no>: Jan 30 05:53PM +0100 On 30/01/16 03:20, Lynn McGuire wrote: >> support. It would be a new library. > Don't all of the compiler vendors supply their own versions of the > standard libraries? Most compiler /developers/ don't make libraries. The phrase "compiler /vendor/" implies someone that /sells/ compilers, and usually when a compiler is sold for money it comes along with assemblers, linkers, libraries, IDE, debugger, etc. But the people actually /writing/ compilers frequently don't make the libraries (or anything else), except "compiler support libraries" for things like software floating point support. Even when a single company makes, packages and distributes a complete toolchain, the compiler and library teams are normally separate (but with close cooperation, of course). For the clearest example, the gcc development team don't make the assembler or linker for any target platforms, and they don't make a standard library. People use a wide range of standard libraries with the same versions of the compiler, because they are looking for a range of different features in the libraries (some people want small libraries, some what fully-featured libraries, some want OS-specific libraries, etc.) |
| David Brown <david.brown@hesbynett.no>: Jan 30 07:36PM +0100 On 30/01/16 17:17, 嘱 Tiib wrote: > take next to no power. > See http://www.eetimes.com/document.asp?doc_id=1322014&print=yes > Majority of market is WiFi, then Bluetooth. Point of fact - the majority of MCUs do /not/ have WiFi or anything of the sort. It is believable that of the people who responded to that survey, that about 50% said that when they used some sort of wireless communication on a project, it included WiFi. But that's all. Similarly, reading that page quickly gives the impression that 17% of embedded systems run Android, when in reality microcontrollers that are not powerful enough to run Android outsell ones that are by a factor of something like 10,000 to 1. However, it is certainly true that a typical modern MCU is more powerful than those of only a few years ago, and 32-bit systems (especially Cortex M) are very much on the increase. This makes it a lot more realistic to use "big system" features of C++ in a wider range of embedded systems. > not need it for resolving particular problem. I may need them in > next. However graphics as such does not make sense whatsoever about > most MCU so it should be separate library not standard C++ library. At least it should be optional, rather than required. And certainly the sort of graphics needed in embedded systems covers a wide range - from no visible interface, through simple screens or LEDs, then small graphics screens with very limited features, to full computer-like screens. There is no standard in what hardware is available, and no standard in the type of software features needed. >> Also, the standard prefers U2 as integer number implementation;-) > I failed to decipher what you mean. U2? Bono, Edge, Adam, Larry? I've no idea either. |
| Bo Persson <bop@gmb.dk>: Jan 30 07:52PM +0100 On 2016-01-30 19:36, David Brown wrote: > graphics screens with very limited features, to full computer-like > screens. There is no standard in what hardware is available, and no > standard in the type of software features needed. The standards committee really doesn't like optional parts of the standard. That creates dialects. Once upon a time, the Cobol standards committee released a standard with 12 optional packages. Sorting, report writer, etc. Not until later did they discover that they had instantly created 4096 different languages, all 100% standards compliant. We don't want to repeat that. Bo Persson |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 30 10:32PM +0100 On 1/30/2016 7:52 PM, Bo Persson wrote: > they discover that they had instantly created 4096 different languages, > all 100% standards compliant. > We don't want to repeat that. Oh, it's already happened, and more is on the way. Already happened: e.g. support for converting function pointer to `void*` and vice versa, is optional, since C++11. More is on the way: e.g. support for wide character string constructors for file system library in C++17. Cheers, & gulp!, - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 30 10:34PM +0100 On 1/30/2016 10:32 PM, Alf P. Steinbach wrote: > Already happened: e.g. support for converting function pointer to > `void*` and vice versa, is optional, since C++11. > More is on the way: e.g. support for wide character string constructors ^^^^^^ for ... stream constructors with wide character filenames |
| "Öö Tiib" <ootiib@hot.ee>: Jan 30 07:10AM -0800 On Friday, 29 January 2016 15:51:26 UTC+2, Zaphod Beeblebrox wrote: > [...] > > Oh it does. It leaks 3 stateless objects. > What do you mean? What word don't you understand? "3", "objects", "stateless" "leaks"? |
| 4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 30 05:52PM On 30/01/2016 15:10, Öö Tiib wrote: [... > What word don't you understand? "3", "objects", "stateless" "leaks"? I think it would be much more productive (for everyone) if, rather than using a polemic tone in each message, people explained what they mean pacifically. If you mean that my code "leaks" 3 objects because it does not deallocate them, then nobody really cares. It's just an example to show how virtual inheritance works. -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra) |
| 4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 30 07:06PM On 30/01/2016 18:45, Stefan Ram wrote: [...] > We do care about proper lifetime control in this newsgroup Oh please, don't be ridiculous. You care about polemicising about futile details all the time in this ng. That example was not about the usage of pointers, it was about virtual inheritance. Last reply from me. -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra) |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 30 09:13PM +0200 On 30.01.2016 19:52, 4ndre4 wrote: > pacifically. If you mean that my code "leaks" 3 objects because it does > not deallocate them, then nobody really cares. It's just an example to > show how virtual inheritance works. Yes, this is an example what some newbie may find in a google search and reuse in his project, claiming that using raw pointers is OK because the gurus in c.l.c++ do it as well. But you are right, it was not important for the actually discussed topic, so it should not bother you if Öö Tiib and Zaphod Beeblebrox want to discuss this in more detail or not. Cheers Paavo |
| ram@zedat.fu-berlin.de (Stefan Ram): Jan 30 06:45PM >pacifically. If you mean that my code "leaks" 3 objects because it does >not deallocate them, then nobody really cares. It's just an example to >show how virtual inheritance works. We do care about proper lifetime control in this newsgroup and usually use smart pointers instead of raw pointers, even if it is a small example, because we believe that someone who can't even get a small example right can't write production code. However, in the code posted, the objects created with new /are/ deallocated at the end of main because the lifetime of dynamic storage does not exceed the lifetime of the whole program (couldn't find this in the norm, so I made it up). So, there is no leak. |
| Dombo <dombo@disposable.invalid>: Jan 30 12:38AM +0100 Op 24-Jan-16 om 20:26 schreef David Brown: > a mistake in my coding that happens to involve a macro", as far as I > can see. It is not fundamentally different from any other kind of > mistake. You are assuming here that *all* the code is written by *you*, which may be the case on small embedded systems but is rarely the case with large scale projects which typically involve thousands of header files from many parties. Chances are that someone somewhere added a macro with unintended side-effects. One "nice" example is the definition of a max() macro (IIRC this was in one of the Windows header files). > What I /don't/ see is the idea that macros are so specially bad that > it is appropriate to disrupt the flow of the code and make them > stand out above all other identifiers. Though any language feature can be abused, my experience is that macros are much more likely to introduce unintended effects than other language constructs. Other language constructs tend to have more easily predicable effects, not in the last part because their scope is limited, and much better diagnostics in case you do get it wrong. The problem with preprocessor macros is that it is bolted on to the C and C++ languages rather than being an integral part of those languages. On the system I learned C programming the preprocessor was actually a separate program. You first had put your C file through the preprocessor, after that you had feed the output of the preprocessor to the C compiler which was another program. Past 3 years I've done most of my programming in languages that don't support a C style preprocessor. Frankly I haven't missed digging through piles of header files to figure out how some "clever" macro expands and why it causes problems. > If these folks /need/ to use all-caps names for macros, then they are > doing something wrong. > Namespace collisions happen. It's almost inevitable. Actually my experience is that namespace collisions are very rare since the use of namespaces has become common in C++. I can't think of a case where I had to deal with a namespace collision in over more than a decade, with the exception of macros redefining identifiers. > common names for anything in a wider scope than necessary. This > applies to macros, but it also applies to global functions, types, > enumerators, etc., just as much. For those there are namespaces, unfortunately macros totally ignore those. > encourages the belief (not followed by everyone here) that macros are > someone dangerous and scary, and need to stand out so that they can > be treated with special care. As long as macros do not adhere to the normal scoping rules, have the ability to redefine just about anything and don't behave like the rest of the language, they do need to be treated with special care. Besides C, C++ and assembly languages there aren't many modern programming languages that have a C like preprocessor. Also the C++ language itself gets more and more language features that reduce the necessity to resort to preprocessor macros. I guess there is a reason for that. |
| David Brown <david.brown@hesbynett.no>: Jan 30 05:45PM +0100 On 30/01/16 00:38, Dombo wrote: > unintended side-effects. One "nice" example is the definition of a max() > macro (IIRC this was in one of the Windows header > files). Certainly my viewpoint is biased towards my own work, which is mostly small embedded systems. And certainly I am talking about what /I/ write - I can't change the naming style of other people's code! My argument is not in favour of writing macros with names like "max" (at least not in general - of course these names could be fine in a small self-contained program, and one can be much freer within a source file than in a header file). My argument is merely that you should pick appropriate names for macros based on their usage and avoiding unwanted naming conflicts - you should /not/ pick a style based on "it's a macro, and macros are evil". The reason you don't name a macro "max" in a common header is basically the same as the reason you don't name a global function "max" in that common header. That macro is somewhat worse - no arguments there - but the principle is the same. > support a C style preprocessor. Frankly I haven't missed digging > through piles of header files to figure out how some "clever" macro > expands and why it causes problems. I agree entirely with what you say here. One of the most important benefits of C99 over older C90 is that "static inline" and "static const" have greatly reduced the /need/ of macros. The same applies to C++ over C, and C++11 over C++03, and C++14 over C++11. But the reason to use "constexpr" or templates instead of old macros is /not/ that macros are "evil", but that these solutions are /better/. And when you still need to use a macro for a particular purpose, you should name it in the same way you name everything - in a way appropriate to its usage and its interplay with the rest of the code. You should not name it in shouting all-caps that disrupts the code and stands out from everything else, simply because it happens to be a macro. |
| 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