- Pragma once support - 3 Updates
- constexpr issues - 2 Updates
- On-line code generation - 1 Update
| "Öö Tiib" <ootiib@hot.ee>: Dec 03 04:28AM -0800 On Friday, 30 November 2018 23:49:35 UTC+2, Vir Campestris wrote: > > handle it differently. > I can't think of any reasonable case where they would. > (unreasonable? two files with the same guard name??) All we are to certain extent ignorant, naive and fallible. Sometimes we solve something using some unreasonable way that works at first and only later causes complications. The project where I saw several copies of same header was such because it contained lot of different independent optional dll modules that were made by different teams. Sometimes there were copies of same headers made, perhaps for to simplify work with those in separation. |
| scott@slp53.sl.home (Scott Lurndal): Dec 03 02:11PM >I benchmarked this at my last company. >One order, maybe. Two - no. It was scary how long it took opening those >files. Mind, this was on spinning rust. What operating system? Windows file operations are pathetically slow. |
| Vir Campestris <vir.campestris@invalid.invalid>: Dec 03 09:10PM On 03/12/2018 14:11, Scott Lurndal wrote: > What operating system? Windows file operations are pathetically slow. Windows running in a VM! Andy |
| "Öö Tiib" <ootiib@hot.ee>: Dec 03 02:50AM -0800 > or implicitly interpreted to use. > All classes/functions... have to go through such similar examination > procedure against each new feature. It sounds like you try to write classes that do something useful but can't be misused. I also try to make my classes straight to the point for what these are meant but I do not worry about misusage too deeply. If something can be used then it can be also misused. > Another analogy would be like Qt's foreach. Since I don't use foreach, > just can imagine the labor (and the mental struggle) I would take to > upgrade to newer c++ version. You can always avoid making clones of library functions. There is std::foreach since C++98 and there is range based for since C++11. The chances are rather slim that your self-made version wins those. > Multiple inheritance is rare is because of years of experiences and > evolution (something like exception specification). The bottom thing is > class inheritance is not that omni-capable as it used to be believed. I am programmer not politician and so I don't believe in silver bullets. For me inheritance is a feature of some programming languages. A tool like any other. That tool is meant to resolve certain complications with certain kind of objects. Typically the complication manifests itself as long methods/functions with lot of if-else or switch-case chains that handle that kind of objects. That can be fine or can make code hard to follow, test and maintain. The complication itself is infrequent and inheritance is often not the best tool to resolve it. A situation where same group of objects has several and orthogonal such complications is ultra rare. Therefore most usages of multiple inheritance are misuse of the tool. > reasons too much to underestimate the shadow side (tests not done enough). > At least I know 'size bloat' is not a good sign (you might find many > rarely used things appear in compiled files or in executibles instead). I agree that all kind of testing (unit, automated and manual) are often not done enough. The reason is that it is work too. Mature, well tested product means lot of work of highly skilled specialists. That is expensive. If we go extreme, 100%, no defects, then that means we need omnipotent specialists. It is AFAIK impossible so we have to balance our resource usage. |
| wyniijj@gmail.com: Dec 03 07:11AM -0800 Öö Tiib於 2018年12月3日星期一 UTC+8下午6時50分14秒寫道： > can't be misused. I also try to make my classes straight to the point > for what these are meant but I do not worry about misusage too > deeply. If something can be used then it can be also misused. Therefore, my strategy (including from being misused) is keeping the API simple and forcing users to check for errors explicitly (even inside the library, I also check the underlying things for errors if convenient). Most people don't like to check for errors explicitly rather like to see the completed written program terse, beautiful,...,even 'smart'. Objectively to say, we got what we want. For my part, I could work at home writting programs quite mechanically, even mindlessly (not good, though). 99% of bugs reported from clients are not serious and can be identified and fixed in one day. That is the practical reason why I need to check the API against newer c++ features in the 1st place, another reason is pure academic, theoretical. > You can always avoid making clones of library functions. There is > std::foreach since C++98 and there is range based for since C++11. > The chances are rather slim that your self-made version wins those. My mistake, I though Qt4's foreach was invented before c++. The analogy was trying to say that if some new c++ feature or 'keyword' collides with or comes too close to one's existing codes, that would cause headache, e.g. thread, many people should have such experience. > best tool to resolve it. A situation where same group of objects has > several and orthogonal such complications is ultra rare. Therefore > most usages of multiple inheritance are misuse of the tool. I was talking about history. Class inheritance had been believed powerful like crazy, so why not go further, so multiple inheritance it is. > tested product means lot of work of highly skilled specialists. That > is expensive. If we go extreme, 100%, no defects, then that means > we need omnipotent specialists. If you say it is also a work, meaning a pre-determined release is scheduled first, than the problem is the plan, sounds to me. No one can claim 100% correct (including this sentence). The tests I see that could be done are quite simple, just enumerate all usecases(unbiased) as many as possible, laborsome, though. > It is AFAIK impossible so we have > to balance our resource usage. That's the trick. More invention or more tests? |
| "Öö Tiib" <ootiib@hot.ee>: Dec 03 05:28AM -0800 > Why does icc produce such a big bss segment? Those bytes > have to be zeroed out before the program runs. Somehow > icc makes clang look good. Seems that you built for AMD processor. ICC needs to make efficient code for Intel processors and bit crappier variant for AMD processors. ;-) But seriously ... what kilobytes? We are talking about your serializer wannabe written in C++ not about an HDL for a FPGA of some sort. |
| 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