STL Queue Implementation

A few points that nearly jump out at me:

1. You've implemented it as a linked list of individually allocated nodes. This nearly guarantees poor locality of reference and for small types wastes quite a bit of space.

2. Your destructor leaks memory:

   template <typename T>
   queue<T>::~queue() {
       node *curr = new node();
       while(head) {
           curr = head;
   

   This allocates a node (not clear why you'd want to allocate a node in the dtor, but there it is), then if head != nullptr, it overwrites that pointer with head, thus leaking the node it just allocated (and if that condition isn't met, it just flows off the end without doing any more with curr, also leaking the memory).

3. Your node type takes for granted that a T can be initialized from 0:

   node()
       : data(0)
   

   For a generic type, this assumption is unwarranted. You typically want to use T() to create a value-initialized object, which will be 0 for arithmetic types, a null pointer for a pointer type, an empty string for a string type, and so on.

First off

Never, ever use a using directive in a header as that can cause problems for your client code. As this is a code review I'm not going to comment on how to implement the C++11 features you mentioned. You can get help with this over at StackOverflow.

Public interface

Why is node a public type in queue? The user should never have to deal with the implementation details of queue. So I would recommend hiding it as a private or protected member class.

Your front() method returns a copy which is correct if called on a const declared queue. But on a non-const queue you're better of returning a reference to T.

Correctness issues

You should be aware of the fact that new can throw a std::bad_alloc. A destructor in C++ is allowed to throw an exception but it is generally discouraged. If an exception is thrown during handling of another exception the program will call std::terminate(), so if your destructor throws it can throw during stack unwinding and your program will terminates. Also if an exception is thrown from the destructor during a delete operation then the memory of the class may never be freed depending on the implementation of the delete operator. In short you are better off not throwing from the destructor. Not only that, your destructor actually leaks the allocated node which is never used.

Your pop() method also leaks memory through tmp if elements!=0 which it always is because you throw an exception if elements==0.

A correct pop() method should be written like this:

template <typename T>
void  queue<T>::pop() {
    if(head == nullptr)
        throw std::runtime_error("Invalid Action");

    node* remove = head;
    head = head->next;
    delete remove;

    --elements;
}

You are also unnecessarily allocating new nodes at many places.

Your node() constructs a T(0) in all cases which is not necessarily possible for all types a user may use as template argument. As Jerry also states this is incorrect. However Jerry's suggested solution to use T() instead requires that T be default-constructible without side-effects. This is not always true and you're better off using std::aligned_storage<sizeof(T)> like this:

template<typename T>
struct node {
    std::aligned_storage<sizeof(T)> data;
    bool has_data{ false };
    node *next;

    node()
        : next(nullptr) 
    {}

    node(T const& value, node* next)
        : next(next)
    {
        new (&data) T(value);
        has_data = true; // just incase the constructor throws.
    }

    node(T&& value, node* next)
        : next(next)
    {
        new (&data) T(std::move(value));
        has_data = true;
    }

    T& getdata(){
        if (!has_data)
            throw std::runtime_error("error no data");
        return *reinterpret_cast<T*>(&data);
    }

    ~node(){
        if (has_data)
            getdata().~T();
    }
};

This means that you can create nodes without actually running the constructor or initializing the node data.

Style suggestion

Prefer to test on what you need and not an invariant of what you need.

template <typename T>
T queue<T>::front() const {
    if(elements == 0)
        throw std::runtime_error("Invalid Action");
    return head->data;
}

Is better written like this:

template <typename T>
T queue<T>::front() const {
    if(head == nullptr)
        throw std::runtime_error("Invalid Action");
    return head->data;
}

Also you never call the node constructor with a non-null *next why not change the constructor to simplify usage?

Use sentinels

A sentinel node is an easy way to get around special casing the null list. Read more here: Sentinel Node.

Performance

The poor locality of reference due to linked lists can be mostly mitigated with a memory pool / fixed-size allocator. As the queue is popped at the front, any form of naive vector use is out of the question.

If the maximum number of elements is known at compile time, a Circular Buffer will be your best choice. With some work you can construct a dynamically expanding circular buffer and resizing it would be no more costly than resizing a vector which would leave you with amortized \$\mathcal{O}(n)\$ time to fill a queue of size \$n\$. I believe this is the best approach for performance.