Hirdetés
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- Meggyi001: Eldugott helyek Párizsban, amiket jó eséllyel még nem láttál... 2. rész.
- GoodSpeed: Kell-e manapság egérpad vagy sem?
- Gurulunk, WAZE?!
- droidic: Windows 11 önállóság nélküli világ: a kontroll új korszaka
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
Új hozzászólás Aktív témák
-
-
Jester01
veterán
válasz
sztanozs
#3487
üzenetére
Ha egy virtuális függvény közvetlenül vagy közvetett módon konstruktorból vagy destruktorból hívódik meg, ideértve az osztály nem statikus adattagjainak konstruktorát és destruktorát is, és az objektum amire a hívás vonatkozik maga az objektum ami konstruálás vagy destruálás (jajj
) alatt áll akkor a meghívott függvény a konstruktor vagy destruktor osztályában lévő végső override nem pedig leszármazott osztálybeli.Vagyis az adott példában az A() konstruktorban az f() virtuális hívás feloldása során csak a konstruktor osztályát veszi figyelembe és nem a leszármazottat még akkor sem ha amúgy egy olyan példány készül éppen. Így lesz belőle A::f()
MOD: ToMmY_hun
-
Jester01
veterán
válasz
EQMontoya
#3485
üzenetére
Nem hiba. A szabvány szerint:
When a virtual function is called directly or indirectly from a constructor or from a destructor, including during the construction or destruction of the class's non-static data members, and the object to which the call applies is the object (call it x) under construction or destruction, the function called is the final overrider in the constructor's or destructor's class and not one overriding it in a more-derived class.
-
Jester01
veterán
-
Jester01
veterán
válasz
zsambek
#2675
üzenetére
Ha a 44. sorban a temp az simán csak T* tömb lenne akkor a 67-69 sorokban egyszerűen értékadás lehetne.
A kisebb függvényben a const hibás használata (célszerűen const char*).
Nincs ~Array ezért az adat nem kerül felszabadításra, memory leak.Stilisztikai megjegyzések:
Nyelveket keverni nem szerencsés: adat, kisebb, getData(int i){return adat[i];}, stb...
Érthetelen/félrevezető nevek: ssize, elements
Inkonzisztens elnevezések: getData, setElements de bubble_Sort és merge_Sort.
Nem a legszűkebb scope használata.Elsőre ennyi
-
Jester01
veterán
válasz
Krono91
#2646
üzenetére
Nem ott van a hiba ahol mutatod, szerintem a fordító sem ott mondja ... az enyém legalábbis nem
Ez a rossz:
ListaElem(ListaElem *next = 0, ListaElem *prev = 0) :n(next), p(prev) {}
Valószínűleg ezt akartad inkább:
ListaElem(ListaElem *n = 0, ListaElem *p = 0) :next(n), pre(p) {}
-
Jester01
veterán
válasz
EQMontoya
#2643
üzenetére
Minden bizonnyal olyan környezetben vagy ahol az int és a double között van egy kis üres hely. Például ha az int 32 bites a double meg 64 akkor lesz közöttük 4 byte üres hely. Az ip++ erre az üres helyre fog mutatni, viszont a dp már félig át fog lógni a double tagba. -
#2557
Jester01
veterán
kemkriszt98
#2556
Jester01
veterán
válasz
kemkriszt98
#2556
üzenetére
Egyszeri használatra meg ez fölösleges program, sokkal egyszerűbben is le lehet ezeket gyártani.Na mindegy.
-
#2555
Jester01
veterán
kemkriszt98
#2554
Jester01
veterán
válasz
kemkriszt98
#2554
üzenetére
Azért azt érzed, hogy ez borzalmas, ugye?
A hiba mindenesetre itt van: string s = "PC" + a+b+c+d;
Itt a + operátor az nem karakter hozzáfűzés, hanem a "PC" konstanshoz képest pointer művelet. Éljen az operator overloading
Egy lehetséges javítás: string s = string("PC") + a + b + c + d; -
Jester01
veterán
-
#2268
Jester01
veterán
WonderCSabo
#2267
Jester01
veterán
válasz
WonderCSabo
#2267
üzenetére
Előre is le lehet fordítani (AOT). A JIT az interpretálástól szerintem igen messze áll.
-
#2266
Jester01
veterán
WonderCSabo
#2265
Jester01
veterán
válasz
WonderCSabo
#2265
üzenetére
Izé, alapból a .net az JIT (tehát futásidőben bináris kódra fordul) nem interpreter. Sőt, előre le is fordíthatod. Bár az is tény, hogy van hozzá interpreter is.
-
#2264
Jester01
veterán
PumpkinSeed
#2263
Jester01
veterán
válasz
PumpkinSeed
#2263
üzenetére
A teg_szam-nak nem kell paraméter. Ezt minden bizonnyal a fordító is közölte veled.
Vagyis:cout<<endl<<t.teg_szam()<<endl;
A téglalap objektumod már tudja a saját szélességét-hosszúságát, így a területét is.
-
Jester01
veterán
Az álláshirdetések nagyobb részében azt látom, hogy c++ programozókat keresnek.
Ebben nem vagyok olyan biztos.
a c++ is félig meddig OOP nyelv, jól tudom?
Igen.
egy új nyelvet megtanulni tényleg "könnyű"?
Igen, amíg hasonló koncepcióra épül. Pl. haskell-t nem feltétlenül könnyű megtanulni ha csak c# tudásod van.
mi a különbség a két nyelv között?
Sokminden, de a szerintem az egyik legfontosabb, hogy a c#-hoz alapból társuló .net keretrendszer sokkal bővebb mint a c++ szabványos könyvtár így egy csomó dolgot sokkal könnyebb megvalósítani. Másik fontos dolog, hogy c#-ban alapvetően garbage collector van.
-
Jester01
veterán
Szerintem az a kolléga problémája, hogy a ciklusból akar kilépni amit ugye break-kel lehetne, de a switch-en belüli break nem azt csinálja.
Lehetséges megoldás külön függvény vagy return használata. Persze a goto is működne, ha jó helyen lenne a címke. Illetőleg egy kilépési flag is szóba jöhet.
-
Jester01
veterán
válasz
loopati
#2228
üzenetére
A logaritmus elég időigényes dolog, egy osztásos ciklussal szerintem jobban jársz, de ahogy gondolod.
Tizedesvessző után nem lesz szám ha egészekkel operálsz
Ez például megadja a 3 legmagasabb helyiértékű számjegyet:
while(x > 999) x /= 10;
Ezután ha szükséges akkor az egyes számjegyeket további osztásokkal már egyszerű kinyerni.
-
Jester01
veterán
Mondjuk annyi előnye van, hogy így a fordítótól függ, milyen kódolást használ
Ami egyáltalán nem biztos, hogy előny. Ha a feladat azt mondja, iso8859-2 kódolásra csináld meg de nincs olyan fordítód vagy ha más is le akarja fordítani a programod más kódolású fordítóval.
Szóval nem rossz megoldás ez ha le van fektetve konkrétan mit kell csinálni. Arról nem is beszélve, hogy gyorsabbat nem nagyon fogsz írni.
Abban igazad van, hogy nem általános.
-
-
Jester01
veterán
válasz
Jester01
#2218
üzenetére
Például iso8859-2 kódolásra:
#include <stdio.h>
static const unsigned char table[] = {
/* 0xC0 */ 0, 'A', 0, 0, 0, 0, 0, 0,
/* 0xC8 */ 0, 'E', 0, 0, 0, 'I', 0, 0,
/* 0xD0 */ 0, 0, 0, 'O', 0, 'O', 'O', 0,
/* 0xD8 */ 0, 0, 'U', 'U', 'U', 0, 0, 0,
/* 0xE0 */ 0, 'a', 0, 0, 0, 0, 0, 0,
/* 0xE8 */ 0, 'e', 0, 0, 0, 'i', 0, 0,
/* 0xF0 */ 0, 0, 0, 'o', 0, 'o', 'o', 0,
/* 0xF8 */ 0, 0, 'u', 'u', 'u', 0, 0, 0
};
int removeaccent(int c)
{
unsigned char mapped;
if (c < 0xc0) return c;
mapped = table[c - 0xc0];
if (mapped == 0) return c;
return mapped;
}
int main()
{
int c;
while((c = getchar()) != EOF)
{
putchar(removeaccent(c));
}
return 0;
} -
Jester01
veterán
válasz
Dave-11
#2194
üzenetére
Alapesetben a getline() az ajánlott, igény szerint hossz ellenőrzéssel és hibajelzéssel.
Nyilván ha 20 karakternél többet ad a felhasználó és te nem olvasod be, akkor a következő beolvasások onnan folytatják. A getline() az egész sort beolvassa neked, tehát ilyen probléma nem lesz.
-
Jester01
veterán
válasz
Dave-11
#2180
üzenetére
A static ilyen használata (mert van neki sajnos több is) azt jelenti, hogy az adott függvény csak az aktuális modulban (fájlban) használható, kívülről nem. Ezáltal a fordító jobban optimalizálhat és nem koszoljuk össze a globális névteret. Jelen esetben persze nem volt jelentősége.
-
Jester01
veterán
válasz
Dave-11
#2178
üzenetére
Ha szabad néhány dolgot megjegyeznem (konstruktív célzattal):
* a magyar és az angol elnevezések keverése nem szép dolog.
* return után nem kell else
* ha már c++ akkor van benne sort gyárilag
* ha nem használod a sort-ot akkor legalább függvénybe illene kitenni a saját implementációt
* a négyzetgyökre még meg kell nézni az oszthatóságot, vagyis <= kell
* nem kell float-ra castolni az sqrt hívásban
* a 2-t nem kell speciálisan kezelni
* nem kell új vektorAz én megoldásom így néz ki (bele szabad kötni):
#include <vector>
#include <algorithm>
#include <cmath>
#include <iostream>
using namespace std;
static bool isPrime(int a)
{
if (a <= 1) return false;
for(int i = 2; i <= sqrt(a); i++)
{
if ((a % i) == 0) return false;
}
return true;
}
static void problem5(vector<int>& v)
{
vector<int>::iterator boundary = partition(v.begin(), v.end(), isPrime);
sort(v.begin(), boundary, less<int>());
sort(boundary, v.end(), greater<int>());
}
int main()
{
int numbers[] = { 2, 3, 1, 6, 7, 4, 5, 9, 8 };
vector<int> v(numbers, numbers + sizeof(numbers) / sizeof(numbers[0]));
problem5(v);
for(unsigned i = 0; i < v.size(); i += 1)
{
cout << v[i] << ' ';
}
cout << endl;
return 0;
} -
Jester01
veterán
Szerintem azt akarta mondani, hogy explicit szinkronizáció nélkül nem szabad arra építeni, hogy a feldolgozás hogyan halad az egyes szálakon. Pl. attól hogy az egyik szálon gyorsabb műveletek vannak, még lehet, hogy adott körülmények között valamiért mégis megakad és a másik szál hamarabb végez.
-
Jester01
veterán
Azért nem, mert "nem egyenlő" a feltételed tehát j-vel elmegy a tömb végéig az első olyan elemnél aminek nincs párja, és onnantól már nem is találja meg a többit. Csak addig szabad előremenni amíg a másik tömb elemei kisebbek az aktuális elemnél (ha növekvő sorrendben vannak). Ahol megálltál ott pedig meg kell nézni, egyezik-e az elem és ha igen akkor hozzáadni a metszethez.
-
Jester01
veterán
-
#2086
Jester01
veterán
WonderCSabo
#2084
Jester01
veterán
válasz
WonderCSabo
#2084
üzenetére
Ez nem igaz
Kiválóan működik tagfüggvényként is, miért ne menne?Zoli133: mi okozza a problémát? Kiveszed a halmazt a map-ból, onnantól meg iterálhatsz rajta kedvedre.
const set<string>& s = ab["foo"];
for(set<string>::const_iterator it = s.begin(); it != s.end(); ++it) ... -
Jester01
veterán
válasz
bandi0000
#1959
üzenetére
Beolvasol egy teljes sort majd szétdarabolod. Egy egyszerű lehetséges megoldás (de nem túl hibatűrő):
#include <iostream>
#include <sstream>
#include <vector>
using namespace std;
int main(int, char**)
{
cout << "Enter numbers separated by spaces: ";
string line;
getline(cin, line);
istringstream s(line);
vector<int> numbers;
int x;
while(s >> x) numbers.push_back(x);
cout << "You entered " << numbers.size() << " numbers" << endl;
return 0;
} -
Jester01
veterán
A template-k már csak ilyenek. A fordítónak látnia kell a definíciót, nem csak a deklarációt (mintha ezeket te kevernéd kicsit).
Olyat lehet játszani, hogy konkrét paraméterre explicit példányosítod akkor meg fogja találni másik fordítási egységben is.Amúgy nem véletlen, hogy az új módi szerint a "headereknek" nincs .h kiterjesztése. Szegény c++ nagyon el lett barmolva, hogy az interface és az implementáció összemosódik.
-
#1459
Jester01
veterán
Lavidaloka
#1458
Jester01
veterán
válasz
Lavidaloka
#1458
üzenetére
Ha nincs meg a forráskód akkor csak reverse engineering módszerekkel lehet.
-
Jester01
veterán
válasz
Jhonny06
#1317
üzenetére
Igen, ez már közelít az igazsághoz. A fenti kód önmagában még nem lenne baj, vagyis az, hogy az x tudja írni az y viszont nem, az még nem probléma, millió olyan eset van amikor különböző pointereken keresztül különböző elérésed van, például:
char c;
char* x = &c;
const char* y = &c;Ezzel semmi baj, x-en keresztül lehet írni, y-on nem.
A gond ott kezdődik, hogy az említett struktúra módot adna olyan konverzióra aminek során a const elveszik egy pointerből. Látszólag ugye itt éppen hozzáadódik és ez biztonságosnak tűnik, de valójában egy kiskaput nyit:
char* x;
const char** y = &x;
const char* z;
*y = z;
*x = 0;Itt a z pointerről leszedtük a const-ot és az x-en keresztül olyan címre írtunk amire nincs felhatalmazásunk. Ugye *y típusa const char* és z is ez, tehát a *y = z rendben van. Viszont mivel y=&x ezért most már x is ugyanoda mutat ahová z, csak x nem const vagyis *x írható.
Mégegyszer hangsúlyoznám, nem az a baj, hogy több pointer ugyanazt a címet különböző módon éri el, hanem az, hogy egy tetszőleges const pointerből írhatót lehetne varázsolni. (Persze egy cast-tal ezt még mindig meg lehet tenni de az már más kérdés.)
-
-
Jester01
veterán
válasz
Jhonny06
#1311
üzenetére
Itt ugye nem a pointer a konstans, hanem amire a legvégén mutat (dupla indirekció után), vagyis **y nem írható.
Ez például konstans mutató és teljesen szabályos, az y maga a konstans, vagyis y nem írható:
char** const y = &x;Ez is szabályos, itt az a konstans amire az y mutat, vagyis *y nem írható:
char* const *y = &x; -
Jester01
veterán
ráadásul gyanítom, hogy olyankor az osztályt megsemmisíti, és
úgyúj példányt hoz létre a default copy construktorralÍgy van. Ha nem POD objektum, akkor valamilyen konstruktor hívásnak lennie kell, akkor is ha az std::copy használatával történik a másolás (csak az még lassabb is lehet, mivel előbb default konstruktor majd operator= hívás lesz).
-
Jester01
veterán
-
#1208
Jester01
veterán
WonderCSabo
#1207
Jester01
veterán
válasz
WonderCSabo
#1207
üzenetére
Meg azt sem tudja, hogyan kell preprocesszort futtatni
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Jester01
veterán
válasz
Brianiac
#1198
üzenetére
7) lebegőpontos számításoknál a véges pontosság, a kettes számrendszer és a kerekítési hibák miatt általában nem fog egyenlőség szigorúan teljesülni ezért tipikusan valami tolerancián belüli közelséget szokás vizsgálni.
Például:
Kérem az kör középpontjának koordinátáit (Ox, Oy):
1.1 2.2
A koordináták: (1.1;2.2)
Kérem a Pont koordinátáit (Px, Py):
1.4 2.6
A koordináták: (1.4;2.6)
Kérem a kör sugarát (r):
0.5
A kör sugara: 0.5
A körön belül van a pontHacsak így fél négy tájban el nem számoltam, ez pedig rajta van a körön.
MOD: ja most látom, hogy neked van egy felesleges if feltételed is .. ha már tudjuk, hogy nem kisebb és nem egyenlő akkor csak nagyobb lehet (kivéve persze a NaN esetet de az most elvileg nem lesz és különben sem kezeled)
-
Jester01
veterán
válasz
Brianiac
#1196
üzenetére
A lényegi kérdéshez nem tudok érdemben hozzászólni, de azért a kódhoz van észrevételem:
1) system("pause") ez a "kedvencünk" itt a fórumon, ezért azonnali főbelövés jár. Ráadásul te még a szükséges headert sem hívtad be, így le sem fordul.
2) setlocale (LC_ALL, "Hun"); ez nem tudom milyen rendszeren működik, de a szabályos locale nevek leginkább hu_HU és hasonlók. Persze visszatérési érték ellenőrzése nélkül ezt nem veszed észre. Egyébként is illik inkább a felhasználói beállításokat átvenni, továbbá célszerű akkor már wide karakteret használni.
3) Ha már iostream-et használsz, akkor a \n csúnya (persze azért működik). Helyette ajánlott az endl manipulátor.
4) A pont és kör középpont távolságnégyzetet illene kitenni egy változóba (ahogy a sugárnégyzetet is). A fordító persze úgyis kioptimalizálja, de ez így nem annyira olvasható.
5) hibakezelés nincs, a kiírt szöveg pedig megtévesztő az elvárt formátumot illetően
6) (ez nagyon halvány észrevétel) logikátlan a kör sugarát a végén bekérni, érdemesebb együtt tartani a kör jellemzőit
7) plusz pont lehetne, ha ráutaló magatartással jeleznéd, hogy ismered a lebegőpontos számítások veszélyét (egyenlőséget általában nem szabad ellenőrizni)
8) a cmath-t fölöslegesen hívod be, nem használsz belőle semmit.
9) formailag személy szerint hiányolok néhány szóközt innen-onnan, az olvashatóság jegyébenNégyzetre emelni leginkább úgy célszerű ahogy csináltad (azaz szorzással), legfeljebb csinálhatsz neki külön függvényt.
-
Jester01
veterán
válasz
peterszky
#1171
üzenetére
Egyébként igen, xmlXPathRegisterNs megoldja a problémát:
const char xml[] = "<r xmlns='http://tempuri.org/xyz'><n1><n2>x</n2></n1><n1></n1></r>";
...
xmlXPathRegisterNs(xpathCtx, (xmlChar*)"tmp", (xmlChar*)"http://tempuri.org/xyz");
xmlXPathObjectPtr xpathObj = xmlXPathEvalExpression((xmlChar*)"tmp:n1/tmp:n2", xpathCtx); -
Jester01
veterán
válasz
ArchElf
#1166
üzenetére
Nem tudom miért kell külön kérvényezni, hogy lehetőleg futtatható kódot kapjunk.
Ha jól értettem mit akar a kolléga, az nekem működik:
#include <iostream>
using namespace std;
#include <libxml/xmlreader.h>
#include <libxml/tree.h>
#include <libxml/xpath.h>
int main()
{
const char xml[] = "<r><n1><n2>x</n2></n1><n1></n1></r>";
xmlParserInputBufferPtr input = xmlParserInputBufferCreateMem(xml, sizeof(xml) - 1, XML_CHAR_ENCODING_NONE);
xmlTextReaderPtr reader = xmlNewTextReader(input, NULL);
xmlTextReaderNext(reader);
xmlNodePtr subtree = xmlTextReaderExpand(reader);
xmlXPathContextPtr xpathCtx = xmlXPathNewContext(subtree->doc);
if(xpathCtx == NULL)
{
cerr << "xpath context create failed" << endl;
return 1;
}
xpathCtx->node = subtree;
xmlXPathObjectPtr xpathObj = xmlXPathEvalExpression((xmlChar*)"n1/n2", xpathCtx);
if(xpathObj == NULL)
{
cerr << "xpath eval failed" << endl;
return 2;
}
//printXPathNodes(xpathObj->nodesetval);
cout << xpathObj->nodesetval->nodeNr << endl;
return 0;
} -
#1083
Jester01
veterán
WonderCSabo
#1082
Jester01
veterán
válasz
WonderCSabo
#1082
üzenetére
Miért őrülne meg? Az olvasási próbálkozás után a !f (ami igazából ugye f.fail()) szépen kilép. Probléma egy szál se
-
#1081
Jester01
veterán
WonderCSabo
#1080
Jester01
veterán
válasz
WonderCSabo
#1080
üzenetére
Nem, mert akkor az utolsó karaktert kétszer is feldolgozza. Példa
-
#1079
Jester01
veterán
FireKeeper
#1078
Jester01
veterán
válasz
FireKeeper
#1078
üzenetére
Pedig az jó. Mint írtam is, az a default egyébként.
#include <fstream>
int main(int argc, char *argv[])
{
std::fstream f("test.txt");
while(true)
{
char c;
f >> c;
if (!f) break;
c ^= 0x20;
f.seekp(-1, std::ios::cur);
f << c;
f.seekp(0, std::ios::cur);
}
return 0;
} -
#1077
Jester01
veterán
FireKeeper
#1075
Jester01
veterán
válasz
FireKeeper
#1075
üzenetére
Ha nem baj, hogy esetleg lassú lesz akkor read-write kell megnyitni a fájlt (ez egyébként fstream esetén default), és seekp-vel visszalépni az éppen beolvasott karakterre majd felülírni. Szabvány szerint írás-olvasás váltásnál kötelező egy seek, szóval a kiírás után, bár a pozíció az jó, mégis kell egy újabb seekp.
-
Jester01
veterán
válasz
Gyomman
#1064
üzenetére
Már csak a hibaüzenet hiányzik, no meg hogy teljes lefordítható és futtatható kódot prezentálj. Ebből ugyanis hiányzik maga a példányosítás illetve az egész F_file. Én vettem a fáradságot és értelemszerűen kipótoltam valamivel, az szó nélkül működik. Természetesen ügyeltem arra, hogy a megadott bemeneti stream és elem párosra létezzen operator>> (arra gondolok, hogy neked esetleg ez hibádzik).
#include <iostream>
#include <fstream>
#include <cstring>
using namespace std;
template <typename G>
class F_file
{
public:
F_file(const char* _utvonal, const char* _nev)
: file(0), length(0), nev(_nev), utvonal(_utvonal) {};
FILE* file;
int length;
const char* nev;
const char* utvonal;
};
template<typename G>
void operator>>(istream& in, F_file<G>& F)
{
if (F.file) fclose(F.file);
char* ttemp=new char[strlen(F.nev)+strlen(F.utvonal)+5];
strcpy(ttemp,F.utvonal);
strcat(ttemp,F.nev);
strcat(ttemp,".dat");
F.file=fopen(ttemp,"a");
G temp;
int len;
(in>>len).ignore(1); //szóközt eldobjuk
F.length+=len; //hosszt megnöveljük
while((in>>temp).ignore(1))
{
fwrite(&temp,sizeof(G),1,F.file);
}
delete [] ttemp;
}
int main(int argc, char *argv[])
{
F_file<int> f("/tmp/", "test");
cin >> f;
return 0;
}Az fwrite hívásból mellesleg hiányzott egy & jel, és úgy egészében véve sem értem mit akarsz csinálni, de ez így legalább valamit csinál
-
#1010
Jester01
veterán
Sk8erPeter
#1009
Jester01
veterán
válasz
Sk8erPeter
#1009
üzenetére
Azért van mert a csoda c++ nyelvben bizonyos dolgok kétértelműek. A te My_Mouse_Class MyMouse(); sorod egy függvény prototípus lett, mégpedig egy MyMouse függvényé ami nem vár paramétert és visszatér egy My_Mouse_Class példánnyal.
-
#1004
Jester01
veterán
WonderCSabo
#1002
Jester01
veterán
válasz
WonderCSabo
#1002
üzenetére
Vagy: if (strchr("+-*^/%", c))
-
Jester01
veterán
válasz
!wannabe
#997
üzenetére
Külső programot indít:
1. az a program lehet, hogy nem is elérhető (pl. más oprendszer, jogosultság, path)
2. ez általában lassú/erőforrásigényes, bár jelen esetben mindegy
3. nyilván a külső program valahogy megoldja, tehát te is megoldhatnád ugyanúgy
4. tipikusan a kezdők szokták használni windows-on, mert ezzel akarják elkerülni, hogy az ablak becsukódjon pedig azt nem így kell.Több most nem jut eszembe ... ja de, impotenciát okoz!
-
#969
Jester01
veterán
WonderCSabo
#968
Jester01
veterán
válasz
WonderCSabo
#968
üzenetére
wstring-be, igen.
-
#965
Jester01
veterán
WonderCSabo
#962
Jester01
veterán
válasz
WonderCSabo
#962
üzenetére
Programkódba alapból nem írunk ékezetet mert csak a baj van vele. Ha konstans kell, akkor ajánlott kiírni numerikusan.
Továbbá, unicode karakter az nem fér bele egy mezei char típusba, ahhoz wchar_t kell, és a megfelelő wide streameket kell használni. Nomeg persze kell valami hasonló setlocale mint amit a kollega írt.
Imígyen:#include <locale>
#include <iostream>
using namespace std;
int main()
{
wchar_t a=L'\xe9';
wchar_t b;
setlocale(LC_ALL, "");
wcin>>b;
if(a==b)
{
wcout<<"muxik"<<endl;
} else {
wcout<<"rossz ekezet"<< endl;
}
return 0;
} -
Jester01
veterán
válasz
!wannabe
#945
üzenetére
Hát ez gyönyörű
Mindenesetre más dolgod nincs mint fogni egy debuggert és végiglépkedni melyik P hívások futnak le. Persze ezt kézzel is csinálhatod. Pl. kezdésnek:
1. int main()-ben indulunk, 48. sor. Itt van egy U<E> példány ennek hívódik a P metódusa a következő sorban. Nézzük az hol van.
2. 42. sor. N w;w.P(); aholis N=E mivel azzal lett példányosítva. Ugrás tehát az E.P()-hez
3. 13. sor, kiíródik az E, visszatérés a hívóhoz
4. M q;q.P(); mivel itt M=M<N> és N=E ezért ugrás M<E>.P()-hez
5. 29. sor, kiíródik a B, visszatérés a hívóhozstb.
-
#938
Jester01
veterán
Berenyimiki
#937
Jester01
veterán
válasz
Berenyimiki
#937
üzenetére
Általában nincs.
-
#920
Jester01
veterán
---Lasali---
#919
Jester01
veterán
válasz
---Lasali---
#919
üzenetére
Az platformfüggő. Sima windows konzol használata esetén például SetConsoleCursorPosition.
De a legjobb lenne ha nem használnád egyáltalán. -
Jester01
veterán
válasz
mephi666
#914
üzenetére
a 41. karakter és a 44. ilyen ezrest jelölő pont
Ez igen érdekes szám lesz, mert a 41. és a 44. karakter között csak 2 számjegy van, a 42. és a 43. ... akkor az hogy lehet ezres?Ez sima szövegfeldolgozás, én tuti nem írnék rá c++ programot hanem bármilyen, regex-es cserét tudó programot használnék. Pl. sed-del így nézhet ki:
sed -r 's/([0-9]{5}).{32}([0-9]{3})\.([0-9]{3})\.([0-9]{3}).*/\1;;\2\3\4/' -
Jester01
veterán
De meg lehet oldani másképp is
Használhatod az aszinkron metódusokat (Begin*/End*) vagy indíthatsz külön szálat (thread). Progressbarhoz pedig értelmes méretű és darabszámú kisebb blokkokban írd az adatot és közben így tudod frissíteni a csíkot. (Ha a többszálú megoldást választottad, akkor ügyelve a megfelelő thread használatára.)MOD: látom épp mostanra sikerült valamit alkotnod ... ettől függetlenül amit írtam az él.
-
-
Jester01
veterán
Komolyan nem értem, hogy aki nem tudja használni msdn-t illetve google-t minek akar programozni
A windows forms-ot meg főleg nem értem hogy jön ide. Mi köze annak az ftphez?Megoldás: FtpPutFile illetve WebRequestMethods.Ftp.UploadFile
-
Jester01
veterán
Ha tényleg nem szereti a 3 paraméteres változatot akkor ott valami gubanc van a fordítási környezettel mert az összes fellelhető dokumentáció azt állítja hogy ez szabványos. Ha a környezettel nem tudsz mit kezdeni akkor nincs más hátra mint előre, és írni egy a követelményeidnek megfelelő rendezést kézzel.
-
#806
Jester01
veterán
Sk8erPeter
#805
Jester01
veterán
válasz
Sk8erPeter
#805
üzenetére
Nyilván csak azok működnek amik nem fájl-specifikusak. Az open-t még ott hívd meg amikor létrehozod a stream-et, olyankor még tudod, hogy az ifstream. Később már csak olyanokat illik használni amik sima istream-re is működnek. Ha nagyon muszáj, akkor pl. dynamic_cast segítségével (vagy valami bool adattaggal) csinálhatsz elágazást. Persze ha sok ilyen kell akkor érdemesebb inkább 2 fajta File osztály implementációt készíteni, közös őssel.
-
#803
Jester01
veterán
WonderCSabo
#802
Jester01
veterán
válasz
WonderCSabo
#802
üzenetére
Definiálnád a "megy" kifejezést? Beállít értelmes locale-t? Mert ugye mint említettem, hibakezelés nincs a programban, tehát ha nem megy azt se lehet észrevenni.
-
#801
Jester01
veterán
WonderCSabo
#800
Jester01
veterán
válasz
WonderCSabo
#800
üzenetére
Az én linuxaimon nem megy, tekintve, hogy
A locale name is typically of the form
language[_territory][.codeset][@modifier], where
language is an ISO 639 language code, territory is
an ISO 3166 country code, and codeset is a character
set or encoding identifier like ISO-8859-1 or UTF-8. -
Jester01
veterán
Háááát, ha egyszer úgyis 1000 elemű fix méretű tömbbe olvasol, akkor aztán tök mindegy utána mit varázsolsz. Totál felesleges átmásolni egy másik (immár megfelelő méretű) tömbbe.
setlocale(LC_ALL,"Hun"); ebben nem vagyok olyan biztos, hogy működik. Nálam tuti nem. Persze ha nem is ellenőrzöd a visszatérési értéket akkor sose tudod meg.
numberofstars ez jó félrevezető változónév az imperialista kémek megtévesztésére ... mivelhogy még véletlenül sem a csillagokat számolja.
if(numberoftips<=10 && numberofstars==unknownlength) itt szerény véleményem szerint mindenképp numberoftips<=10
system("pause"); ezért, ha én tanár lennék, azonnal egyest adnék...
+1: kellene egy #include <cstdlib> a (s)rand miatt.
-
-
Jester01
veterán
Az alap operator>> az éppenséggel benyel mindenféle szóközt (whitespace). Most akkor tuti, hogy vectort nem szabad használni? Mert azzal kb ennyi az egész:
#include <fstream>
#include <iostream>
#include <string>
#include <vector>
using namespace std;
int main()
{
ifstream file("teszt.txt", ios::in);
if(!file.good())
{
cout<<"Hiba a fajllal...";
return 1;
}
vector<string> words;
while(file.good())
{
string word;
file >> word;
words.push_back(word);
}
for(int i = 0; i < words.size(); i++)
{
cout <<"i: "<< i <<".: " << words[i] << endl;
}
return 0;
}
![;]](http://cdn.rios.hu/dl/s/v1.gif)
) alatt áll akkor a meghívott függvény a konstruktor vagy destruktor osztályában lévő végső override nem pedig leszármazott osztálybeli.
Miért nem jó az neked? Akkor meg implementáld újra kézzel ... de inkább ne.
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- PlayStation 5
- Veszélyben az adataid? Gond van a WD népszerű HDD-ivel
- Rezsicsökkentés, spórolás (fűtés, szigetelés, stb.)
- Xbox Series X|S
- Telekom mobilszolgáltatások
- Kínai tech-túra összefoglaló
- Vivo X200 Pro - a kétszázát!
- BestBuy topik
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- OLED monitor topic
- További aktív témák...
- BESZÁMÍTÁS! ASUS H81M-A H81 chipset alaplap garanciával hibátlan működéssel
- HIBÁTLAN iPhone 13 Pro Max 256GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3521
- HIBÁTLAN iPhone 13 mini 128GB Starlight -1 ÉV GARANCIA -Kártyafüggetlen, MS3614
- HIBÁTLAN iPhone 15 Pro Max 256GB White Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3661, 100% Akkum
- GYÖNYÖRŰ iPhone 13 mini 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3317
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest