From -5414900666710997382 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc772,10e355266b6fd117,start X-Google-Attributes: gidfc772,public X-Google-Thread: f78e5,10e355266b6fd117,start X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2002-05-24 16:12:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!denver-snf1.gtei.net!news.gtei.net!namche.sun.com!news2me.EBay.Sun.COM!engnews1.eng.sun.com!taumet!clamage From: Attila Feher Newsgroups: comp.std.c++,comp.lang.c++.moderated Subject: A humble attempt to suggest alignment support for C++ Date: 24 May 2002 23:08:50 GMT Organization: Oy L M Ericsson Ab Lines: 162 Approved: stephen.clamage@sun.com (comp.std.c++) Message-ID: <3CEA1A08.C6D95CC7@lmf.ericsson.se> NNTP-Posting-Host: taumet.eng.sun.com X-NNTP-Posting-Host: netlab.cs.rpi.edu X-Original-Date: Tue, 21 May 2002 12:57:28 +0300 X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAPOz570HMCo9UcraBAQEQXwH9HZ/DHNzKz7OADd3/36V93NHMrtFqFXeO Zu8kZr+q4OAHgfpIBjPse2y/uK9TaW4LsCpOKsLWXmCNc0EGbgmfyg== =ORFR X-Approved-For-Group: kanze@gabi-soft.de comp.lang.c++.moderated X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Content-Length: 5617 X-Status: $$$$ X-UID: 0000000001 Originator: clamage@taumet Xref: archiver1.google.com comp.std.c++:11508 comp.lang.c++.moderated:43842 Cross posted to comp.lang.c++.moderated, because I hope that there will be a fruitful discussion about how to do this best. This is my proposal, which may serve as a starting point for the discussion. Please let me know what do you think about it! Suggestion for new aligment language features for C++ ===================================================== Motto: ------ Dynamic memory allocation is expensive. To pay for it, just to get right alignment is silly. Motivation: ----------- C++ programmers many times face the issue of being able to create fixed capacity, dynamic sized sequential containers. Right now, with current language features such a container can only be implemented using dynamic memory allocation, like vector. But in many cases, such an allocation is an overkill. Boost provides an array template, but that is mostly suitable for free-to-construct or cheap-to-construct elements, since it is a fixed size (and capacity) container. Therefore users of it pay for default construction of all elements of the array, or (in case of curly initialization) default construction of the unused elements. In addition to that the unused elements will be (unneededly) destroyed as well. Boost array is very good for built-in types, but shows its weaknesses (it is an aggregate) when non-C types are involved. Solution #1: ------------ This solution is more work for the users of the language, the way to solve the problem is not so elegant, but it is probably easy to implement. Two additions to the language are required here: 1.) max_align(T) compile time operator(?) 2.) T *std::align( void *ptr[, std::size_t size]) runtime function The max_align works like sizeof. It gives the maximum "alignment loss" in bytes one can get with the type T. So if type T needs to be aligned on 8 bytes boundary, max_align(T) would give 7, because we can loose max. 7 bytes, if we align this type. The align(ptr[, size]) template like function would give return an address _after_ ptr, which is properly aligned for type T. The caller can then create a type T at that address using replacement new. The second overload of align would check if it aligns ptr to a T is there any space left in those size bytes to create a T. If not, it throws some std::whatever_we_call_it. The max_align would help in allocation: template class fsdc_array { T *arr_; char buff_[sizeof(T)+max_align(T)]; }; The align would help in figuring out the address of the first element: template blabla fsdc_array::fsdc_array() { arr_ = align( buff_); } The code of the array template could then address its elements via arr_. Solution #2: ------------ This solution requires a new, special keyword in the declarations, hides all the know-how, and therefore a bit more complicated for the implementors but much easier for the users. And it is less flexible than #1, since with #1 I can even create a T *tp with align, then say Y *yp=align( tp+1); and position a Y after the T in the memory. This solution would enable the coder to change alignment of any type or just char arrays in declarations. As it seems it is enough for just char arrays, but you may see a good reason for open it up to arrays or any other type. It could look something like this: align_as char T_arr[sizeof(T)*S]; So align_as would be a sort of "storage specifier like thing", possibly behaving the same as static from syntax point of view. Except that it would not "collide" with any storage specifiers, since it is a different thing: alignment specifier. Solution #3: ------------ Provide both #1 and #2, allowing the nice "tricks" described about #1 under #2 (opening up a great flexibility) as well as give an easy way to do the easy thing. Conclusion: ----------- I see many people struggling with alignment issues. With the current set of language support (nil), we cannot solve this problem portably. Adding this max_align(), align() and align_as to the language we can allow people to save the dynamic memory allocation and still have a rather STL like container: but on the stack, which is thread safe, not like the heap/free-store. I know, that the idea of such a container can be attacked from exception safety point of view. Well, this is the price to pay, if the stored items are non-PIMPL. If they are, the dsfc array is a great thing: it is exception safe (swapping, assigning pointers is safe) but saves the unneeded "malloc call". ------------------------------------------------------------------------ This is posted to both clc++m and cstdc++ Please comment! MHC: ---- I guess the "support" for all 3 "things" I have suggested is already present in the language. It may happen that wording these into the standard may actually take more time then implementing them. There will be much more questions to answer then I have tried here: Like should T be a fully defined type? I remember Scott did complain something about being able to do a vector of incomplete types. Well, since here we use the size and alignment requirements for the type: I guess it should be fully defined. Attila [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do this! ] [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]