Function Already Defined Error in C++

Function already defined error in C++

By default, these functions have external linkage. That means each translation unit has functions called double round(double r) and float round(float r), which causes a name collision at link time.

Some possible solutions are:

1. Declare the functions as static, which implies internal linkage
2. Inline the functions
3. Move the implementation out of the header and into a c/c++ file

Read more here:
What is external linkage and internal linkage?

By the way, include guards protect a single translation unit from including a header file multiple times. That's a different issue that what you're seeing here.

Error LNK2005: function already defined in MyForm.obj

If you declare and implement a function in a header file (Header.h) and if this file gets included twice, then you'll most likely will get a function already defined error at some point.

This can be fixed by either:

• Moving function implementation to a source (cpp) file and only keep it's declaration in the header (h) file

• Make the function inline (if it is acceptable), that will remove the error

How do I fix already defined -main in c++?

If you have two files (.cpp) in your visual studio project each containing a main or _tmain function, link will fail because there can only be one main function defined.

Rename all other main function and you'll be fine.

ctor error function already defined and has different type c++ or mql

just should write ; after class

class MovingAvrage_Expert
{
public:
   MovingAvrage_Expert(void);
   ~MovingAvrage_Expert(void);
   bool Init(void);
   double TradeSizeOptimized(void);
   void CheckForOpen(void);
   void CheckForClose(void);
   bool SelectPosition();
};

:)

LNK2005 function already defined in

You have an #include<List.cpp> in your Matrice.cpp and as you compile and link all cpp files together this will result duplicate definitions of everything defined in List.cpp as they are also defined in Matrice.cpp due to the include.

Replace the #include<List.cpp> with #include<List.h> and add the declaration of empty into the List.h

already defined error in VC++

Generally speaking, .c files contain embodiment of variables, functions, etc.; while .h files contain prototypes of variables, functions, etc., found in it's companion .c file.

It is generally the case that variable and function bodies are not placed in a .h file; only variable and function prototypes should be placed in .h files.

When considering how to split-up code into separate files, it is important to consider which functions, structures and macros are the most primitive. For example, if you write two functions, and function 'a' calls function 'b', function 'b' is most primitive.

The idea is to group functions into a 'c' file that are related, and are at a similar primitive level.

In the case of this question, the more primitive list functions should be embodied in list.c. Then 'list.h' is used to prototype functions and structures used by other less primitive .c files such as main.c.

The most primitive functions are also the most self sufficient. While less primitive functions should call more primitive functions, the reverse makes for clumsy code-flow.

Now to review the question code:

/*---list.c file ---*/
#include "main.h"

list.c should be considered as more primitive than main.c. Hence, having list.c include main.h is (professionally) not a good idea. list.c, being more primitive should be more self-sufficient.

Rather than including main.h, it would be better for list.c to include it's own list.h so that it has access to it's own `struct list' definition, etc.

void display()
{
    pHead->a=100;
    printf("%d",pHead->a);
}

In order to better isolate list.c, the above function should not reference a 'global' variable (pHead). Rather, it would be better to have the 'node to display' passed into the function as an argument.

With this in mind, here are how 'list.c' and 'list.h' might be improved:

/*---list.h file-------*/
#ifndef LIST_H
 #define LIST_H

typedef struct NODE_S
   {
   int a;
   struct list *next;
   } NODE_T;

typedef struct LIST_S
   {
   NODE_T *head;
   } LIST_T;

extern void NodeDisplay(NODE_T *node);

#endif

/*---list.c file ---*/
#include <stdio.h> // printf()
#include "list.h"  // NODE_T, LIST_T

void NodeDisplay(NODE_T *node)
   {
   printf("%d\n",pHead->a);
   return;
   }

Note that pHead and pCurrent are not prototyped, or embodied, in list.h or list.c Those variables are not used in list.c, and there is no functional reason to place them in list.h

---

Now examine main.h and main.c as they are in the question code:

/*----main.h file-----*/

#ifndef MAIN_H
 #define MAIN_H

#include<stdio.h>

#include "list.h"
#endif

In isolation, what is the purpose that main.h requires stdio.h and list.h? If they were removed, would there be something left 'undefined' in 'main.h'? Perhaps these two include files don't really belong in main.h. "But if they are removed from main.h, why even have a main.h?" Good point. perhaps main.h serves no purpose and perhaps should not even exist.

The main.c file is the least primitive of all files, and shouldn't generally export anything to other (more primitive) files.

/*---main.c file---*/
#include "main.h"

void main(void)
   {
   LIST *New=pHead;
   display();
   printf("\n\n%d",New->a);
   getch();
   }

So what exactly does main.c need? It needs calls printf(), so it will need to include stdio.h. It calls display(), and references the LIST structure, so it needs list.h.

Yes, those .h files were included in main.h; good point. However, the code will be less clumsy (more professional) if main.c includes exactly what it needs explicitly.

With this philosophy in mind, here is a reworked main.c, without a superfluous main.h:

/*---main.c file---*/
#include <stdio.h>   // printf()
#include <conio.h>   // getch()
#include "list.h"    // NodeDisplay(), LIST_T

int main(void)
   {
   LIST_T pList = 
      {
      .head = NULL
      };

   /* Allocate & Insert a node into the list. */
   NodeCreate(&pList, 100);
   NodeDisplay(pList.head);
   getch();
   return(0);
   }

This version of main.c includes exactly what is required, and appropriately calls less primitive functions. It has no need for 'global variables' because it passes its local storage to more primitive functions as needed.

Oh! you noticed the function NodeCreate()!

While the operation of allocating and inserting a new list node could be performed in main.c, such an operation is most likely a common occurrence that fits nicely with other linked list operations. Hence, add such a function to list.c:

/*---list.c file ---*/
#include <stdio.h>  // printf()
#include <stdlib.h> // malloc()
#include "list.h"   // NODE_T, LIST_T

void NodeDisplay(NODE_T *node)
   {
   printf("%d\n",node->a);
   return;
   }

void NodeCreate(LIST_T *list, int a)
   {
   NODE_T *newNode = malloc(sizeof(*newNode));
   if(NULL == newNode)
      {
      fprintf(stderr, "malloc(newNode) failed.\n");
      goto CLEANUP;
      }

   if(NULL == list)
      {
      fprintf(stderr, "Passing NULL as the list address not allowed.\n");
      goto CLEANUP;
      }

   /* Initialize new node fields (payload) */
   newNode->a = a;

   /* Link newNode as new 'list head' node. */
   newNode->next = list->head ? list->head->next : NULL;
   list->head = newNode;     
   newNode=NULL;

  CLEANUP:

     if(newNode)
        free(newNode);

     return;
     }

And so that this function can be called from the less primitive main.c, add a prototype of the function to list.h:

/*---list.h file-------*/
#ifndef LIST_H
 #define LIST_H

typedef struct NODE_S
   {
   int a;
   struct list *next;
   } NODE_T;

typedef struct LIST_S
   {
   NODE_T *head;
   };

extern void NodeDisplay(NODE_T *node);
extern void NodeCreate(LIST_T *list, int a);

#endif

---

See spoiler code here.

Linker says a function is already defined if I try to define it in another file (running tests)

I'm not defining printOne anywhere in Test.cpp.

Actually, you are, when you #include the source code of PrintOne.cpp into Test.cpp. If you then compile and link both Test.cpp and PrintOne.cpp together, the linker indeed sees 2 definitions of printOne(), one in each .obj file.

For what you are attempting to do, you need to add a .h file that just declares printOne(), and then you can #include that file into both .cpp files, where only one of them defines printOne(), eg:

Test.cpp:

#include "pch.h"
#include "CppUnitTest.h"
#include <iostream>
#include "PrintOne.h"

using namespace Microsoft::VisualStudio::CppUnitTestFramework;

namespace PointandVectorCreationTest
{
    TEST_CLASS(PointandVectorCreationTest)
    {
    public:
        
        TEST_METHOD(TestMethod1)
        {
            std::string expected = "1\n";

            std::stringstream buffer;
            std::streambuf* sbuf = std::cout.rdbuf(); // Save cout's buffer
            std::cout.rdbuf(buffer.rdbuf()); // Redirect cout to the stringstream buffer

            int result = printOne();

            // When finished, redirect cout to the original buffer 
            std::cout.rdbuf(sbuf);
            std::cout << "std original buffer: \n";
            std::cout << buffer.get();

            // Test
            Assert::AreEqual(expected, buffer.str());
        }
    };
}

PrintOne.h

#pragma once
int printOne();

PrintOne.cpp:

#include "PrintOne.h"
#include <iostream>

int printOne() {
    std::cout << 1 << std::endl;
    return 0;
}

LNK2005 already defined error on inclusion of C-type header file in C++ project [MSVC12]

This is a common problem with the header files, that contain implementaton. When you use #include directive, compiler simply inserts .h file content instead of it. So when you use this header in different places of your project, you get several identical implementations of its methods and global variables. Since it has #ifdef or #pragma once compiler guard, it compiles just fine. But when linker is trying to unite all compiled obj files to one executable module, it gets several identical implementations. Since it could not know which one should be used, you get LNK2005 error. To solve this problem you could move implementations and globals into the separate cpp file and include it in the project. Other way would be to mark all header functions as inline, or use __declspec(selectany)

---

Related Topics