Asked  7 Months ago    Answers:  5   Viewed   31 times

I have some code in a header that looks like this:

#include <memory>

class Thing;

class MyClass
    std::unique_ptr< Thing > my_thing;

If I include this header in a cpp that does not include the Thing type definition, then this does not compile under VS2010-SP1:

1>C:Program Files (x86)Microsoft Visual Studio 10.0VCincludememory(2067): error C2027: use of undefined type 'Thing'

Replace std::unique_ptr by std::shared_ptr and it compiles.

So, I'm guessing that it's the current VS2010 std::unique_ptr's implementation that requires the full definition and it's totally implementation-dependant.

Or is it? Is there something in it's standard requirements that makes impossible for std::unique_ptr's implementation to work with a forward declaration only? It feels strange as it should only hold a pointer to Thing, shouldn't it?



Adopted from here.

Most templates in the C++ standard library require that they be instantiated with complete types. However shared_ptr and unique_ptr are partial exceptions. Some, but not all of their members can be instantiated with incomplete types. The motivation for this is to support idioms such as pimpl using smart pointers, and without risking undefined behavior.

Undefined behavior can occur when you have an incomplete type and you call delete on it:

class A;
A* a = ...;
delete a;

The above is legal code. It will compile. Your compiler may or may not emit a warning for above code like the above. When it executes, bad things will probably happen. If you're very lucky your program will crash. However a more probable outcome is that your program will silently leak memory as ~A() won't be called.

Using auto_ptr<A> in the above example doesn't help. You still get the same undefined behavior as if you had used a raw pointer.

Nevertheless, using incomplete classes in certain places is very useful! This is where shared_ptr and unique_ptr help. Use of one of these smart pointers will let you get away with an incomplete type, except where it is necessary to have a complete type. And most importantly, when it is necessary to have a complete type, you get a compile-time error if you try to use the smart pointer with an incomplete type at that point.

No more undefined behavior:

If your code compiles, then you've used a complete type everywhere you need to.

class A
    class impl;
    std::unique_ptr<impl> ptr_;  // ok!

    // ...

shared_ptr and unique_ptr require a complete type in different places. The reasons are obscure, having to do with a dynamic deleter vs a static deleter. The precise reasons aren't important. In fact, in most code it isn't really important for you to know exactly where a complete type is required. Just code, and if you get it wrong, the compiler will tell you.

However, in case it is helpful to you, here is a table which documents several members of shared_ptr and unique_ptr with respect to completeness requirements. If the member requires a complete type, then entry has a "C", otherwise the table entry is filled with "I".

Complete type requirements for unique_ptr and shared_ptr

                            unique_ptr       shared_ptr
|          P()           |      I        |      I        |
|  default constructor   |               |               |
|      P(const P&)       |     N/A       |      I        |
|    copy constructor    |               |               |
|         P(P&&)         |      I        |      I        |
|    move constructor    |               |               |
|         ~P()           |      C        |      I        |
|       destructor       |               |               |
|         P(A*)          |      I        |      C        |
|  operator=(const P&)   |     N/A       |      I        |
|    copy assignment     |               |               |
|    operator=(P&&)      |      C        |      I        |
|    move assignment     |               |               |
|        reset()         |      C        |      I        |
|       reset(A*)        |      C        |      C        |

Any operations requiring pointer conversions require complete types for both unique_ptr and shared_ptr.

The unique_ptr<A>{A*} constructor can get away with an incomplete A only if the compiler is not required to set up a call to ~unique_ptr<A>(). For example if you put the unique_ptr on the heap, you can get away with an incomplete A. More details on this point can be found in BarryTheHatchet's answer here.

Tuesday, June 1, 2021
answered 7 Months ago

MSVC is right while GCC is wrong:


Incompletely-defined object types and the void types are incomplete types


If T is an incomplete type, the program is ill-formed

Sunday, July 4, 2021
answered 6 Months ago

You are comparing a fiddle of v1 with your v2 fiddle.

In v2 there isn't slotMinutes. Instead you should use slotDuration (see the docs), that should be set to:

slotDuration: '00:15:00'

Here is the updated jsfiddle.

EDIT: Add description for each timeslot in vertical axis

The previous fiddle shows the 15 minute slot, but the vertical axis only has the hour (like 6am, 7am, and so on).

If you want the vertical axis to have all the time slots (6am, 6:15am, 6:30am, 6:45am), you can check the source code of fullcalendar.js line 5780 (version 2.1.1) where there is a function called slatRowHtml.

In this function, the following condition is used to write the time: !slotNormal || !minutes, where:

var slotNormal = this.slotDuration.asMinutes() % 15 === 0;
minutes = slotDate.minutes();

So, slotNormal is always be true (we have set 15 minutes period) and minutes will be 0, 15, 30 and 45. Since the condition is negative (!slotNormal || !minutes), this means that !slotNormal is always false and !minutes is only true when minutes = 0, and this is why only the hours are displayed.

To fix this you have two options, each one with its quirks:

  1. Set slotNormal = '00:15:01'. With this value slotNormal will be false and all slots will have a description. The issue with this is that you are adding a second to each timeslot, which means that, by the time fullcalendar is printing 3pm, it will be 3:01pm because of the added seconds. You can check this JSFiddle.
  2. Remove the entire condition from the source code and mantain slotDuration = '00:15:00'. This will work but you need to remember to check for the condition each time you update FullCalendar,
Friday, August 13, 2021
answered 4 Months ago

Use full calendar View-Specific Options

 views: {
  month: {
    columnFormat: 'dddd' // set format for month here
  week: {
    columnFormat: 'ddd d/M' // set format for week here
  day: {
    columnFormat: 'dddd' // set format for day here

remove columnFormat from your code and set views config.

Wednesday, August 25, 2021
answered 4 Months ago

The requirement of complete type at the template instantiation point is due to std::default_delete, so probably you could work-around it by providing a custom deleter.

struct node;         // node_delete need to know 'node' is a type.
struct node_deleter 
{                    // std::unique_ptr needs 'node_deleter' to be complete.
    void operator()(node* ptr);  // forward-reference to avoid needing
};                               //  'delete ptr' before the node is complete.

struct node
    std::unique_ptr<node, node_deleter> next;

void node_deleter::operator()(node* ptr)
     delete ptr;

Mind you, I have not tested it in MSVC, and probably you should try to upgrade to VC 11, or file a bug to Microsoft if even VC 11 cannot compile your original code.

Sunday, October 17, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :