Is there a difference between abstract data type and interface?

Question

From what I understand, an abstract data type is basically some data and what we are allowed to do with that data (ex. a list with a set of data and an attribute size and the functions get(), set(), sort(), insert() and remove(). It's an abstract data type because we do not know what the data inside is going to be or how get(), set(), sort(), insert() and remove() are going to be implemented. Is this basically the same thing as an interface? for example in C++

template <typename T>
class List{
private:
    int size;
    T* data;
public:
    T get(int index) = 0;
    void set(int index) = 0;
    T remove(int index) = 0;
    void sort() = 0;
    void insert(T obj) = 0;
};

would List here be considered an abstract data type? Also what if the attributes are hard typed like in the following class?

class Person{
public:
    string name;
    int age;
    string gender;
};

Thanks

Answer 1

An ADT has an interface, but they are not the same thing. For example, Objects are fundamentally different from ADTs (see for example On Understanding Data Abstraction, Revisited by William R. Cook for a simple explanation), but they also have interfaces.

Also, a single ADT (or a single Object) can have multiple interfaces, for example, a List ADT can be both iterable and indexable.

It is also possible, although not sensible for something to have an interface that leaks its internal representation, making it neither an ADT nor an Object, but still having an interface.

Answer 2

An abstract data type is just that, abstract.
It supports some operations and might give an idea of their complexity, but that's it already. The exact details are not at this level, they would obscure the important things.

All those details, namely how the operations are accessed and what they do (arguments, their ranges and types, name, preconditions, postconditions, invariants) make up the interface and its contract.

A specific implementation adheres to the interface, but adds all the details about how it works internally.
You should generally "program to the interface , not the implementation".

Knowing ADTs lets you quickly determine suitable concrete data types.
But unless you are debugging or modifying the concrete implementation, you should refrain from going beyond its public interface, as the inner workings are often confusing and subject to change without notice.

---

List in your example is just a compilation error. If you fix it enough by adding virtual where needed, you will have an abstract class.
The part of its interface you don't show are what those member-functions are contracted to do. Also, are there non-members which belong to it?

Person looks like ye old bag of data. All the innards are laid bare, the interface is pretty much obvious and trivial. There is nothing interesting about it. That's not to say bags of data, also known as data-transfer-objects aren't useful and sometimes the only intelligent way to go about it, especially inside a different classes implementation.