Diskussion:C++

Effektivitet

* Effektivitet - Det tar lång tid att utveckla C++-program och många enkla saker kräver mycket kod. Det är lätt att slösa tid på debugging och länkning-fel.

Och vilka programspråk slipper man att "slösa tid" på avlusning i? Fel i koden kan uppstå i alla programmeringsspråk, så det där är väl ändå något som gäller alla språk? Vad gäller länkningsfel så är det väl inte direkt ett så stort problem att det bör nämnas här? Det är något som man faktiskt inte borde råka ut för om man har tänkt igenom vilka objektfiler och bibliotek som behöver länkas. Endast nybörjare borde väl tycka att det är ett förvirrande koncept, eller?

Faktiskt tycker jag inte att något av dessa är de första man kommer tänka på när man tänker på brister i C++. C++ stora nackdel är väl egentligen att det är förvirrande för nybörjaren, eftersom det omfattar så många olika paradigmer? Det kan ju till och med vara krångligt för en erfaren C++-programmerare att få grepp om andra personers C++-kod, eftersom de många olika paradigmerna leder till många olika programmeringsstilar. Jag menar absolut inte att det är enbart en nackdel att vara ett multiparadigmspråk, det gör ju trots allt språket mycket flexibelt. Men det är ett tveeggat svärd.

Någon som håller med? Andra förslag på riktiga nackdelar?

Det är luddigt skrivet. Men wikipedia är under ständig uppbyggnad :). Det som står här är inte färdigt, min tanke var att bara nämna några nackdelar med C++ och då måste ju länkning faktiskt nämnas. Det är omodernt och onödigt, något som kompilatorn borde sköta automatiskt. När det gällde 'debugging' menade jag inte att man var tvungen att fixa buggar i c++ och det slipper man i andra språk. Tanken var att man i C++ ofta måste lägga ner mycket mer kod för rutingrejer som att hantera minne, hantera besvärligare apier (som windows). Tid man kunde lägga ner på algoritmen för problemet hamnar lätt på att göra det man gjort hundratals gånger förrut (eller liknande). Om du programmerat några icke imperativa språk förstår du säkert vad jag menar. Eftersom man måste skriva mer kod i c++ blir det mer buggar. Den enkla tillgången till minnet genom pekare är också ett stort problem eftersom minnesfel (bufferoverlow, stack osv!) ger de farligaste buggarna. När det gäller att lösa programmeringsuppgifter på kort tid är c++ dåligt, c++ är inte produktivt. See resultaten från programmeringstävlingar för bekräftelse. Men annars har du rätt, raderna du citerade bör förtydligas. Användare:Dexter

Länkning sköts faktiskt oftast av kompilatorn. Att man hanterar minne är knappast något unikt för C++ utan något som finns i de flesta språk. Dessutom kan det oftast göras lättare i C++ än i t.ex. C genom att man lägger in allockering och frigörning av minne i konstruktor respektive destruktor. Hantera besvärligare APIer? APIerna är lika krångliga oavsett språk. Om man pratar Windows är det betydligt enklare att använda MFC än SDK. Användningen av pekare är heller inget unikt för C++ utan tämligen vanligt i språk där man vill kunna få den extra hastighet som direkt minnessaccess ger. Dina invändingar verkar lite ogenomtänkta. // Liftarn

Hehe, tänk lite mer innan du skriver nästa gång Liftarn =). Missförstå mig inte nu. Jag försöker inte desperat hitta nackdelar med C++ och påstå att det är ett dåligt språk. Men, eftersom det nämns fördelar måste man också nämna nackdelar. När det gällde länkningen sköts den INTE av kompilatorn utan av länkern, i visual studios fall heter den link.exe. Har aldrig varit med om en riktig (ej managed c++) c++ kompilator med inbyggd länker. Däremot körs den automatiskt ifrån visual studio som är en editor. Problemet med länkning är inte att att den finns utan att det kan uppstå problem som "unresolved external symbol", "multiple definitions". Jag anser att detta är onödigt och omodernt och gör att man måste skriva manuella #define blbala osv för att förhindra länkerfel. Moderna språk som java, C# osv har naturligtvis inte dessa problem. Återigen ingen stor nackdel, men det är en. Ditt snack om att apierna är lika krångliga för vilket språk man än väljer tycker jag inte stämmer av en anledning. C++ är lägre nivå, varje rad kan direktöversättas till en maskinkod utan att det tar alltför stor plats. Därför är det självklart att C++ kod tar mer plats. Varför tror du egentligen C++ program skriva i windows tar mycket mer plats än de skulle gjort om de var skrivna i VB, C#, Java, Haskell eller liknande. Sedan påstår blaja som att jag har skrivit att "pekare är unikt för C++", klart det inte är, men det finns både fördelar och nackdelar med att använda dem. Mitt huvudargument är att C++ inte är produktivt jämfört med Java, C#, Haskell eller liknande. Jag nämnde det sist för det var viktigast, anledning är texten ovan. Nämn gärna själv lite nackdelar med C++ förutom att det kan vara svårt för nybörjare vilket den anonyme kommentaren tillförde. // Användare:Dexter

Ok, missförstod dig angående länkningen. Det stora problemet med C++ är dels att det har mer overhead (än C iaf). Dels kan objektorienteringen ställa till väldiga problem om man inte ser upp, speciellt vid multippelt arv. Objektorienteringen gör också koden svårare att följa och debugga. Det är iofs inget unikt för C++. Ditt resonemang att C++ tar mer plats för att det inte tar mer plats låter underligt och ett anrop till en API tar ungefär lika stor plats oavsett språk. Att program Visual Basic tar mindre plats beror antagligen på att de (tills aldeles nyligen) var interpreterande. EXE-filen innehöll bara anrop till kod som låg i VBRUN.DLL som programmet tvingades släpa med sig. Om det är produktivt eller inte är ett annat resonemang. Jag skulle tro att C++-kod är enklare att underhålla än C, Fortran och assembler men svårare än Java och Pascal. // Liftarn

Bra att vi är överens om länkningen =). Nu tycker jag däremot du är helt ute och cyklar. Skulle det "stora problemet" med c++ var overheaden?! Om du använder ex Visual Studios egna common runtime library som dll:er vilket man borde om man nu tycker overheaden är viktig får du ett enkelt windows program på några kilobyte. Om man däremot är sparsam och skriver sitt eget crt eller använder någon annas får man med lätthet ner storleken till under 5 kb på enkla program. Visserligen blir C++ kod med nya funktioner som exceptions några kb större än C men detta vågar jag påstå aldrig har betydelse idag. Angående mitt resonemang om att C++ kod tar mer plats har att göra med att man måste skriva mer kod. Eftersom C++ är lägre nivå än ex VB som använder sig av enorma DLL-libraries så blir C++ koden mer optimerad för det den är skriven för. Tänk att skriva att helt program för windows direkt i maskinkod. Det skulle ta stor plats för att göra lite men den färdiga exe filen blir väldigt liten. Samma sak med C++, mycket kod ger förhållandevis liten exe fil eftersom man bara får med sånt man använder sig av. Att du inte tycker mängden kod har med produktivitet tycker jag är lika självklart som att det tar längre tid att gå 5km jämfört med 1km, eller?

// Användare:Dexter

Tja, det beror iofs vad man utvecklar för. Kör man på en modern PC blir varken den ökade storleken eller att det blir lite långsammare något större problem, men om man programmerar för inbyggda system med mindre minne och mindre CPU, t.ex. om man programmerar för en Z80 på 9 Mhz och har 32 kB RAM kan overheaden lätt bli besvärande. Ok, vi pratar om kompilerad respektive okompilerad kod. I Cobol kan man lätt producera mängder av kod som inte gör så mycket, innebär det då att man är produktiv? // Liftarn 3 januari 2003 kl.14.30 (CET)

Detta blev en intressant diskussion. Okej du håller fast vid att "det stora problemet" med C++ är overheaden. För det första. Det finns ingen Z80 på 9Mhz (vad jag vet om iallafall). För det andra. Hur stor del av de som programmerar gör det till en Z80 med 32kb minne eller sämre system? Lite för liten del för att påstå att det är den stora nackdelen. Fast det kan ju faktiskt stå med under nackdelar precis som du skrev: "Större overhead än C". Nu tänkte jag hjälpa dig lite med ordet produktiv eftersom du inte riktigt vet vad det är (eller så spelar du dum =)). Produktivitet är förhållandet mellan resurser och produktionsresultat. Allstå om det kostar mycket pengar att skriva ett program (vilket det gör om det är mycket kod) är det inte lika produktivt som att göra det i ett språk där samma jobb tar mindre tid. Imperativa språk och C++ i synnerhet är mindre produktiva än funktionella språk. För bekräftelse se ICFPs internationella programmeringstävlingar och se vilka språk som klarat sig bäst trots att de flesta kodar C++.// Användare:Dexter

Ok, vi lägger ner det eftersom det verkar vara en religiös fråga. I Sharp Wizard sitter en Z80 på 9.8 MHz och effektivt minnesutrymme för program är 32 kB och det finns en hel del som programmerar för den (i C, inte C++). Angående produktivitet beror resultatet på vad man mäter produktionsresultatet i, gör man som IBM gjorde förut och mäter det i antalet skrivna rader kod kan man få intressanta resultat... // Liftarn

Hahaha!!! Du fattar ju ingenting!?!? Vem bryr sig om hur IBM räknade produktionsresultaten förrut?? Frågan handlade om produktivitet. Jag har ett litet tips till dig. Lär dig ge upp vid rätt tillfälle och erkänn om du tänkt om. Så slipper du bli förnedrad. Eller så har jag helt fel och du är jätteklipsk, bara det att du inte sovit på ett tag :-). Tid är pengar. Användare:Dexter

Jag har läst igenom artikeln och diskussionen ovan men tycker att artikeln är ganska rörig. Jag skulle vilja ta bort delsektionerna om för- och nackdelar eftersom alla upptagna punkter är relativa, d.v.s., för- resp. nackdelarna beror på vad man jämför med. Istället skulle jag byta ut stora delar av texten mot en mer egenskapsorienterad beskrivning. Jag vill dock inte starta ett redigeringskrig, så jag slänger ut en krok här först för att se om någon har starka invändningar.
Mats Kindahl 22 maj 2004 kl.20.36 (CEST)

Artikeln som nu finns är väl närmast att betrakta som en stub... och jag håller med om att till och med det lilla som finns är ganska rörigt. Jag litar helt på dig matkin:-) // OlofE 22 maj 2004 kl.22.47 (CEST)

Trevligt att höra, för nu har jag börjat skriva om det. :) //Mats Kindahl 23 maj 2004 kl.10.33 (CEST)

Statiskt typat

Artikeln inleds med påståendet att c++ är "statiskt typat". Det uttrycket brukar oftas användas som motsats till "dynamiskt typat", och c++ är både och. Däremot sägs ibland att c++ är "starkt typat", vilket kanske säger mer om både språket och filosofin. Skillnaden i typhantering mot till exempel java är ganska liten (sånär som på javas extrema åtskillnad mellan ibyggda typer och objekt, som man slipper i c++), om man säger "starkt typat" i stället så är det mer till skillnad från till exempel perl ...

Det längre exemplet.

Jag får fel på

      cout << *i << std::endl;

i det längre exemplet på sidan. "`cout' undeclared (first use this function)" Jojan (diskussion) 23 mars 2006 kl.16.19 1 januari 2001 kl. 00.00 (CET)(Signatur tillagd i efterhand av none.)[svara]

Det är fixat nu. --Skizzik 23 mars 2006 kl.16.40 (CET)

Tack, men vad är det programmet egentligen ska göra? Man skriver bara in massa heltal (int) i den. --Jojan 24 mars 2006 kl.15.01 (CET)

Systemkommandon (Windows)

Vad har detta med C++ att göra?

Jag föreslår radering av denna del, alternativt tilläggande av förfarandet vid kompilering i samtliga operativsystem. //yuide 14 mars 2007 kl. 09.57 (CET)[svara]

Jag föreslår att det får stå kvar med motiveringen att det är en kod liksom den andra koden som tagits upp. Jag har haft stor nytta av att systemkommandona stod här och jag misstänker att det är fler än jag som haft nytta av det.

MVH

Grizzly 14 mars 2007 kl. 17.46 (CET)[svara]

Kanske har haft nytta, men det kanske skulle passa bättre i en annan artikel. /Moberg 12 april 2007 kl. 21.02 (CEST)[svara]

Jag håller med att det inte bör tas upp här. Jag förstår inte varför man nämner systemkommandon men inget om STL. -- Livlinan 3 januari 2008 kl. 20.43 (CET)[svara]

Verkar inte hända så mkt här så jag flyttade det mesta till Systemkommandon så länge, antagligen ett dåligt namn. -Moberg 6 januari 2008 kl. 14.51 (CET)[svara]

Kortkommandon för ASCII-tecken

Är det inte så att \xFF konverteras till den decimala motsvarigheten på det hexadecimala talet 'FF'? /Moberg 12 april 2007 kl. 21.02 (CEST)[svara]

\xFF konverteras till ett tecken inte ett nummer. \xFF blir det tecken som har det hexadecimala numret FF. Man behöver inte använda ordet "decimal". Sedan tillhör \xFF inte ASCII eftersom ASCII bara är 7-bitars. Så jag ska ta bort ordet ASCII. \xFF är ÿ i Latin-1 och ˙ i Latin-2. -- BIL 12 april 2007 kl. 21.43 (CEST)[svara]

Visst är det 7-bitars men för övrigt så anger \xFF visst ASCII nr 255, koden nedan kan visa det. { // enkelt program för att kolla hexadecimala koder

 cout << "\xFF";
 while(true);
 return 0;

Utskriften man får är inte så effektfull bara ett mellanslagsliknande tecken. Men att notera är att om du i anteckningar(notepad på engelska windows) trycker in alt+255 får du samma tecken. Inte övertygad? Prova med 3C då, motsvarigheten i Deciamala systemetär 60, du får fortfarande samma tecken, prova med 01 fortfarande samma. Dessutom finns inget tecken 100 att visa(256) vilket borde ligga utanför ASCII tabellen(256 är det 257:e tecknet). Det var därför jag lade till \xFF som ASCII när jag översatte stycket från sin gamla engelska version.

Strikt räknat är ASCII en amerikansk 7-bitsstandard med tecken upp till nummer 127. Hur nummer 128-255 tolkas är mer varierande och är inte ASCII. Skriver du Alt-255 på tangentbordet, får du DOS-tecken nr 255 som är ett slags blanktecken (arv från gamla PC-datorer). Kompilerar du ditt lilla program som ett DOS-program blir det utskriften. Du kan skriva Alt-0255 och få tecknet som Windows har som nummer 255 nämligen ÿ. Gör du ett litet Windows-program som visar "\xFF" så får du ÿ. Tecken nummer 100 hex finns inte i traditionella C++, men går att få som ett unicode-tecken, man kan (i vissa kompilatorer) skriva '\x100' vilket är nummer 256 eller unicode-tecknet Ā som inte finns i Latin-1. -- BIL 13 april 2007 kl. 14.50 (CEST)[svara]

Begreppet "ASCII" syftar numera i princip alltid till 8-bitars tabellen (med 256 "tecken" 0-255, inkl pipljud, newline, returrad etc). Tycker inte detta är något att bråka om. Skriver man "ASCII" avser man normalt sätt "den nya" ASCII-tabellen. (Ny) ASCII (i praktiken) omfattar även dubbelkoder som t.ex. kan användar vid direktinmatning (utan enter), piltangenter etc.
Annars tycker jag att påståendet om att C++ ger snabba program är mycket tveksamt. Jämfört med java går det undan, om man t.ex. skriver ett C-program och ett C++ program (exakt samma kod, frånsett stdio.h / iostream.h och printf / cout) och ber datorn räkna fram primtal nummer 125000 t.ex. , kompilerar och exekvarar på samma hårdvara går C-programmer omkring 8 ggr så snabbt. Och i ren assembler 50-100 ggr så snabbt. Vilket OS som används kan ha viss betydelse,
men C eller ännu hellre assembleroptimerad C (för de långsammaste delarna t.ex. division, modulus etc) ger övelägsen prestanda. C++ (som OOP) har bara sina fördelar i riktig stora program. /DrAssembler 83.249.33.82 19 augusti 2009 kl. 02.11 (Signatur tillagd i efterhand.)[svara]

Men det finns ju ingen "8-bitarstabellen". Det finns otal. ISO 8859-1 och Windows-1252 är de vanligaste i västvärlden, men alla som fortfarande jobbar i DOS är bekanta med Codepage 850. ASCII syftar fortfarande på 7-bitarstabellen, även om den alltsom oftast representeras i åtta bitar.

Vad gäller hastigheten på C++-program så får vi nog ta ditt exempel som en anekdot. Resultatet beror starkt på val av algoritm och kompilator. —CÆSAR 19 augusti 2009 kl. 16.47 (CEST)[svara]

Det finns ett otal 8-bitarstabeller och ingen av dem är ASCII. ASCII är strikt 7-bitar. Det är fullständigt ASCII-kompatibelt att helt sonika klippa bort den åttonde biten, något som historiskt sett ofta gjorts av mailprogram. Det är därför som quoted printable existerar. /ℇsquilo 24 oktober 2016 kl. 17.32 (CEST)[svara]

Onödiga delar

Jag tycker att stora delar av den här artikeln är överflödiga, exempelvis delen om hur en if-sats funkar. Om man ska ha exempel på programkod skriven i C++ kan man väl åtminstone ta upp på vilka sätt det skiljer sig från exempelvis C, med templates, hela den objektorienterade biten, lustiga namespaces, m.m. If-satser är inga nymodigheter och oändligt långt ifrån någonting speciellt för C++. Det hade varit bättre om vi visade t.ex. hur klasser fungerar i C++, med deras konstruktorer och destruktorer, hur templates kan se ut, operatoröverlagring, m.m. Delen om systemkommandon kan tas bort helt och likaså delen om "kortkommandon för ASCII-tecken", särskilt med tanke på att inget av det som står där är kommandon och dessutom är även det här väldigt långt ifrån unikt för C++. Herrn 5 december 2008 kl. 19.11 (CET)[svara]

Fördel /nackdel

Början av diskussionen (överst) präglas av för- och nackdelar med C++. När det gäller inlärning anser jag att det första språk man bör bekanta sig med är QBasic, den kompilerande versionen 4.5. Med detta språk kan man åstadkomma avsevärt mer än många tror. Och förutsatt att man kompilerar det som "stand alone exe" går det tämligen snabbt också. (QBasic ver 4.5 är dock ett 16-bitars språk och kommer vad jag förstår inte fungera på 64-bitars operativsystem) Fördelen är att man slipper tänka på datatyper, inkluderingar av headerfiler etc. Därefter är C tämligen lättlärt, bl.a pga att man inte skiljer på funktioner och subrutiner. Men att starta med C++ utan att kunna C anser jag direkt olämpligt, även om man väntar med inkapslade variabler, metoder, överlagring och annat som är typiskt för objektsorientering. En C++ programmerare som inte kan grunderna i C kommer bli en aning handikappad, vare sig han/hon märker det eller inte. Angående C# sade Bill Gates vid dess lansering ungifär "Jag programmerar helst direkt i maskinkod (!) , men nu tycker jag C# är så skojigt att jag gått över till detta". Jag tror honom knappast, utan tänker istället på ett äldre citat från samme potentat "Ingen kommer någonsin behöva mer än 1 Megabyte i sitt minne !". Vid hastighetsoptimeing (av räknetunga program) bör man undvika att använda alla typer av division (inklusive modulus). Det är det i särklass bästa optimering man kan göra. Minns jag rätt tar en division minst 17 klockcykler jfr addition, subtraktion och multiplikation som kan gå på två. Innuti nästlade loopar kan en ONÖDIG division slöa ner hastigheten extremt. Prova och skriv ett program som kontrollerar alla tal upp till önskad nivå, om de är primtal. En version med division och modulus en annan version utan all form av division - och lägg in en tidsfunktion som mäter tiden i dem båda. Spara resultat i en array (fält) eller (i andra hand)till en fil - utskrift på skärm förstör jämförelsen.

Vad som är bäst att lära sig först är en åsikt. Faktum är att C++ länge har använts som undervisningsspråk på universitet och högskolor. QBasic (sista version: 1.1) och QuickBasic (sista version: 4.5) är båda 16-bitarsprogram. Det finns dock modernare interpretatorer och kompilatorer, t.ex. QB64.

Bill Gates-citatet om minnet är en myt. 1 MB-gränsen beror på pekarstorleken i Intels 80x86-processor (20 bitar), vilket inte är något som Bill Gates bestämde över. Jag har inte lyckats hitta någon källa till C#-citatet.

Hastigheten hos en division beror på vilken processor man använder. På en 80386 tar en teckenlös (unsigned) division med två 8-bitarstal (AL * [minnesadress]) 17 cykler som du säger, men det kan motsvarande multiplikation också göra. C++ används dock på många fler processorarkitekturer än bara Intels, så det är mycket som kan skilja sig. En annan bra optimering som kan ge mycket större utslag än reducering av antal divisioner är uppslagstabeller, men det beror helt på vad det är man gör. –CÆSAR 17 mars 2011 kl. 09.00 (CET)[svara]

Vad är det du vill ha sagt? Du svamlar om att man borde lära sig BASIC (eller QBasic som du kallar det, som inte är ett språk) och om hur man optimerar programkod, men vad har det med denna artikel att göra? Herrn 20 mars 2011 kl. 11.25 (CET)[svara]

Dialekter saknas inom C++

Det finns enbart en standard och dess implementationer. Att lista release-historiken och kalla den för dialekter är felaktigt. - Jolun101 (diskussion) 24 oktober 2016 kl. 13.19 (CEST)[svara]

Vad har vi för källor som skulle kunna ligga till grund för en förbättring av artikeln? - Tournesol (diskussion) 24 oktober 2016 kl. 13.20 (CEST)[svara]

Omfattande material om C++ och C++-kommiten inom ISO (WG21) finns på [[1]] [[2]] och även [[3]]. De har nyligen fastslagit en releasad version kallad C++17. - Jolun101 (diskussion) 24 oktober 2016 kl. 13.29 (CEST)[svara]

Jämför med C (programspråk); K&R, ANSI, C99 och C11 är generationer snarare än dialekter. Ska man pratat om dialekter är snarast C++ en dialekt av C. /ℇsquilo 24 oktober 2016 kl. 17.24 (CEST)[svara]

Håller med. Möjligen att C, D, Go m.fl.kunde anses som dialekter men ändå mycket tydligare att helt utesluta rubriken dialekter. Jolun101 (diskussion) 24 oktober 2016 kl. 21.10 (CEST)[svara]

Jag känner inte till någon definition på programspråksdialekt, men en rimlig sådan vore att det är en parallell standard för samma språk. ISO-standarderna är inte parallella utan ersätter varandra. Jag håller därför med om att det är fel att kalla dem dialekter.

C, D och Go är andra språk, inte dialekter. På engelska Wikipedia finns ett segment om C++-dialekter som kan vara intressant: Outline of C++ § C++ dialects. –CÆSAR 25 oktober 2016 kl. 11.08 (CEST)[svara]

Jag håller med om att ISO-standarderna inte är "dialekter" Iziabel (diskussion) 1 september 2017 kl. 21.26 (CEST)[svara]

Sun Studio

Sun Studio är ersatt av Oracle Developer Studio, Oracle köpte Sun och produkten döptes om. - 84.216.231.210 24 oktober 2016 kl. 13.37 (CEST)[svara]

SDL är helt skrivet i C, inte C++

Tog bort följande stycke: SDL (Simple DirectMedia Layer) är ett API för grafik som är ganska lätt att använda. Det har inte lika många funktioner som Direct X och Win32-API:t men det tenderar att gå snabbare att programmera i och ger till skillnad från de tidigare nämnda alternativen portabel kod.

Jolun101 (diskussion) 25 oktober 2016 kl. 08.08 (CEST)[svara]

Externa länkar ändrade

Hej, wikipedianer!

Jag har just ändrat 1 externa länkar på C++. Kontrollera gärna mina ändringar. Om du har några frågor, eller vill be boten ignorera vissa länkar eller hela artikeln, läs frågor och svar för mer information. Jag har gjort följande ändringar:

Lade till arkiv https://web.archive.org/web/20090713013807/http://www.open-std.org/JTC1/sc22/WG21/ till http://www.open-std.org/jtc1/sc22/wg21/

När ändringarna har blivit kontrollerade kan du använda verktygen nedan för att rapportera eventuella problem.

Om du har hittat länkar som påstås vara döda men inte är det kan du rapportera det som falskt positivt.
Om du har hittat fel i själva ändringen kan du rapportera en bugg.
Om du har hittat fel med själva URL:en, som till exempel att den använder en otillförlitlig arkivtjänst, kan du ändra det med URL-verktyget.

Hälsningar.—InternetArchiveBot (Rapportera fel) 28 oktober 2017 kl. 06.11 (CEST)[svara]

Externa länkar ändrade

Hej, wikipedianer!

Jag har just ändrat 1 externa länkar på C++. Kontrollera gärna mina ändringar. Om du har några frågor, eller vill be boten ignorera vissa länkar eller hela artikeln, läs frågor och svar för mer information. Jag har gjort följande ändringar:

Lade till arkiv https://web.archive.org/web/20060925231414/http://www.infa.abo.fi/~chakie/kurser/c++/html/book1.html till http://www.infa.abo.fi/~chakie/kurser/c++/html/book1.html

När ändringarna har blivit kontrollerade kan du använda verktygen nedan för att rapportera eventuella problem.

Om du har hittat länkar som påstås vara döda men inte är det kan du rapportera det som falskt positivt.
Om du har hittat fel i själva ändringen kan du rapportera en bugg.
Om du har hittat fel med själva URL:en, som till exempel att den använder en otillförlitlig arkivtjänst, kan du ändra det med URL-verktyget.

Hälsningar.—InternetArchiveBot (Rapportera fel) 28 augusti 2018 kl. 03.28 (CEST)[svara]