- Derivation without size increase? - 5 Updates
- Cross-platform C++ GUI Library -- coming soon! - 4 Updates
- February meetings - 4 Updates
- TDD considered harmful - 8 Updates
- Making all getters- return values const? - 4 Updates
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 05 06:08PM +0200 On 5.02.2016 16:43, Marcel Mueller wrote: >> The size of B is not 24 or 25, but 32, because alignment. > You are on a 64 bit platform? > I would have expected 28 otherwise. Doesn't matter, the doubles in A require 8-byte alignment, which 28 is not. > return 0; > } > => 24 #pragma pack(1) does indeed work (with MSVC), but then sizeof(A)==23. This means that when placed in an array, larger members like doubles inside A would be misaligned and cause performance hits. If I put #pragma pack(1) only before B, then sizeof(A)==24 and sizeof(B)==25, which is not better. I could probably derive both A and B from a common sizeof 23 base and add 'char unused;' or something like that to A. Then sizeof(A)==24, but I'm afraid the compiler would still think the required alignment is 1 and would not align the objects in memory properly. Interestingly enough, the other platform which we need to support (gcc on x64 Linux) seems to do the right thing (sizeof(A)==24, sizeof(B)==24), with no pragmas or additional flags needed. Cheers, Paavo |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 05 06:39PM +0200 On 5.02.2016 17:32, Jerry Stuckle wrote: > Exactly how many are "zillions"? Even if you have 1,000,000 of them at > the same time (very doubtful - trying to process that many items would > take a lot of time), you're only talking about 8 MB of additional memory. Yes, it might well be that I am wasting my time on a premature optimization, but I was just curious if using C++ abstractions would indeed somehow work against the zero overhead principle. But as I have now seen that gcc does the right thing without any tricks, I am starting to think this is just a quality of implementation issue. Cheers Paavo |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 05 12:46PM -0500 On 2/5/2016 11:39 AM, Paavo Helde wrote: > I am starting to think this is just a quality of implementation issue. > Cheers > Paavo Like any performance issue, I concern myself with it when it becomes a problem, not before. For instance, in your case, I would be very concerned if this were running on an embedded processor with 512K of RAM. However, if it's running on a machine with 5GB (or even 50MB) of RAM, I'd be less concerned until it became a problem. It may very well be this can cause a problem. If it is, you'll need to fix it. But remember also that the compilers align data for performance reasons, also. It's faster to load/store an integer when it's on a 4 byte boundary in most 32 bit processors, for instance. Compressing your structure may end up slowing the application down. Or, by not using as much memory, you may cause less paging and application performance may improve. You just don't know at this point. Almost every performance issue is a tradeoff somewhere. It's a matter of finding the right tradeoff. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Feb 05 06:00PM +0100 On 05.02.16 17.08, Paavo Helde wrote: >> You are on a 64 bit platform? >> I would have expected 28 otherwise. > Doesn't matter, the doubles in A require 8-byte alignment, which 28 is not. Think, you are a bit too fast. A 32 bit platform never needs 64 bit alignment. > #pragma pack(1) does indeed work (with MSVC), I tested with gcc. > but then sizeof(A)==23. That was the intention of the OP. > This means that when placed in an array, larger members like doubles > inside A would be misaligned and cause performance hits. True. One have to take care about that. > I could probably derive both A and B from a common sizeof 23 base and > add 'char unused;' or something like that to A. No #pragma pack should do the job as well. Hmm, seems only to work if new members are added. class A { union { A_base a; int dummy[(sizeof(A)-1)/sizeof(int)+1]; }; }; ... not that pretty. > Interestingly enough, the other platform which we need to support (gcc > on x64 Linux) seems to do the right thing (sizeof(A)==24, > sizeof(B)==24), with no pragmas or additional flags needed. So probably the optimizer has been enhanced. This is always the problem with optimization. At some point they work against you. [...] It does not work for me without pragma. B grows one machine size word. Neither gcc 4.7.2 @ Debian amd64 nor gcc 4.8.4 @ Mint 17 x86 nor gcc 4.9.2 @ Raspbian ARMv6 nor gcc 3.3.5 @ eCS x86 nor IBM icc 3.08 @ eCS x86. But the above hack works with all of them. Marcel |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 05 08:16PM +0200 On 5.02.2016 19:00, Marcel Mueller wrote: >> not. > Think, you are a bit too fast. > A 32 bit platform never needs 64 bit alignment. Yes, you are right. It seems I have started to forget about 32-bit world only after a few years. > I tested with gcc. >> but then sizeof(A)==23. > That was the intention of the OP. No, not at all. > It does not work for me without pragma. B grows one machine size word. > Neither gcc 4.7.2 @ Debian amd64 nor gcc 4.8.4 @ Mint 17 x86 nor gcc > 4.9.2 @ Raspbian ARMv6 nor gcc 3.3.5 @ eCS x86 nor IBM icc 3.08 @ eCS x86. For any case, I tried with an example which resembles my real code more exactly: ~>cat main.cpp #include <iostream> #include <stdint.h> #include <string> class X; class A { union xunion { int64_t k; double f; const void *p; struct Extra { std::string* s; X* x; } x; char buf[16]; } x; struct { char buf_continued[6]; } y; char tag; }; class B: A { char anotherTag; public: // ... }; int main() { std::cout << "sizeof(A)==" << sizeof(A) << "\nsizeof(B)==" << sizeof(B) << "\n"; return 0; } ~>g++ -Wall main.cpp ~>./a.out sizeof(A)==24 sizeof(B)==24 ~>g++ -v ... gcc version 4.6.2 (SUSE Linux) Maybe they have abandoned this optimization in later versions... MSVC produces 24 and 32 for this code, or 23 and 24 with #pragma pack(1). |
| Lynn McGuire <lmc@winsim.com>: Feb 04 04:22PM -0600 On 2/4/2016 2:15 PM, Mr Flibble wrote: > http://neogfx.org > https://github.com/FlibbleMr/neogfx > /Flibble Will it have X% of the functionality of wxWidgets? https://www.wxwidgets.org/ And a Mac / HTML version? Lynn |
| Lynn McGuire <lmc@winsim.com>: Feb 04 04:54PM -0600 On 2/4/2016 2:15 PM, Mr Flibble wrote: > http://neogfx.org > https://github.com/FlibbleMr/neogfx > /Flibble Neat! SDL is an open source cross platform hardware library: http://www.libsdl.org/ Lynn |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 05 12:09AM On 04/02/2016 22:22, Lynn McGuire wrote: >> /Flibble > Will it have X% of the functionality of wxWidgets? > https://www.wxwidgets.org/ I have never researched wxWidgets in any detail mainly because it appears to be an MFC rip off. > And a Mac / HTML version? HTML version? I may do a Kickstarter for a Mac version (mainly to fund me buying some Apple hardware). /Flibble |
| scott@slp53.sl.home (Scott Lurndal): Feb 05 02:24PM >http://neogfx.org >https://github.com/FlibbleMr/neogfx >/Flibble How is it better than the platform independent proposal for C++14? https://github.com/mikebmcl/N3888_RefImpl/blob/master/README.md If you need 3D, wouldn't it be better to extend N3888 instead of creating a new library? |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 04 01:58PM -0500 On 2/4/2016 12:32 PM, Richard wrote: > I can do that too. > The Utah group has met every month for it's entire existence. > Therefore, the list is flawless. Nope, just one of several examples of user groups which no longer exist - and haven't, for quite a while. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 04 03:35PM -0500 > section and mention that they may no longer be > meeting. Besides Washington, DC what others do you > think are no longer meeting? Sacramento, for one. I'm sure if you're interested you can find others. > Brian > Ebenezer Enterprises > http://webEbenezer.net That's nice. But the only thing worse than no list is an incorrect list. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Geoff <geoff@invalid.invalid>: Feb 04 05:39PM -0800 >section and mention that they may no longer be >meeting. Besides Washington, DC what others do you >think are no longer meeting? You would be well advised to follow the links for those groups on that web link you posted. The D.C. Meetups link is a dead link to the root page of the Meetups site. If the group organizers can't be bothered to keep their calendars updated I' say it's not worth listing anywhere. |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 05 10:16AM -0500 On 2/4/2016 8:39 PM, Geoff wrote: > web link you posted. The D.C. Meetups link is a dead link to the root > page of the Meetups site. If the group organizers can't be bothered to > keep their calendars updated I' say it's not worth listing anywhere. Geoff, it's not that they don't keep their calendars updated. They stopped meeting at least two years ago. There's no calendar to update. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| 4ndre4 <4ndre4@4ndre4.com.invalid>: Jan 31 06:55PM On 31/01/2016 03:42, Mr Flibble wrote: [...] > TDD > wants lots of testable small (atomic) public methods to test but every > public method you add actually REDUCES the encapsulation of a class No, it doesn't. Sorry, but you haven't understood what TDD is. The fact that you can test each individual electronic component available on the market in isolation, does not mean that you are esposing any details about the interaction between those components, on any electronic board you can build with them. Remember that there are languages (such as Python, JavaScript, etc..) where there is no concept of "private method". Private methods are just a convention. -- 4ndre4 "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." (E. Dijkstra) |
| Ian Collins <ian-news@hotmail.com>: Feb 01 11:03AM +1300 Mr Flibble wrote: > wants lots of testable small (atomic) public methods to test but every > public method you add actually REDUCES the encapsulation of a class > whilst adding a private method does not sausages. Er no, TDD doesn't want anything of the sort. Being a process, TDD doesn't actually "want" anything at all except for tested, working code... If you understood the process, you would know that there isn't any conflict between TDD and encapsulation. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Jan 31 09:48PM -0500 On 1/31/2016 6:45 PM, Mr Flibble wrote: > You obviously don't understand TDD then and its mantra of designing > upward from failing tests. Private methods are totally at odds with TDD. > /Flibble Oh, I understand it. And private methods have absolutely nothing to do with TDD. TDD deals with the external (public methods) interface of the class. The internal (private methods) of the class are immaterial. In fact, the private methods can change, be added or deleted without changing the public interface - which is what TDD cares about. How something is done - the implementation (which includes private methods) is immaterial. What is material is the results. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Feb 01 02:13PM +1300 Mr Flibble wrote: > Except if you use TDD you don't end up with sausages you end up with > meatballs. TDD is anathema to best (SOLID) practices related to the > design of non-trivial software systems. Restating the same empty nonsense won't make it any more correct. There aren't any conflicts between TDD and SOLID practices. SOLID practices help make TDD better. If I recall correctly, SOLID was originally coined by Robert Martin (Uncle Bob) (possibly here: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod). You may be surprised to know that he is also a strong advocate of TDD: https://blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html Go figure. -- Ian Collins |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 02 01:25PM On Tue, 2016-02-02, Zaphod Beeblebrox wrote: > compiler enforces that check. But anyone wants to change the > contract, can do that, so it's not different than just a syntactic > convention. That's a funny way of looking at it ... anyone can edit any program to say what they want; that doesn't mean private: is just a convention. However: > Python/JavaScript, you are telling the client programmer that they > are not supposed to call that method directly. It's a way to define > a contract. Same thing as access specifiers. I disagree with your wording, but I agree with your point. IME, the conventions in Python are almost as good as private: in C++, if you stick strictly to the conventions (which I think people generally do). (The difference is in Python I have to trust the users of my class not to be stupid, or perhaps run a linting tool. In C++ I can pretty much look at a class and tell that noone is messing with the privates, because it would be not only stupid but remarkably stupid for them to do so.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Cholo Lennon <chololennon@hotmail.com>: Feb 02 04:03PM -0300 On 02/02/2016 02:02 PM, Zaphod Beeblebrox wrote: > so, but maybe you're right. > TDD is an iterative process where you must find the solution > through that iteration. Defining testable interfaces is just a consequence. > HAVE to define testable interfaces. The iteration you are talking > about is just the red-green-refactor process, which is at the > foundation of TDD. AFAIK (in my own experience) the interface is constantly mutating due to the nature of the (TDD) process, so is not important its definition at the beginning. The interface will eventually converge to its final form after several iterations. > been tested individually. The way you assemble them forms the specific > "behaviour" you want to implement. You're not breaking the encapsulation > of your own circuit, assembling those components in a specific way. The analogy with electronic circuits is not always true: The problem here is that sometimes (more often than you might expect) you don't have the "internal" components of a class: ie. a real database, a timer, etc. You have to mock them in order to simulate the real use of your class. And, if you need to change the internal components,then you have to break the encapsulation using for example injection of dependencies. Just to clarify my position: I am not defending TDD, I am just trying to explain what it really is (in another post I wrote my ideas about TDD) Regards -- Cholo Lennon Bs.As. ARG |
| Ian Collins <ian-news@hotmail.com>: Feb 10 04:02PM +1300 Jerry Stuckle wrote: >> for military avionics. > So you checked every single NAND gate, NOR gate, and inverter on your > chip? Individually? Blimey, this is going back over 30 years (and it wasn't my chip! (and much beer has passed through my brain since then)).... So what I can remember is everything with state (flip-flops) was tested in the chain. Imagine something like an octal tri-state latch (say a 74574 for the oldies) where test mode connected the 8 latches in series. So I guess the analogy with unit tests something like: line of code -> gate/inverter function -> flip-flop test suite -> scan test. So the scan test tests the flip-flops which verifies the gates. So yes, any duff gate would cause the test to fail. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Feb 09 10:15PM -0500 On 2/9/2016 10:02 PM, Ian Collins wrote: > So what I can remember is everything with state (flip-flops) was tested > in the chain. Imagine something like an octal tri-state latch (say a > 74574 for the oldies) where test mode connected the 8 latches in series. But you claimed every GATE was tested. What's the real answer? > test suite -> scan test. > So the scan test tests the flip-flops which verifies the gates. So yes, > any duff gate would cause the test to fail. Ah, so you didn't test every gate - despite your earlier claims. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| JiiPee <no@notvalid.com>: Feb 04 04:57PM I was reading Sutters book where he adviced how to create a perfect class. In one place he said that here: class Human { public: string getName() const { return m_name; } private: string m_name; }; it should be: const string getName() const { return m_name; } instead so that the user cannot by accident try to set the temporary variable like: Human a; a.getName() = "Peter"; So preventing this kind of "error" use. I kind of agree, but do you people also think that all getters should be done like this (if they return an temporary object)? I do not see class makers doing this consistently. |
| Victor Bazarov <v.bazarov@comcast.invalid>: Feb 04 05:45PM -0500 On 2/4/2016 11:57 AM, JiiPee wrote: > }; > it should be: > const string getName() const { return m_name; } Are you sure you didn't miss the reference indicator, like const string& getName() const { return m_name; } ? > people also think that all getters should be done like this (if they > return an temporary object)? > I do not see class makers doing this consistently. There is very little sense in qualifying the return value type. Code like a.getName() = "Peter"; needs to be caught in a code review and either clarified with a comment or removed. V -- I do not respond to top-posted replies, please don't ask |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 05 12:53AM +0100 On 2/4/2016 5:57 PM, JiiPee wrote: > }; > it should be: > const string getName() const { return m_name; } Like Victor, I suspect that you've inadvertently omitted an "&" here. But maybe not, it depends when this was written. Anyway, the "get" prefix is negative value verbiage in C++, I'm surprised Herb used it. > So preventing this kind of "error" use. I kind of agree, but do you > people also think that all getters should be done like this (if they > return an temporary object)? This was once recommended by Scott Meyers. Then came move semantics, and Andrei Alexandrescu declared that advice dead (actually, as I recall, that was /before/ C++11, just with Andrei's own C++03-compatible move semantics scheme called Mojo). There was a slightly memorable quote that I don't recall, but anyway, if you make the return value `const` then it can't be efficiently moved from, so that's ungood. > I do not see class makers doing this consistently. For modern coding it would be a sign of UNREASONED coding, actively doing additional needless and generally negative value things because one has seen it somewhere, associated with some measure of authority, without understanding it or reasoning about it. But before C++11 it could be good practice. Cheers & hth., - Alf |
| JiiPee <no@notvalid.com>: Feb 05 01:50AM On 04/02/2016 23:53, Alf P. Steinbach wrote: >> it should be: >> const string getName() const { return m_name; } > Like Victor, I suspect that you've inadvertently omitted an "&" here. ok, my example was not the best, but there is a better example in my Victors asnwer. > But maybe not, it depends when this was written. > Anyway, the "get" prefix is negative value verbiage in C++, I'm > surprised Herb used it. its mine.... > slightly memorable quote that I don't recall, but anyway, if you make > the return value `const` then it can't be efficiently moved from, so > that's ungood. ok, so not been able to move is worse than a danger that somebody does: a.getName() = "Peter"; |
| 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