[C++] compiler fout

[Marc_87]

Beste mensen,

Voor mijn opleiding op school ben ik C++ aan het programmeren. Dit doe ik met Microsoft Visual Express 2012. Er zijn mensen die de GVIM editor met de Borland BCC32 gebruiken en daarbij wordt de onderstaande code wel uitgevoerd. Ik krijg een acht tal errors.



De code die ik ingetypt heb moet via "cout" op het beeldscherm gezet worden.
Heeft iemand hier een idee wat er fout gaat omdat ik weet dat de code wel goed is...

[ Voor 6% gewijzigd door Marc_87 op 23-05-2013 10:53 ]

[Afvalzak]

Misschien even op de fouten googlen? Met name de 2e lijkt me wel handig..

[Verwijderd]

Misschien handig om het tweede .cpp bestand (vermenigvuldiging.cpp) ook te plaatsen..?

[ThomasG]

Als je de rode lijntjes en de foutmeldingen bekijkt, kun je zien dat je iterator nergens gedefinieerd is. De compiler heeft nu geen idee dat het een klasse moet zijn, waardoor het deze aanziet als ongedefinieerde variable. En krijg je de andere foutmeldingen er gratis bij. Je bent dus iets vergeten te doen.

spoiler:

#include <iterator>

[danslo]

Naast wat ThomasG zegt, mis je ook een aantal backslashes in je pad.

[Marc_87]

Wat ik dan niet snap is dat er bij andere programma's dat "#include <iterator>" niet bij hoeft te staan. Daarom heb ik hier ook niet aan gedacht.

Dit is uiteindelijk de code geworden en nu werkt die perfect. Nu nog even omschrijven zodat er ook regelnummers bijkomen:

C++:

#include <iostream>
#include <fstream>
#include <algorithm>
#include <iterator>
using namespace std;


int main()
{
ifstream in("C:\\Users\\Marc ....\\Documents\\Visual Studio 2012\\Projects\\test1\\test1\\vermenigvuldigen.cpp");
in >> noskipws;

copy( istream_iterator<char>( in ),
      istream_iterator<char>(),
      ostream_iterator<char>(cout)
     );
cin.get();
}

[ Voor 0% gewijzigd door RobIII op 23-05-2013 18:18 . Reden: Code-tags toegevoegd ]

[Zoijar]

Marc_87 schreef op donderdag 23 mei 2013 @ 18:06:
Wat ik dan niet snap is dat er bij andere programma's dat "#include <iterator>" niet bij hoeft te staan. Daarom heb ik hier ook niet aan gedacht.

Vziw zegt de standaard niets over welke andere headers bepaalde headers includen. Om portable te zijn moet je dus de juiste header includen, ookal zullen sommige compilers dat zelf al indirect doen via een andere header.

(using namespace std; wordt trouwens gezien als bad practice door vele)

[ Voor 7% gewijzigd door Zoijar op 23-05-2013 18:26 ]

[Marc_87]

Zoijar schreef op donderdag 23 mei 2013 @ 18:25:
[...]

Vziw zegt de standaard niets over welke andere headers bepaalde headers includen. Om portable te zijn moet je dus de juiste header includen, ookal zullen sommige compilers dat zelf al indirect doen via een andere header.

(using namespace std; wordt trouwens gezien als bad practice door vele)

Oke duidelijk, dan ga ik vanaf nu meer in de header includen.

Waarom wordt "using namespace std;" door velen als bad practice gezien dan?

[BoAC]

Google: c++ using std bad practice

[Zoijar]

Buiten die specifieke gevallen daar is het sowieso namespace pollution en verzwakt het encapsulatie. Je voegt eigenlijk gewoon botweg twee namespaces samen. Je kan al aanvoelen dat dat niet helemaal juist is.

[Marc_87]

Duidelijk, hier ga ik de leraar even mee confronteren.

[Zoijar]

Vraag je meteen even af waarom dit werkt, zonder std:: voor copy. Dan ben je al een eind op weg met C++

C++:

copy(std::istream_iterator<char>( in ),
      std::istream_iterator<char>(),
      std::ostream_iterator<char>(std::cout)
     ); 

[Soultaker]

Je bent tegen using namespace std maar argument-dependent lookup is prima

[Zoijar]

Soultaker schreef op donderdag 23 mei 2013 @ 23:24:
Je bent tegen using namespace std maar argument-dependent lookup is prima

Yep. http://www.gotw.ca/publications/mill08.htm

ADL is vrij noodzakelijk om de taal normaal te laten werken (tenzij je misschien alle lookup regels wilt veranderen) using namespace std is dat niet.

[ Voor 23% gewijzigd door Zoijar op 24-05-2013 00:12 ]

[Soultaker]

C++ barst van de features die niet strikt noodzakelijk zijn; da's een waardeloos argument om ze niet te gebruiken. Namespaces zelf zou je daar ook onder kunnen scharen.

Welk nut heeft ADL eigenlijk behalve het faciliteren van operator overloading? Daarvoor hadden ze ook simpelweg kunnen zeggen dat operators alleen in de globale namespace gedeclareerd kunnen worden. Dat was een minder ingrijpende aanpassing van look-up regels geweest, en feitelijk komt het daar met ADL ook op neer.

[ Voor 5% gewijzigd door Soultaker op 24-05-2013 00:29 ]

[Zoijar]

Namespaces en ADL bevorderen encapsulatie; dat is een van de belangrijkste principes van OOP.

Dit is trouwens een goed voorbeeld van die pagina van een mogelijk probleem:

C++:

// Example 1: Will this compile?
//

// in some library header
namespace N { class C {}; }
int operator+(int i, N::C) { return i+1; }

// a mainline to exercise it
#include <numeric>
int main() {
  N::C a[10];
  std::accumulate(a, a+10, 0);
}

Hoeft natuurlijk geen operator+ te zijn die problemen geeft, maar kan ook net zo goed een normale functie zijn. Een operator+ in std:: hide namelijk je globale operator+.

[Soultaker]

Die code is juist niet problematisch als alle operators in de globale scope zitten zoals ik voorstelde, en laat al die algoritmen in std nu juist operators gebruiken (of een expliciete comparator, wat ook het probleem oplost)

Maar goed, je hebt een punt wat betreft overloaded functies in het algemeen.