Re: [Boost-users] [heap] Mix use of size_t and size_type
Hi Matthias: I am not really reading d_ary_heap.hpp actually. As my experiences the size_type is used as the parameter in template programming. It's not a confirmed type and it is depended on what you transmit the value of type while you build template function. It could be "int, short, unsigned things even the customized type". It seems to be confirmed during compiling. In another hand, size_t is used "typedef", it is as a definition and will be confirmed during preprocessing. It has could be unsigned int, not always, but often. I hope it is helpful. Cheer~ 程墨 PBI―北京加维通讯电子技术有限公司 地址：北京市海淀区西北旺镇 丰智东路3号院 邮编：100094 Mail: mcheng@pbicn.com
Hi Cheng, Thanks a lot. I'll reread the code with your explanations in mind... -- Matthias
On Wednesday, March 11, 2015 12:09 PM, Cheng Mo wrote:
Looks wrong to me, arithmetic should probably use the same types. And what's going on with std::min?
size_type comes from the allocator, and should be used for sizes and indices (well, that's how the STL seems to use them).
As a typedef, compile time, after the preprocessor.
It has could be unsigned int, not always, but often. I hope it is helpful.
The indices should have the same type, and they should be size_type. The default size_type of allocators in the STL is size_t, so it usually isn't a problem, but for correctness it should be size_type. Ben
On 12/03/2015 01:02, Ben Pope wrote:
Agreed.
And what's going on with std::min?
I'm not sure what D is, but that's a fairly basic "constrain to no later than the end of the array" construct. If you're referring to the parentheses around std::min itself, that's a standard defense against #define min(). You might also see this in some code as "std::min BOOST_PREVENT_MACRO_SUBSTITUTION (...)", which is more obvious but also much uglier.
This is really quite important to avoid difficult-to-diagnose trouble when using Windows, whose code often makes a daft #define for min. So important, that Boost has a tool to check for it called 'Inspect' that reports all sorts of naughtiness, including this. Build the tool inspect.exe by cd to ?:\modular-boost\tools\inspect and running b2 to build inspect.exe Then cd to the top of your code, eg /libs/your_library and run inspect from there (perhaps inspect.exe > my_inspect.html) You will get some spurious complaints, but you can pick out all uses of min() and max() without protective brackets. Should be, for example, (std::numeric_limits<result_type>::min)() Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Thursday, March 12, 2015 05:52 PM, Paul A. Bristow wrote:
I haven't worked with Windows headers for a while, but I always ensured that NOMINMAX or whatever it was, was defined. Of course, that's not entirely useful if you're writing a library. Ben
Doesn't protect your from being named'n'shamed by the Boost Inspect program ;-) http://boost.cowic.de/rc/docs-inspect-develop.html (Not that authors are a bit shameless and not taking as much notice of this as they should - perhaps we need to plop their shameful behaviour into their emailbox?) So the pesky extra brackets are The Right Thing To Do. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
participants (5)
-
Ben Pope -
Cheng Mo -
Gavin Lambert -
Matthias Meulien -
Paul A. Bristow