Hej

Detta är en enkel int-stack. Jag vill använda exception. Utan exception funkar bra men när jag inforgar
exception i mina två funktioner kommer följande:

....StringIndexOutOfRange......
undefined std....
...
...
...




Ser ni var felet ligger eller ska jag infoga en annan fil???hjälp mig


Mvh lisa

kOd:
// #################################### H-FIL

#ifndef MINSTACK_H
#define MINSTACK_H
#include <iostream.h>
#include <stdexcept>
using namespace std;

class Minstack{
public:
Minstack(int storlek=10);
~Minstack(){delete[]stacken;}

void push(const int &obj)throw(length_error);
int pop()throw(length_error);
void print();

private:
int *stacken;
int strlk,top;

Minstack(const Minstack *s){}
const Minstack operator=(const Minstack &s){return *this;};
};


Minstack::Minstack(int s)
:strlk(s)
{
top=-1;
stacken = new int[strlk];
}

void Minstack::push(const int &obj)throw(length_error){
if(top>=strlk-1)
throw length_error("fel");
stacken[++top]=obj;

}

int Minstack::pop()throw(length_error){
if(top<=-1)
throw length_error("Fel");
return stacken[top--];
}
void Minstack::print(){
cout<<"Antal i stacken just nu: "<<(top+1)<<endl;
for(int i=top;i>=0;i--)
cout<<stacken[i]<<" ";
}
#endif
// ############################# CPP-FIL ############################

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

void main(){
Minstack st(4);

try{

st.push(8);
st.push(6);
st.push(4);
st.push(2);

}
catch(length_error l){
cout<<l.what();
}
st.print();
try{

st.pop();
st.pop();
}
catch(length_error l){
cout<<l.what();
}
st.print();


cin.get();
cin.get();
}

För det första så ska du byta ut

#include <iostream.h>

till

#include <iostream>

och använda std:: framför allt i standardbiblioteket, ex. std::cout << "apa";

Sen som ett tips har du valt lite onödiga namn; "strlk" istället för "storlek", hur mycket tjänar det till egentligen? =)

Använd hellre talande namn på alla funktioner och variabler.

Hur som helst: Låter du throw-hänvisningen stå kvar när du inte kör med exceptions?
alltså
throw(length_error)
i deklarationen
void push(const int &obj)throw(length_error);

Det finns en del kompilatorer som inte fixar det. Om du provar att ta bort dem, så kan det funka,

<b>och använda std:: framför allt i standardbiblioteket, ex. std::cout << "apa";</b>

Eller så som du redan gör:
using namespace std;

...vilket man ju inte bör göra, eftersom man då tappar hela syftet med namnrymder.

Och detta har vi redan haft en lång diskussion om. Orkar dock inte leta reda på tråden.

Ja, jag vet. Men hur som helst kan du väl ändå inte anse att man bör öppna en namnrymd i den globala?

Om identifierarna från en namnrymd används överallt i ett program, dvs globalt, varför inte öppna namnrymden globalt?

Idén med namnrymder är att slippa använda långa namn som mysql_select_db() där man bakar in namnrymden i namnet och inte kan plocka bort det när identifieraren används. När programmeringsspråket stödjer namnrymder kan man, om ingen risk för namnkollision finns, klara sig med att skriva select_db(). Detta har dessutom fördelen att om man skulle byta databas, räcker det att byta ut <b>using namespace mysql;</b> mot <b>using namespace annandb;</b>.

Du verkar vara helt övertygad om att man ska öppna namnrymder globalt, till skillnad från majoriteten av C++-användarna. Sen köper jag inte dina argument.

<b>>Idén med namnrymder är att slippa använda långa namn som mysql_select_db()</b>
Långt ifrån det enda skälet. Det primära skälet var att enkelt kunna modifiera gamla bibliotek och headerfiler för att kunna följa en modernare syntax.

<b>>Detta har dessutom fördelen att om man skulle byta databas, räcker det att[...]</b>
Det där är inte sättet man i allmänhet gör det i C++. Det normala är att om man har två namnrymder A och B, så definierar man ett nytt som man kallar C, och sätter det till att vara A eller B, och refererar sen till C genom hela applikationen. Vill man någon gång byta byter man bara vad C är.

<b>>Om identifierarna från en namnrymd används överallt i ett program, dvs globalt, varför inte öppna namnrymden globalt? </b>
Eftersom programmet kan växa till den punkt när man inte längre kan ha en namrymd öppen globalt, och då måste gå igenom hela programmet för att flytta in namnrymden i metoder eller klasser.

<b>Du verkar vara helt övertygad om att man ska öppna namnrymder globalt</b>

Inte alla namnrymder skall öppnas globalt. Den enda jag rekommenderar öppnas globalt är std.



<b>Det primära skälet var att enkelt kunna modifiera gamla bibliotek och headerfiler för att kunna följa en modernare syntax</b>

Vilken "modernare syntax" syftar du på?

<b>>Inte alla namnrymder skall öppnas globalt. Den enda jag rekommenderar öppnas globalt är std.</b>

Citat:
<b>>Om identifierarna från en namnrymd används överallt i ett program, dvs globalt, varför inte öppna namnrymden globalt? </b>
Det där låter lite mer generellt än du sa nu...?

<b>>Vilken "modernare syntax" syftar du på?</b>
Den som tillkom efter 1994. Sen är väl kanske syntax fel ord, snarare "paradigm" eller så, men genom att införa namnrymderna kunde man enkelt behålla gamla bibliotek med minimala förändringar både i biblioteken och i klientkod.

Det ena var en fråga inte en rekommendation; jag ville få ett argument. Det andra var en rekommendation.

Sedan kan man skilja mellan olika typer av projekt. I grundkurser i programmering, där man i första hand skall lära sig hur programmering fungerar, ser jag inget hinder att öppna std globalt. Och jag uppfattade det som att trådskaparen ligger ungefär på eller strax ovanför denna nivå. I ett större projekt kan det vara en annan sak.



Utveckla gärna vilket paradigmskifte du syftar på som förenklades genom införandet av namnrymder.

<b>>Sedan kan man skilja mellan olika typer av projekt. I grundkurser i programmering, där man i första hand skall lära sig hur programmering fungerar, ser jag inget hinder att öppna std globalt. Och jag uppfattade det som att trådskaparen ligger ungefär på eller strax ovanför denna nivå. I ett större projekt kan det vara en annan sak. </b>
Ja, det är klart att det är skillnad på nybörjarprojekt och mer komplicerade grejer. Men det handlar också om att ge en attityd. En person som inte är van vid att arbeta med namnrymder på annat sätt än att släppa upp dem kommer dra sig för att göra på annat sätt senare också.

När personen i fråga har kommit till projekt där namnrymder är ett perfekt sätt att hantera situationen så faller de istället tillbaka till gamla, dåliga metoder, som villkorlig kompilering, makron, etc.

<b>>Utveckla gärna vilket paradigmskifte du syftar på som förenklades genom införandet av namnrymder.</b>
Jag talar inte om ett paradigmskifte, jag kallade det för "paradigm" (med citationstecken), något så dramatiskt har naturligtvis inte hänt. Men den modulära programmeringen, bibliotekstänket, etc. underlättades radikalt. Hela iden med att det inte finns något "äkta globalt" har förstärkts.

Som exempel (se Bjarnes sida) kan man bygga en interpretator, helt funktionsorienterat, men ändå hålla det på samma effektiva modulära nivå som all OOP.

Tack för förslaget att kolla på Bjarnes sida. Där hittade jag flera exempel där han själv använder <b>using namespace std</b> globalt. *he he* ;-)


<b>Som exempel (se Bjarnes sida) kan man bygga en interpretator, helt funktionsorienterat, men ändå hålla det på samma effektiva modulära nivå som all OOP.</b>

Det exemplet får du gärna ge en länk till.

Ja, det är jag fullt medveten om. Det glömde jag skriva i förra inlägget; att använda using namespace globalt är i princip bara till för två ändamål:
1. För att göra en mycket snabb konvertering av en gammal applikation till nya header-filer.
2. För exempel.

I exempel (som inte rör namnrymder) kan det bli plottrigt om man har med för mycket detaljer. Därför utesluter man ofta saker som namnrymder, felhantering, etc.

Det är möjligt att exemplet jag nämnde kom från Scott Meyers, men jag har för mig att det var Bjarnes. Hur som helst var det i princip en radda funktioner, grupperade i 3-4 namnrymder, med talande namn ("lexer", etc.). Den resulterande koden blev skitsnygg och enkel, och man såg tydligt att det var lätt att byta ut specifika komponenter.

EDIT:
För en bra genomgång av bla detta se Scott Meyers böcker, Effective C++-serien

Förresten, det sa jag nog inte.
Du verkar anse att std är en speciell namnrymd som alltid är ok att släppa eftersom den ändå är standard. Grejen är bara att det finns andra bibliotek som också lägger sig själva i std (även om det inte är en speciellt bra ide...).