- Creating a constexpr list - 1 Update
- offsetof in C++ - 12 Updates
- why can't you copy stringstream? - 4 Updates
- "Death to C, ++" - 7 Updates
- Let us together create something the world desperately needs - 1 Update
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 18 11:13AM +0100 On Mon, 17 Jul 2017 11:00:20 -0700 (PDT) rep_movsd <rep.movsd@gmail.com> wrote: [snip] > In actuality I need to parse a LISP cons like data structure (which > is a multiway tree), so the statically allocated thing is likely to > be limiting. This won't work in C++. constexpr expressions are not like lisp macros: you don't have the whole language available for constructing at compile time the output form which is to be evaluated at run time, as you do with a lisp. Everything in a constexpr expression is a literal of some kind - a compile-time constant or a literal type, or a constexpr function taking and returning literal types. This means amongst other things that you cannot do anything in a constexpr expression which allocates memory. More generally, you cannot return or take as parameters non-literal types, including std::string. As a very trivial example, a lisp macro can call the language's time functions to embed the time of compilation in the compiled binary. This absolutely won't work in C++ (you would use the __DATE__ and __TIME__ macros instead). Have a look at this: http://en.cppreference.com/w/cpp/language/constexpr |
| jacobnavia <jacob@jacob.remcomp.fr>: Jul 21 12:25PM +0200 Hi I have to deal with this code: 93// given a pointer to w->m_chunk (where w is a CDBStringWrapper) return w. 94 static CDBStringWrapper* wrapperFromChunk(StringChunk const* c) { 95 return (CDBStringWrapper*)((char*)c - offsetof(CDBStringWrapper, m_chunk)); 96 } I have read about all kinds of warnings workaround and why the work around do not work about this. What would be the replacement of "offsetof" in C++ P.S. This code compiled OK for around 12 years. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 21 03:45AM -0700 On Friday, 21 July 2017 13:25:57 UTC+3, jacobnavia wrote: > around do not work about this. > What would be the replacement of "offsetof" in C++ > P.S. This code compiled OK for around 12 years. Is that CDBStringWrapper standard layout type? Can you post what you complain about 'offsetof', what is expected behavior and what is actual behavior? |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jul 21 10:57AM > around do not work about this. > What would be the replacement of "offsetof" in C++ > P.S. This code compiled OK for around 12 years. Well offsetof work only on POD structures. If CDBStringWrapper is not POD, you are out of luck... -- press any key to continue or any other to quit... |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 21 01:34PM +0200 On 21.07.2017 12:25, jacobnavia wrote: > I have read about all kinds of warnings workaround and why the work > around do not work about this. > What would be the replacement of "offsetof" in C++ It's still `offsetof`. It's limited to POD types. > P.S. This code compiled OK for around 12 years. In general, although the compiler may complain, there won't be a problem with offsets being dynamic unless some virtual base class is involved, and there won't be a problem with nullpointers dereferenced at compile time, so if just the compiler optimizes the expression to compile time constant you can (safely, but not formally) do things like this: struct Blah { int x; int y; virtual ~Blah() {} Blah( int a, int b ): x{a}, y{b} {} }; #include <stddef.h> // offsetof #include <stdio.h> using Byte = unsigned char; namespace my{ using Size = ptrdiff_t; auto dummy() -> Blah* { return nullptr; } auto y_offset() -> Size { return reinterpret_cast<Byte*>( &(dummy()->y) ) - reinterpret_cast<Byte*>( dummy() ); } } // namespace my auto main() -> int { Blah const o{ 111, 222 }; int const* const py = &o.y; Blah const* const po = reinterpret_cast<Blah const*>( reinterpret_cast<Byte const*>( py ) - //offsetof( Blah, y ) my::y_offset() ); printf( "%d %d\n", po->x, po->y ); } Cheers &/ hth., - Alf |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jul 21 12:40PM +0100 > I have read about all kinds of warnings workaround and why the work > around do not work about this. > What would be the replacement of "offsetof" in C++ What's going wrong? Are the conditions required of offsetof being met? Is the type a standard-layout class? > P.S. This code compiled OK for around 12 years. What's the compiler's error message? -- Ben. |
| jacobnavia <jacob@jacob.remcomp.fr>: Jul 21 02:19PM +0200 Le 21/07/2017 à 12:45, Öö Tiib a écrit : > Is that CDBStringWrapper standard layout type? > Can you post what you complain about 'offsetof', what is expected behavior > and what is actual behavior? DBBaseString.h: In static member function 'static CDBStringWrapper* CDBStringWrapper::wrapperFromChunk(const StringChunk*)': DBBaseString.h:95:66: error: expected primary-expression before ',' token return (CDBStringWrapper*)((char*)c - offsetof(CDBStringWrapper, m_chunk)); |
| jacobnavia <jacob@jacob.remcomp.fr>: Jul 21 02:20PM +0200 Le 21/07/2017 à 13:40, Ben Bacarisse a écrit : > What's the compiler's error message? DBBaseString.h: In static member function 'static CDBStringWrapper* CDBStringWrapper::wrapperFromChunk(const StringChunk*)': DBBaseString.h:95:66: error: expected primary-expression before ',' token return (CDBStringWrapper*)((char*)c - offsetof(CDBStringWrapper, m_chunk)); |
| jacobnavia <jacob@jacob.remcomp.fr>: Jul 21 02:33PM +0200 Le 21/07/2017 à 12:25, jacobnavia a écrit : > around do not work about this. > What would be the replacement of "offsetof" in C++ > P.S. This code compiled OK for around 12 years. MY FAULT! Excuse me all. The problem is that (somehow) cstddef.h wasn't getting included. How could this compile OK for so many years? Well, somebody has thought that it would be a good idea to optimize out the: #include <cstddef.h> in the latest version! He replaced it by the much faster code: 6 #if !defined(_SIZE_T_DEFINED) 7 #ifdef _64BIT 8 #if defined(_WIN64) 9 typedef unsigned __int64 size_t; 10 #else // defined(_WIN64) 11 typedef unsigned long long size_t; 12 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment