0

I have this very weird error in the constructor of my class.

#include "ContratException.h"
//#include "File.h"


namespace labPileFile {

template<typename T>
File<T>::File(const int max) :
        m_tete(0), m_queue(0), m_tailleMax(max), m_cardinalite(0) {
    m_tab = new T[m_tailleMax];
}

template<typename U>
std::ostream& operator <<(std::ostream& p_out, const File<U>& p_source) {
    p_out << "[";
    for (int i = 0; i < p_source.taille(); ++i) {
        p_out << p_source[i] << ",";
    }
    p_out << "]";
    return p_out;
}

}

Eclipse gives me several "Expression cannot be used as a function" errors Errors

All three errors are the same thing.

here is my .h, if it can help (I have to create the .cpp from the .h that I was given)

#ifndef _FILE_H
#define _FILE_H

#include <iostream>
#include <stdexcept>

namespace labPileFile {

template<typename T>
class File {
public:
    File(const int = MAX_FILE);
    ~File();

    File(const File<T> &);
    const File<T> & operator =(const File<T> &);

    void enfiler(const T &);
    T defiler();

    int taille() const;
    bool estVide() const;
    bool estPleine() const;

    const T & premier() const;
    const T & dernier() const;

    T operator [](const int &) const;

    void verifieInvariant() const;

private:
    T *m_tab; /*!< Content of the queue*/
    int m_tete; /*!< Head of the queue (first index)*/
    int m_queue; /*!< Last index of the queue*/
    int m_tailleMax; /*!< Current capacity of the queue*/
    int m_cardinalite; /*!< Number of elements*/
    static const int MAX_FILE = 100; /*!< Default capacity*/
};
}

#include "File.hpp"

#endif

Does anyone know what I'm doing wrong?

Kaito Kid
  • 983
  • 4
  • 15
  • 34
  • are these just errors shown by eclipse or real compiler errors? – 463035818_is_not_an_ai Sep 23 '16 at 16:32
  • Do you have a `using namespace std;` statement in any header file involved? – πάντα ῥεῖ Sep 23 '16 at 16:32
  • @Nathan I'm not sure this dupe applies here. – πάντα ῥεῖ Sep 23 '16 at 16:33
  • @πάνταῥεῖ Reopened. I didn't see the `#include "File.hpp"` at the end so I assumed the OP was using a cpp file as they said. – NathanOliver Sep 23 '16 at 16:37
  • Why are you initializing integers like that instead of inside constructor? This kind of initialization is meant for member objects, though it usually works. – Gabriel Vasconcelos Sep 23 '16 at 16:54
  • 2
    @GabrielVasconcelos Why *wouldn't* you ? Member initializer lists are there to initialize direct and virtual base subobjects and non-static data members. I suggest you [read up on it](http://en.cppreference.com/w/cpp/language/initializer_list). – Nelfeal Sep 23 '16 at 17:08
  • @tobi303 Those are real errors that prevent compilation; πάνταῥεῖ I don't have std anywhere; GabrielVasconcelos This is how our teacher makes us do it, so it really doesn't matter if it's good or bad, since I have to do it or I'll lose points. – Kaito Kid Sep 23 '16 at 17:15
  • @Nelxiost because it is not a necessary nor interesting fashion, imho. Normal attribution works perfectly fine, so why have it done different? In case of subobjects though it is better as it's a "simpler" way of calling the constructors. – Gabriel Vasconcelos Sep 23 '16 at 17:15
  • @KaitoKid I see... Have you had a look in which C++ version you're using? Afaik this works only from C++11 (not sure here) – Gabriel Vasconcelos Sep 23 '16 at 17:18
  • 1
    @GabrielVasconcelos If by "subobjects" you mean "member objects", then they are data members. And whether data members are objects or not, it makes sense to treat them the same way. It isn't necessary for fundamental types, and it isn't either for classes. I see no reason for segregating them. However, in both cases, the member initializer list **initializes** members. In the constructor body, you don't initialize any member. – Nelfeal Sep 23 '16 at 17:23
  • @KaitoKid The code is fine for every version of C++, from [C++98](http://coliru.stacked-crooked.com/a/3233a6e10190fd6b) to C++17. Eclipse seems to be the culprit here. – Nelfeal Sep 23 '16 at 17:30
  • @Nelxiost What would you suggest to identify what Eclipse's problem is, and try to solve it? As of now, I can't ignore it since the build fails... – Kaito Kid Sep 23 '16 at 17:37
  • @KaitoKid The first thing I would do is confirm this is Eclipse's fault. Compile your code without it. Then, if it runs fine, check what Eclipse uses as the compiler and change/update it if you can. I'm afraid I don't know Eclipse well enough to help you any further. – Nelfeal Sep 23 '16 at 17:43
  • Are these actual errors that occur when you compile or are they of the immediate, often bogus, "IDE tries to be clever and find errors without invoking the compiler" variety? – molbdnilo Sep 23 '16 at 17:46
  • @Nelxiost By "subobjects" I mean the same as you. Everywhere else in code you use assignment, why change it here? Initializer list becomes necessary for member objects that have a default constructor that might cause unwanted behavior (specially when POD). Initialization list prevents this from happening. Apart from that and const members (that need to be initialized), it's just not necessary. – Gabriel Vasconcelos Sep 23 '16 at 17:54
  • Tried to duplicate in eclipse 4.5.2 with CDT 8.8.1 but too many pieces missing to confirm or deny. I don't get any complaints from CODAN, but I have no idea what's going on around or how the template's being invoked. – user4581301 Sep 23 '16 at 17:54
  • @GabrielVasconcelos The member initializer ensures a predictable initialization order and the compiler can be configured to complain if you try to break it. Very handy. Not necessary here, but why mix use two initialization styles if you don't have to? – user4581301 Sep 23 '16 at 18:00
  • @GabrielVasconcelos (1/2) By "direct and virtual base subobjects" I (or rather, cppreference) refered to inheritence mechanisms. I doubt you meant the same, since, as far as I know, you cannot call one of the base objects constructors in the body (thus, it wouldn't be a "simpler way", but the only way). This brings me to guess that you meant something different : class-type members (or member objects). Then, you mention assignment. The problem is, we are not talking about assignment, we are talking about initialization. – Nelfeal Sep 23 '16 at 18:43
  • @GabrielVasconcelos (2/2) So, again, why would you change the way you initialize a member based on its type ? If doing something isn't necessary, do you go out of your way just to avoid doing it ? I run the risk of repeating myself, but it makes sense to treat members the same way, whether their type is a fundamental type or a class, hence you shouldn't initialize them differently. – Nelfeal Sep 23 '16 at 18:48

0 Answers0