- Milyen okostelefont vegyek?
- Samsung Galaxy Watch8 - Classic - Ultra 2025
- One mobilszolgáltatások
- Sony Xperia 1 V - kizárólag igényeseknek
- Huawei Watch GT 3 Pro - korlátolt szépség
- Külföldi prepaid SIM-ek itthon
- Hivatalosan is bemutatta a Google a Pixel 6a-t
- Xiaomi 14T Pro - teljes a család?
- Samsung Galaxy Watch7 - kötelező kör
- Okosóra és okoskiegészítő topik
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Új hozzászólás Aktív témák
-
Jester01
veterán
Pont arra gondoltam amire te.
Ahhoz, hogy ne legyen lassú az intervallumlistát lehet például bináris fában tartani. De persze adatbázisról lévén szó, ezt rá lehet bízni az adatbáziskezelőre is, index formájában.Amúgy visszatérve az első javaslatomra, még ha másodperc pontosságról is van szó és mondjuk maximum 10 napos utazásról az még mindig csak 24*3600*10/8=108kByte adat.
-
Jester01
veterán
Ha tudjuk, hogy az idők perc felbontásúak, akkor minden utazáshoz csinálni kell egy tömböt (vagy táblát) ahol percekre van bontva. Majd az összes munkát ki kell törölni. A végén pedig összeszámolni a sorokat, az lesz a tiszta utazás.
Persze a memóriatakarékosabb megoldás egy intervallumhalmaz-kezelő megírása, de az macerásabb
-
Jester01
veterán
Korrekt hálózati protokoll definíció mindig alacsony szinten, nyelvfüggetlenül adja meg a specifikációt. Például egy szimulátor program is belefutott abba, hogy lusta mód a csomag egy részét egy C struct-ból küldte el, és az igazítás (padding) miatt ez különböző lett 32 illetve 64 biten így a csomag szétcsúszott - annak ellenére, hogy az adatok benne jók voltak.
Nem értek java-hoz különösebben, de ha jól tudom van benne reflection. Az alapján akkor lehet csinálni olyan osztályt ami tetszőleges objektumot automatikusan a megfelelő formára konvertál.
-
Jester01
veterán
-
#3682
Jester01
veterán
Fire/SOUL/CD
#3681
Jester01
veterán
válasz
Fire/SOUL/CD
#3681
üzenetére
Igen, főállásban programozok.
-
#3680
Jester01
veterán
Fire/SOUL/CD
#3677
Jester01
veterán
válasz
Fire/SOUL/CD
#3677
üzenetére
Szerintem van neki egy kész konzolos alkalmazása amit nem ő írt és annak a kimenetét szeretné elkapni. Ehhez úgy kell elindítani, hogy az stdout és stderr át legyen irányítva. Hogy ezt delphiben hogyan lehet, azt nem tudom. Pl. .NET-ben van erre lehetőség a ProcessStartInfo kitöltésével:
When a Process writes text to its standard stream, that text is typically displayed on the console. By redirecting the StandardOutput stream, you can manipulate or suppress the output of a process. For example, you can filter the text, format it differently, or write the output to both the console and a designated log file. -
Jester01
veterán
-
#3672
Jester01
veterán
adamtoth91
#3671
Jester01
veterán
válasz
adamtoth91
#3671
üzenetére
Ez egy fórum, azért van, hogy beleszólj
A kérdést viszont nem egészen értem. Általános távirányításra ott a VNC vagy terminal services/remote desktop. Speciális távirányításra meg persze lehet írni programot. -
Jester01
veterán
Az egyszerű megoldás a párhuzamos portos adatvonal figyelés lenne. Ilyenkor a programnak állandóan futnia kellene, ami persze erőforráspazarlás illetve kihagyás esetén előfordulhat, hogy nem vesz észre egy eseményt (ennek veszélye persze az esemény hosszától függ). Megszakításos már jobb lenne, de ahhoz nyilván bonyolultabb a program.
Ha nekem kellene megcsinálni, akkor inkább egy mikrokontrollert használnék amitől aztán tetszőleges időközönként el lehetne kérni a listát (pl. naponta).
-
Jester01
veterán
-
Jester01
veterán
válasz
Jester01
#3519
üzenetére
Ja, viszont valgrind szólt, hogy accept hívásban a harmadik paraméter (a méret) nincs inicializálva. Ez okozhat hibát, attól függően, hogy éppen milyen véletlen adat van az adott címen.
man accept: The addrlen argument is a value-result argument: it should initially contain the size of the structure pointed to by addr -
Jester01
veterán
Külső programot használ egy egyszerű funkcióra, rossz hatékonyság, extra függőség (mi van ha nincs a PATH-ban pause?) Ráadásul nem is platformfüggetlen. A kezdő programozó meg elhiszi, hogy ez a helyes anélkül, hogy belegondolna: a pause.exe-t is megírta valaki, tehát valahogy meg lehet csinálni.
Ilyen egyszerű programoknál általában simán elég az enter-re várás (a line buffering miatt a tetszőleges billentyű már nem platformfüggetlen). Tehát egy
string tmp; cin >> tmp;
bőven jó.
-
#3175
Jester01
veterán
Dr. Romano
#3174
Jester01
veterán
válasz
Dr. Romano
#3174
üzenetére
Valami ilyesmi progit gondoltam (32bit!)
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[])
{
union { float f; int x; } tmp;
tmp.f = strtod(argv[1], NULL);
printf("%08X\n", tmp.x);
return 0;
};A 21.18-ra 41A970A4-at ad, nem tudom ez kell-e neked
-
Jester01
veterán
Gondolom a fórummotor benyelt néhány szóközt/tabot
Úgy értettem, hogy először megállapítod melyik a leghosszabb, és aztán az összeset ilyen szélességben írod ki. Ehhez nem kell a tömböket piszkálni, elég a printf formátumban megadni ezt a maximális hosszt. Persze csak akkor működik, ha végignézheted előre a kiírni szándékozott szövegeket.
#include <stdio.h>
#include <string.h>
int main()
{
const char* strings[] = { "1", "12345", "123", "123456", 0 };
int maxlen = 0;
int i;
for(i = 0; strings[i]; i++)
{
int len = strlen(strings[i]);
if (len > maxlen) maxlen = len;
}
for(i = 0; strings[i]; i++)
{
printf("%*s gyenge\n", -maxlen, strings[i]);
}
return 0;
}
./a.out
1 gyenge
12345 gyenge
123 gyenge
123456 gyenge -
-
Jester01
veterán
Nem, a little-endian esetén éppenhogy a byte[0] a legkisebb helyiérték.
Simán egy int* pointer hivatkozás és kész. Portabilis kód esetén pl. a kernel mintájára egy ''le32_to_cpu'' makrót vagy inline függvényt lehet használni ami az architektúrának megfelõen konvertál ha szükséges. -
Jester01
veterán
Ugye a kettővel osztás az egy bit léptetés. Hexa ábrázolás esetén a szomszédos jegy legalsó bitje kell még a működéshez.
Számolgatással pl. így lehet:
inline char to_hex(int v)
{
return v > 9 ? (v + 'A' - 10) : (v + '0');
}
inline int from_hex(char c)
{
return c > '9' ? (c - 'A' + 10) : (c - '0');
}
void shift(char* buffer)
{
int i;
int carry = 0;
for(i = 3; i >= 0; i--)
{
int v = from_hex(buffer[ i ]);
buffer[ i ] = to_hex((v >> 1) | carry);
carry = (v << 3) & 8;
}
}
Ha a számolgatás nem tetszik, akkor lookup táblát is lehet csinálni, pl így:
void shift(char* buffer)
{
static struct { char out[2], f; } map['G'] = {
['0'] = {''08'', 0},
['1'] = {''08'', 1},
['2'] = {''19'', 0},
['3'] = {''19'', 1},
['4'] = {''2A'', 0},
['5'] = {''2A'', 1},
['6'] = {''3B'', 0},
['7'] = {''3B'', 1},
['8'] = {''4C'', 0},
['9'] = {''4C'', 1},
['A'] = {''5D'', 0},
['B'] = {''5D'', 1},
['C'] = {''6E'', 0},
['D'] = {''6E'', 1},
['E'] = {''7F'', 0},
['F'] = {''7F'', 1}
};
int i;
int flag = 0;
for(i = 3; i >= 0; i--)
{
char c = buffer[ i ];
buffer[ i ] = map[c].out[flag];
flag = map[c].f;
}
}
Hibakezelés ezekben nyilván nincs.
Más ötlet momentán nem jut eszembe.
[Szerkesztve] -
Jester01
veterán
Szerintem ez csak azt jelenti, hogy csinálj elõször egy általános osztályt aminek egy implementációja lesz a tiéd. Helyesen elkészítve lehet újabb implementációkat csinálni amik mivel ugyannak az osztálynak a leszármazottai így azonos módon használhatók. Pl. ha én megírom a saját osztályomat ami tegyük fel nem stringben hanem egy vektorban tárolja a számjegyeket akkor ez minden további nélkül kompatibilis lesz a tiéddel (mármint ha én is az általános osztályból származtatom).
-
-
Jester01
veterán
pascalban is van ponter - igen, de a c sokkal jobban rákényszerít, hogy használd, pl. már a stringek normális kezeléséhez is elengedhetetlen
Kérdés, hogy ez jó-e. Az a tendencia, hogy a pointereket irtjuk ahol lehet és ezeket magasabb szintű dolgokkal helyettesítjük (amik C-ben nincsenek). Tehát pointerekkel vesződni ugyanúgy egyre kevésbé hasznos mint a pascal nyelv.
k*rva profik lehetnek akkor. miért nem írják meg egyenesen a másik nyelven?
Mi mondjuk nem pascal-t hanem vb-t használtunk prototipizálásra és utána írtuk át c-re. Bizonyos körülmények között szerintem ennek is van létjogosultsága (proof of concept). -
Jester01
veterán
azon y1...yk fiú felsorolva, amelyek az x-edik alatt helyezkednek el?
Igen. De nem úgy ahogy te gondolod, nem lefelé a hierarchiában. Az yi az x közvetlen gyereke.
3. minden pontnak legfeljebb egy apja lehet
Talán azért lett így leírva, mert így nem kell bele kivétel. De amúgy szerintem ekvivalens a kettõ. (A 4. tulajdonság miatt) -
-
Jester01
veterán
-
Jester01
veterán
Azt már látom, hogy a makefile az rossz, mivel nem tartalmazza a header fájlokat.
A globális változókat a kollega által írt módon kell eltüntetni. Jelen esetben nem nagy ügy, mivel a conv.c-ben jórészt azonos típusú függvények vannak és csak az outfile változóra hivatkoznak. Vagyis a következõ 5 lépést kell elvégezni:
1. a struct tag típusban a tagfunction prototípusához fel kell venni az outfilet plusz paraméternek.
2. az OUT függvénynek is be kell adni a az outfile paramétert.
3. a conv.c-ben az összes tagfunction implementációt az 1. pontnak megfelelõen át kell írni, és az OUT függvényhívásokban át kell adni a plusz paramétert.
4. a convert.c-ben a tagfunction és az OUT hívásokban is át kell adni a paramétert.
5. az infile változó az simán lehet lokális a main függvényen belül.
Nem tudom melyik lenne a 3. globális változó -
Jester01
veterán
Hacsak egyéb ok nincs rá akkor a gráfot egyszerûen csomópontokkal és belõlük induló élekkel ábrázoljuk:
class Node
{
public:
vector<Node*> Edges;
};
Ez nálam mérve 12 byte csomópontonként, az kemény 120kB. A 200000 pointer az 800kB. A legrosszabb vector overhead-del számolva is belefér 2 megába az egész (64 bites gépen max. dupla ennyi).
Ha valami egyéb információt is el kell tárolni a csomópontokról/élekrõl akkor az persze erre még rájön, de azt semmiképp nem úszod meg.
(Az éleknek az egyszerûség kedvéért nem csináltam külön osztályt.) -
Jester01
veterán
Ez a kód olyan mintha a haverom írta volna
Ész nélkül kihasználja a nyelvben lévõ lehetõségeket, de feláldozza az olvashatóságot és karbantarthatóságot. Kiváló példája annak, hogyan ne használjuk a template-eket, hacsak nem vagyunk zsenik.
Mindenesetre a dolog kb. a következõképpen mûködik:
Vektorokkal végez mûveleteket, ez gondolom nyilvánvaló. A Vector<T, N> N darab T típusú elemet tartalmaz. A VectorSum osztály az összeadás mûveletet reprezentálja.
Az elsõ összeadás operátor azt írja le, hogy két azonos elemtípusú és méretû vektor összeadható, és az eredménye ugyancsak ilyen tulajdonságú vektor lesz.
A második összeadás operátor azt mondja, hogy egy vektorösszeghez jobbról még hozzá lehet adni egy másik vektort is.
Az init és print függvények gondolom világosak.
A megvalósítandó mûveletek:
vektor + vektorösszeg: a vektorösszeg + vektor mûvelet párja, a jobb és bal oldal felcserélésével.
vektorösszeg + vektorösszeg: mint az elõzõ, csak most mindkét oldal vektorösszeg
számmal szorzás jobbról és balról: be kell vezetni egy új alapmûveletet a VectorSum mintájára, pl. így:
template<class T, long N, class V>
class ScaledVector
{
long factor;
const V &vector;
public:
ScaledVector(long f, const V &v) : factor(f), vector(v) {}
T operator[](long i) const {
return factor * vector[ i ];
}
};
Igényesebb kollegák a faktor típusát beadhatják template paraméternek, akkor majd pl. double típussal is lehet szorozni.
A Vector osztályba fel kell venni egy újabb overloadot az = operátorra, hogy ilyen ScaledVector osztályt is tudjon fogadni (ugyanúgy sima elemmásolás van benne).
Ezután már csak a szorzás operátorra kell egy overload, pl. így:
template<class T, long N>
inline ScaledVector<T,N,Vector<T,N> >
operator*(int f, const Vector<T,N> &v) {
return ScaledVector<T,N,Vector<T,N> >(f,v);
}
Illetve hasonlóképpen jobbról való szorzáshoz is.
És mivel ilyen ScaledVector objektumokat még össze is akarunk adni, hát ahhoz rá kell engedni a VectorSum-ot két ScaledVector-ra, imígyen:
template<class T, long N, class Left, class Right>
inline VectorSum<T,N,ScaledVector<T,N,Left>,ScaledVector<T,N,Right> >
operator+(const ScaledVector<T,N,Left> &l, const ScaledVector<T,N,Right> &r) {
return VectorSum<T,N,ScaledVector<T,N,Left>,ScaledVector<T,N,Right> >(l,r);
}
Egyszerû, nem igaz?
[Szerkesztve] -
#2367
Jester01
veterán
Forest_roby
#2366
Jester01
veterán
válasz
Forest_roby
#2366
üzenetére
Reggel a fenét
Az attól függ milyen build rendszert használsz. De ha belenézel a makefile-be, akkor nyilván magad is megtalálod. -
Jester01
veterán
válasz
Bazsesz
#2360
üzenetére
A szemaforok tulajdonképpen számlálók amik általában azt jelentik, hogy valami X dologból rendelkezésre áll valamennyi. A számláló növelése nem várakozik, ez csak azt jelenti, hogy több X áll rendelkezésre. Ha most jön valaki, hogy neki kellene valamennyi X, akkor a rendelkezésre álló mennyiséget az igényelt mennyiséggel csökkenteni kell, illetve ha éppen nincs elegendő, akkor várni kell.
A te feladatodra rátérve: 2 szemaforra lesz szükség, mivel a probléma szimmetrikus. Az egyik jelzi, hogy az A program írt valamit amit a B kiolvashat, illetve fordítva.
A program:
write(); /* írunk valamit */
sem_up(A); /* jelezzük, hogy A írt */
sem_down(B); /* várunk amíg B jelzi, hogy írt */
read(); /* kiolvassuk */
B program:
sem_down(A); /* várunk amíg A jelzi, hogy írt */
read(); /* kiolvassuk */
write(); /* írunk valamit A-nak */
sem_up(B); /* jelezzük, hogy B írt */ -
Jester01
veterán
válasz
windforce
#2358
üzenetére
Pl.:
for(chr = fgetc(kodolando); chr != EOF; chr = fgetc(kodolando))
{
chk = fgetc(kulcs);
if (chk == EOF)
{
rewind(kulcs);
chk = fgetc(kulcs);
if (chk == EOF) break; /* ures kulcs, vagy baj van */
}
...
Egyébiránt ellenőrzésképpen próbáld meg dekódolni az eredményt. Ha ezt megtetted volna akkor egyből láttad volna hogy nem csak a plusz karakter a baj. -
Jester01
veterán
válasz
windforce
#2355
üzenetére
Azért van, mert a feof csak azután lesz igaz, hogy megpróbáltad beolvasni az utolsó utáni byteot is. A megoldás pedig az feof helyett az fgetc visszatérési értékének ellenőrzése (EOF konstans lesz).
A kulcs fájl végének ellenőrzése ettől eltekintve is hibás, fölösleges bele a tagadás. -
#2337
Jester01
veterán
Forest_roby
#2336
Jester01
veterán
válasz
Forest_roby
#2336
üzenetére
Az union nem helyettesíti a 2 dimenziós tömböt (legalábbis az elsõ hszedben leírt feltételek szerint), csak az ide-oda konverziótól mentett volna meg.
-
#2335
Jester01
veterán
Forest_roby
#2333
Jester01
veterán
válasz
Forest_roby
#2333
üzenetére
Ha a méretét maximalizáltad, akkor sima ügy. Kiírod az új kezdõ sor(oka)t. Egyben berántod a bemenõ fájlt memóriába, megkeresed a törlendõ blokk végét (n. soremelés karakter) és onnan kezdve visszaírod.
Soronként olvasással is meg lehet csinálni. Miután kiírtad az új kezdõsorokat szépen soronként beolvasod a fájlt, de a kiírást csak a megfelelõ sor után kezded.
MOD: mellékes javítás az elõzõ hsz-hez: az 'a' betû kódja 97, mert a 65 a nagy A.
[Szerkesztve] -
#2334
Jester01
veterán
Forest_roby
#2332
Jester01
veterán
válasz
Forest_roby
#2332
üzenetére
12:00 akár AM akár PM már holnap van
union elem
{
char c;
int x;
};
...
union elem tomb[2];
tomb[0].c = 'a';
tomb[1].x = 1000;
Az a lényeg, hogy az union mezõi egymást átfedik a memóriában, tehát mindig csak az egyik használható. Hogy melyik, azt neked kell tudni. A fenti példában a tomb[0].x is helyes kifejezés, de az értékét nem lehet tudni azon túlmenõen, hogy a legalsó byte 65 lesz (az 'a' betû kódja). -
#2331
Jester01
veterán
Forest_roby
#2330
Jester01
veterán
válasz
Forest_roby
#2330
üzenetére
A kétdimenziós tömb két indexet használ: t[1][2] alakban.
A több típus tárolásához pedig nem struct, hanem union a célszerû (ha egy cellába nem kerülhet egyszerre mind a 2)
A 12:00 után az nem holnap van?
MOD: alternatív megoldás lehet egydimenziós tömb használata, az indexek megfelelõ leképezésével.
[Szerkesztve] -
Jester01
veterán
válasz
Phoenix5
#2326
üzenetére
0. Beolvasod a hőmérsékleteket egy tömbbe.
1. A kiírás innen triviális.
2. Végigmész a tömbön, minden elemre megnézve hogy 0 foknál melegebb volt-e, ezeket összeszámolod. Ha kurzor pozícionálást nem használsz (márpedig nem ajánlom), akkor a kiíráshoz egy pufferbe összegyűjtöd őket vagy pedig mégegyszer végigmész rajtuk (egyszerűbb). Ezt egy függvénybe teheted, ami paraméterben kapja, hogy hová írjon. Pl: int MelegNapok(double* adatok, double hatar, FILE* kimenet). Belül pedig ellenőrzöd, hogy a kimenet NULL-e, mert akkor nem kell kiírni. (Ez jól fog jönni az 5. pontnál.)
3. 10-szer kikeresed a leghidegebb napot úgy, hogy azt mindig kiveszed a tömbből. (De ne módosítsd az eredeti tömböt, mert kell később).
4. Egyszerű szélsőérték keresés azzal megbolondítva, hogy az értéket számítani kell nem pedig az elem maga. Figyelj arra, hogy az utolsó elemet ki kell hagyni.
5. Ha az 1-4 pontokat eleve a 2. pontban írt módon külön függvénybe tetted, akkor csak azt kell ismét meghívni a megnyitott kimenet fájl pointerét átadva.
MOD: alternatívaként rögtön írhatod párhuzamosan a fájlba és a képernyőre is.
[Szerkesztve] -
Jester01
veterán
a ciklusban az a string helyett az a[ i ]-t nézegesd inkább.
Azt nézi, csak a fórummotor benyelte. (dõlt betûs lett utána minden)
MOD: Gerghu: nem jó ötlet, hogy a cmp függvényben módosítod a kapott stringeket, szerintem írd át úgy, hogy egy másolatot csinálsz (ott, vagy pedig a replaceekezet() fvben)
[Szerkesztve] -
-
Jester01
veterán
Használd az strcoll függvényt, ha van.
Kézzel pl. úgy lehet csinálni, hogy felsorolod egy tömbbe a betűk ábécérendbeli pozícióját és onnan rendezel.
int abc[] = { ... ide kell felsorolni a pozíciókat ... };
int i;
for(i = 0; abc[a[ i ]] == abc[b[ i ]] && a[ i ] != 0; i++);
(utf-8 esetén még finomítani kell)
[Szerkesztve] -
#2287
Jester01
veterán
Forest_roby
#2286
Jester01
veterán
válasz
Forest_roby
#2286
üzenetére
Ja talán jó lesz az strcmp oda. De zárójelek nélkül, mert akkor kapod meg a címét! Igy egy függvényhívás lesz, ráadásul paraméterek nélkül. Nem is értem hogy fordulhat le, bár sikított érte a fordító.
MOD: Az az strlen-es warning is erõsen gyanús...
[Szerkesztve] -
#2285
Jester01
veterán
Forest_roby
#2284
Jester01
veterán
válasz
Forest_roby
#2284
üzenetére
word_tree = g_tree_new(strcmp());
Ez mi akar lenni?
MOD: amúgy szokás szerint jó lenne a teljes progi + makefile hogy ki lehessen próbálni.
[Szerkesztve] -
Jester01
veterán
-
#2267
Jester01
veterán
Forest_roby
#2266
Jester01
veterán
válasz
Forest_roby
#2266
üzenetére
Az a baj, hogy a tömböt lokálisan foglaltad le (a veremben lesz) és így megszűnik amikor a függvény visszatér.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ész nélkül kihasználja a nyelvben lévõ lehetõségeket, de feláldozza az olvashatóságot és karbantarthatóságot. Kiváló példája annak, hogyan ne használjuk a template-eket, hacsak nem vagyunk zsenik.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Apple MacBook
- Miért vezet mindenki úgy, mint egy állat?
- Milyen okostelefont vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Mini-ITX
- Tesla topik
- CADA, Polymobil, és más építőkockák
- Fejhallgató erősítő és DAC topik
- Autós topik
- Témázgatunk, témázgatunk!? ... avagy mutasd az Android homescreened!
- További aktív témák...
- Asus B85M-Plus + I3-4170 Processzor
- QNAP TS-932X - 10 gigabites NAS - 5x4TB HDD + 4x400G SSD
- SPIRIT OF GAMER Race Wheel PRO 2 kormány minden tartozékával mekgímélt állapotban eladó!
- Playstation 5 Drive Edition 825GB (CFI-1116A), 6 hónap garanciával, Bp-i üzletből eladó!
- Apple Watch Series 7 41mm NIKE GPS
- Apple iPhone 12 64GB Kártyafüggetlen 1Év Garanciával
- Konzol felvásárlás!! Xbox Series S, Xbox Serries X
- HIBÁTLAN iPhone 11 Pro 256GB Space Grey -1 ÉV GARANCIA - Kártyafüggetlen, MS2937, 100% Akksi
- ÁRCSÖKKENTÉS Dell Latitude E6320 notebook eladó
- Lenovo ThinkPad X13 Yoga i5-10310U 16GB RAM 256GB SSD 13.3 FHD Touch 2in1
Állásajánlatok
Cég: FOTC
Város: Budapest