- Minecraft - 4 Updates
- Unit testing (Re: Putting project code in many different files) - 8 Updates
- Let's talk about multiple inheritance and interfaces. - 1 Update
- Minecraft - 1 Update
| Lynn McGuire <lmc@winsim.com>: Jan 29 12:43PM -0600 On 1/28/2016 3:47 PM, Alf P. Steinbach wrote: > and is sufficient for something non-trivial. > Cheers & hth., > - Alf 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. Lynn |
| Ian Collins <ian-news@hotmail.com>: Jan 30 08:40AM +1300 Lynn McGuire wrote: >> - Alf > 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. -- Ian Collins |
| scott@slp53.sl.home (Scott Lurndal): Jan 29 08:51PM >> 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. Which needs to be distributed as part of the compiler suite. So, additional testing and development resources would be required by the compiler vendor (along with domain-specific knowledge vis-a-vis Cairo and the underlying graphics subsystems on all target operating systems). |
| "Chris M. Thomasson" <nospam@nospam.nospam>: Jan 29 02:36PM -0800 > One can write Minecraft in Java. > One can't write it in C++, except when one would use > non-standard libraries. If I had to write a Minecraft game I would use OpenGL. It works very nicely with C/C++. It would be nice if OpenGL was part of a "standard" graphics library. But, I do not mind using it as a third party non-standard lib. I just bust out the Glew library, and modern OpenGL works fine. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 28 06:34PM -0500 On 1/28/2016 5:34 PM, Jorgen Grahn wrote: > what people in general mean by "unit testing". I still don't see > a consensus. > /Jorgen Unit testing is testing small pieces of the code. For OO, as an example, a unit test may be a single class. Once that class passes, it can be used in testing other classes. So in your example, first you would test B by itself. Then you would test A. 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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| JiiPee <no@notvalid.com>: Jan 29 12:51AM On 28/01/2016 20:01, Jorgen Grahn wrote: > siblings, perhaps they need the same helper functions which noone else > needs, perhaps they will change together ... then I'll probably put > them in one .h file and one .cc file. good point |
| JiiPee <no@notvalid.com>: Jan 29 12:52AM On 28/01/2016 19:15, 4ndre4 wrote: > folders, grouped by functionality. Concurrency also leads to less > conflicts/dependencies between developers, if the code is more > fragmented. ok. I also thought that having a lot of files is not so much a problem, although have not much experience in it. I guess its just a matter of naming the files well. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 28 11:32PM -0800 On Friday, 29 January 2016 02:53:06 UTC+2, JiiPee wrote: > ok. I also thought that having a lot of files is not so much a problem, > although have not much experience in it. I guess its just a matter of > naming the files well. We typically name the folders by namespace and files by class that the file implements (or declares on case of .h file). If we rename the class then we rename the file as well. |
| Ian Collins <ian-news@hotmail.com>: Jan 29 10:47PM +1300 Jorgen Grahn wrote: > If that sounds like a naive question, it's because I'm very unsure > what people in general mean by "unit testing". I still don't see > a consensus. The term is rather vague, although in C++ a class is a good candidate for a unit. I think the case is clearer for encapsulation than it is for inheritance. I will always mock an encapsulate class, with inheritance I will mock the base class if it is in another project or library otherwise I tend to be slack. Most of my code has five files for each class: the header and definition, the test header and definition and an interface definition used to build a mock of the class. Whether a base/encapsulated class class has been tested is irrelevant, you still need a mock object to simulate error conditions. -- Ian Collins |
| JiiPee <no@notvalid.com>: Jan 29 10:02AM On 29/01/2016 07:32, Öö Tiib wrote: > We typically name the folders by namespace and files by class that > the file implements (or declares on case of .h file). If we rename > the class then we rename the file as well. yes the class name is obvious. Do you normally have only one namespace for the project which you use to 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? |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Jan 29 04:22AM -0800 On Thursday, 28 January 2016 20:41:11 UTC, Jorgen Grahn wrote: [...] Cause, if my file is Parser.cpp, I want to have a ParserTest.cpp that covers ONLY the unit tests for Parser.cpp and nothing else. I think it's convenient to follow a simple convention: one class per file, either source or test. |
| 4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 29 06:06PM On 28/01/2016 22:22, Jorgen Grahn wrote: [...] > I still would like to see "4ndre4"'s argument, too. It's a matter of conventions. I said it's convenient, because the convention I follow is to have one class per file and therefore one test 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. As for the word "unit", it is true that the term is vague. Most of the times, a "unit" is a single method. -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra) |
| Zaphod Beeblebrox <a.laforgia@gmail.com>: Jan 29 05:50AM -0800 On Thursday, 28 January 2016 22:53:55 UTC, Öö Tiib wrote: [...] > Oh it does. It leaks 3 stateless objects. What do you mean? |
| ram@zedat.fu-berlin.de (Stefan Ram): Jan 29 04:15AM >>You are just illustrating my argument that C++ needs a standard graphics (2D and 3D) library and a standard user interface toolkit. >That has to be separate standard since "graphics" means few LEDs >for lot of devices where C++ runs. You are just illustrating my argument from 13 years ago: http://www.purl.org/stefan_ram/pub/c++_standard_extensions_en . |
| 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