- little problem - 1 Update
- Error in MSVC 2017... - 2 Updates
- Regal eagle / American cloud - 1 Update
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 07 03:15PM -0800 On 11/7/2019 12:11 AM, Bonita Montero wrote: > purpose. > So I did a simple xatomic-class which inherits the most stuff of > atomic via using: [...] This might be of interest. It does the copy ctor using std::memory_order_relaxed: _________________________________ #include <atomic> #include <vector> #include <iostream> struct foo_atomic { std::atomic<unsigned long> m_state; foo_atomic(unsigned long state) : m_state(state) {} foo_atomic(foo_atomic const& src) : m_state(src.m_state.load(std::memory_order_relaxed)) {} void display() { unsigned long state = m_state.load(std::memory_order_relaxed); std::cout << "state: " << state << "\n"; } }; typedef std::vector<foo_atomic> foo_atomic_vec; int main() { foo_atomic_vec a; a.push_back(foo_atomic(1)); a.push_back({ 2 }); a.push_back({ 3 }); a.push_back({ 4 }); foo_atomic_vec b = a; b.push_back(foo_atomic(5)); foo_atomic_vec::size_type n = b.size(); for (foo_atomic_vec::size_type i = 0; i < n; ++i ) { b[i].display(); } return 0; } _________________________________ Any help at all? Sorry. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 07 02:47PM -0800 This damn error still persists. MSVC needs to fix it. Have not checked the 2019 version yet. It has to do with reporting the size of an allocated array using overloaded new and delete. Here is the code: ______________________________ #include <cstdio> #include <new> struct custom_allocator { static void* allocate(std::size_t size) { void* const mem = ::operator new(size); std::printf("custom_allocator::allocate(%p, %lu)\n", (void*)mem, (unsigned long)size); return mem; } static void deallocate(void* const mem, std::size_t size) { std::printf("custom_allocator::deallocate(%p, %lu)\n", (void*)mem, (unsigned long)size); ::operator delete(mem); } }; template<typename T> struct allocator_base { static void* operator new(std::size_t size) { return custom_allocator::allocate(size); } static void* operator new[](std::size_t size) { return custom_allocator::allocate(size); } static void operator delete(void* mem) { if (mem) { custom_allocator::deallocate(mem, sizeof(T)); } } static void operator delete [](void* mem, std::size_t size) { if (mem) { custom_allocator::deallocate(mem, size); } } }; template<std::size_t T_size> class buf { char mem[T_size]; }; class buf2 : public buf<1234>, public allocator_base<buf2> { char mem2[1000]; }; int main() { buf2* b = new buf2; delete b; b = new buf2[5]; delete [] b; return 0; } ______________________________ MSVC gives the following erroneous output: ____________________________ custom_allocator::allocate(0126A478, 2234) custom_allocator::deallocate(0126A478, 2234) custom_allocator::allocate(0126CFF0, 11170) custom_allocator::deallocate(0126CFF0, 2234) ____________________________ Notice that MSVC loses the size of the dynamic array!? Grrr.... However, GCC still gets its right: ____________________________ custom_allocator::allocate(00df7320, 2234) custom_allocator::deallocate(00df7320, 2234) custom_allocator::allocate(00df7320, 11174) custom_allocator::deallocate(00df7320, 11174) ____________________________ This has been a persistent bug in MSVC for a long time. I wonder how many crashes it caused over the years? Hopefully not a lot because this usage is fairly rare... |
| Melzzzzz <Melzzzzz@zzzzz.com>: Nov 07 11:06PM > This has been a persistent bug in MSVC for a long time. I wonder how > many crashes it caused over the years? Hopefully not a lot because this > usage is fairly rare... Try array of objects with destructors. With destructors they have to place number of objects in array, so then it is possiblity they will report correct size... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 07 09:33PM >> which header files should exist, which is a disappointment. > Is there anything wrong with netinet/sctp.h? If not, I suggest > that as the home. It's analogous to netinet/tcp.h, udp.h and so on, so I guess that's the right place. And it's what the RFC uses in its examples (although it doesn't say anything about that being normative). /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| 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