Unresolved externals - na czym dokładnie polega problem?

Błędy
C++ Fatal Error LNK1120: 1 unresolved externals
error LNK2019: unresolved external symbol .... referenced in function .....

Próbowałem, nie działa:

1. Go back, start over again, go to File -> New -> Project -> Win32 Console Application -> name your app -> click next -> click application settings. For the application type, make sure Console Application is selected (this step is the vital step).
2. Add "..\header.h" in name

Zrobiłem uproszczony kod, który wygląda tak:
http://snag.gy/FLQOt.jpg
http://snag.gy/db5nr.jpg

Cały aktualny kod (już działający) wygląda tak:

 // nnnnnnnnnn 6 sierpnia.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <conio.h>

#include "bilet.h"

using namespace std;

void funkcja();

int _tmain(int argc, _TCHAR* argv[])
{
	funkcja();

	_getch();
	return 0;
}
//------------------------------------------------------------------------------------------------

#ifndef BILET_H	// _h header
#define BILET_H	

void funkcja();

#endif
//------------------------------------------------------------------------------------------------




#include "stdafx.h"		//bez włączenia tego nie działa ...
#include "bilet.h"
#include <iostream>
using namespace std;

//------------------------------------------------------------------------------------------------

void funkcja()
{
	std::cout << "fsafsaffa" << std::endl;
}

Na czym dokładnie polegał problem i jak się ustrzec tego typu błędów na przyszłość? Robiłem przykład z Symfonii, pierwotny kod był o wiele dłuższy i zawierał klasy. Dwa pliki nagłówkowe, 4 pliki cpp.
Czy

1. To że dodawałem te pliki w sposób "FILE -> NEW FILE -> NEW FILE CPP/ HEADER FILE" to powodowało ten problem #1

W jaki sposób poprawnie konstruować pliki, które mają więcej niż 1 plik. Dotychczas pisałem kod w stylu C.

Czy ten "bilet.cpp" powinienem był wsadzić do "Source files" w Solution Explorer (po prawej)? http://snag.gy/v18tX.jpg

Problem jest jako tako rozwiązany, ale chciałbym wiedzieć w czym tkwiła jego istota.
Z góry dzięki za odpowiedź.

edit:
Ten działający przykład zrobiłem przez normalne stworzenie projektu konsolowego, potem w Solution Explorer dodawałem nowy plik nagłówkowy i cpp, zamiast tego w #1 (patrz wyżej).

Problem polega na tym że nie bardzo rozumiesz co robisz. Kompilacja plików źródłowych generuje z nich pewien kod wynikowy. Jeden per plik. Kompilator/IDE musi wiedzieć które pliki kompilować, więc jak wrzucisz sobie jakiś plik w miejsce z dupy (jak uczyniłeś z tym bilet.cpp) to się nie dziw że kompilator go nie znajdzie i nie skompiluje.
Następnie następuje linkowanie czyli łączenie tych skompilowanych plików oraz potrzebnych bibliotek w jedną wykonywalną całość. Teraz też następuje wczesne wiązanie funkcji. Problem w tym że wśród twoich skompilowanych plików NIE MA takiego z definicją funkcji funkcja() więc pojawia sie błąd bo linker nie może znaleźć definicji teżje funkcji.

Prawdę mówiąc, wcześniej robiłem to tylko raz, ale wtedy specjalnie tego nie potrzebowałem. Spisałem te wnioski, byłbym wdzięczny gdyby ktoś je przeleciał i otagował je true/ false z ew krótkim komentarzem

Nowe wnioski (aktualne! 7 sierpnia 2015)

1. Funkcja main aplikacji konsolowej powinna być w pliku .cpp

2. Nazwa plików .cpp może być obojętnie jaka – i tak NIGDZIE ich nie włączamy dyrektywą inlcude (czy jest to reguła obowiązująca we wszystkich przypadkach?)

3. Plik nagłówkowy (header file) musi mieć poprawną nazwę – i też poprawnie musi być podana jego nazwa kiedy włączamy go dyrektywą include – inaczej C1083

4. „stdafx.h” wydaje się być konieczny w każdym pliku .cpp (kompilator wywala błąd, jeżeli go nie włączę)

5. W danym pliku .cpp oraz .h, jeżeli korzystamy z danych symboli (funkcje, klasy, zmienne)

6. Musi być deklaracja funkcji

7. Muszą być włączona dyrektywą include
   1. Pliki nagłówkowe (w cudzysłowie „... .h”)
   2. Biblioteki (nawiasy ostre <...>)

8. Natomiast nie trzeba podawać nigdzie nazwy pliku .cpp gdzie znajduje się ciało funkcji zwykłych i funkcji składowych. Ergo, tylko pliki nagłówkowe i biblioteki muszą być znane wśród plików .cpp, a same pliki .cpp nie muszą być znane w plikach nagłówkowych.

9. Nawiasy „...” i <...> informuje preprocesor gdzie w piewszej kolejności należy szukać dołączanych plików. Na razie wystarczy informacja, że cudzysłów jest dla plików nagłówkowych, a nawiasy ostre dla bibliotek.

10. Pliki nagłówkowe zawierają deklaracje funkcji i klas (w tym funkcji inline), pliki .cpp zawierają ciała funkcji składowych i zwykłych funkcji. W jednym pliku .cpp może być wiele takich funkcji. Natomiast należy trzymać się zasady: jedna klasa – jeden plik nagłówkowy.
    Dla funkcji składowych tworzy się osobny plik .cpp. W takim pliku zebrane są definicje zwykłych funkcji składowych (nie-inline). Dla .cpp nie trzeba strażnika nagłówka, ani też dyrektyw include dla plików nagłówkowych.

11. Fragment
    #ifndef OSOBA_H // _h header
    #define OSOBA_H
    // ...
    #endif
    jest tzw. strażnikiem nagłówka – chroni użytkowników tej klasy przed wstawieniem tego pliku nagłówkowego dwukrotnie. Tylko dla pliku nagłówkowego

12. Będąc w pliku .cpp z funkcją składową, na samym początku włączamy plik nagłówkowy, w którym jest definicja tej klasy.
    //******************
    // Plik: osoba.cpp
    //***************
    #include "osoba.h"
    #include <cstring>
    void osoba::zapamietaj(const char *napis, int lata)
    {
    strcp_s(nazwisko, (napis ? napis : "Anonim"));
    wiek = lata;
    }

13. Dla samych funkcji, wystarczy plik .cpp. W pliku main znajdzie się deklaracja, w innym pliku .cpp znajdzie się definicja tej funkcji (innym słowy, plik nagłówkowy nie jest potrzebny), a więc wystarczą minimum 2 pliki (2x .cpp) do stworzenia takiego programu.
    W przypadku klas, plik nagłówkowy jest konieczny aby przechować ciało klasy bez funkcji składowych nie-inline. Funkcje składowe nie-inline tej klasy są przechowywane w pliku .cpp. A więc trzeba minimum 3 plików, aby stworzyć taki program (1x plik nagłówkowy dla ciała klasy, 2x .cpp dla main i ciała funkcji składowych nie-inline).

Jeszcze jedno. Deklaracja

	void zapamietaj(
		const char *sk,
		const char *dok,
		rodzaj_pociagu poc,
		int kl = 2); 

Definicja powodująca błąd Error 1 error C2572: 'bilet::zapamietaj' : redefinition of default parameter : parameter 4

void bilet::zapamietaj(
	const char *sk,
	const char *dok,
	rodzaj_pociagu poc,
	int kl = 2)
{ 

Zmieniłem ją na
(pomogło zakomentowanie wartości domniemanej 4 argumentu w definicji funkcji składowej)

void bilet::zapamietaj(
	const char *sk,
	const char *dok,
	rodzaj_pociagu poc,
	int kl /* = 2*/)                                  //zakomentowalem = 2
{ 

O co tutaj chodzi? Kiedy próbuję zakomentować analogicznie wartość domniemaną w deklaracji, a zostawić w definicji (czyli vice versa), to wyskakuje błąd Error 1 error C2660: 'bilet::zapamietaj' : function does not take 3 arguments

1. KAŻDY kod źródłowy wykonywalny ma być w pliku cpp (z dokładnością do ciał metod razem z definicją klasy)
2. Ja bym nie ryzykował z fikuśnymi nazwami bo kompilator może nie podołać z jakimiś unicodami :P
3. Bo używasz Visuala. Inne kompilatory tego nie mają.
4. Nie trzeba.
5. Te twoje "biblioteki" to też nagłowki. Kwestia po prostu gdzie kompilator szuka.
6. Chciałbym zobaczyć jak implementujesz ciała metod klasy bez includowania nagłówka tej klasy ;] Zresztą sam sobie przeczysz w 10 ;]

Co do problemu z deklaracją/definicją to kłamiesz. W drugim przypadku zakomentowałeś za dużo (tzn zakomentowałeś cały argument) i stąd problem.

kvsanagi napisał(a):

O co tutaj chodzi? Kiedy próbuję zakomentować analogicznie wartość domniemaną w deklaracji, a zostawić w definicji (czyli vice versa), to wyskakuje błąd Error 1 error C2660: 'bilet::zapamietaj' : function does not take 3 arguments

Domyślny parametr powinien być albo w deklaracji albo definicji, nigdy obu. Dobrą praktyką jest umieszczenie go w deklaracji, bo zawsze działa i jak ktoś popatrzy na interfejs funkcji to od razu go zobaczy. Umieszczenie go w definicji działa jeśli w momencie wywołania funkcji ta definicja jest już znana:

#include <iostream>
using namespace std;

void foo(int x);
void foo(int x = 5)
{
	cout << x << endl;
}

int main() 
{
	foo();
}

Natomiast nie zadziała jeśli w momencie wywołania funkcji znana jest tylko deklaracja:

#include <iostream>
using namespace std;

void foo(int x);

int main() 
{
	foo();       // NIE skompiluje sie
}

void foo(int x = 5)
{
	cout << x << endl;
}

To jest właśnie ten błąd, który dostajesz. W momencie wywołania kompilator zna tylko funkcję, która przyjmuje 1 argument, więc oczywiście nie wie jak ją wywołać bez argumentu.