[C++] paar integers aan elkaar plakken

[Intrepidity]

Ik moet een paar datums met elkaar gaan vergelijken. De ene datum zit in een integer als ddmmjjjj, de andere datum zit in een struct met 3 integers (dag, maand, jaar). Om deze te vergelijken moet ik dus de 3 integers uit de struct aan elkaar plakken. Het moet wel een integer blijven dus dingen als sprintf enzovoort zijn niet handig.
Iemand een idee? Simpel probleempje maar je moet het maar net weten

[Verwijderd]

Ik begrijp dus dat de codering gewoon de decimale vorm is, dus dat het getal 26102005, zegge zesentwintig miljoen honderd-en-twee-duizend zesentwintig, de datum van vandaag voorstelt? (M.a.w. er wordt niet ingewikkeld met bits gecodeerd, en er zijn b.v. getallen zoals 11132005 die niet geldig zijn, m.a.w. er zitten gaten in de reeks).

Dan lijkt het me heel eenvoudig: Doe dag maal een miljoen, tel daarbij de datum maal duizend op, en tel daarbij het jaar op.

[Janoz]

Je kunt hoeveelheden natuurlijk niet 'plakken'. Wat je wel zou kunnen doen is 'shiften'. binair shiften is redelijk gebruikelijk, maar hier zul je 'decimaal' moeten shiften. Dat klinkt ingewikkeld, maar het komt er gewoon op neer dat je met vermenigvuldigen met 10 je getal een positie naar links verschoven is. Doe dit een paar keer, tel wat dingen op en klaar.


Blijft natuurlijk staan waarom je uberhaupt een ddmmjjjj veld opslaat in een enkele integer. Het is immers geen 'hoeveelheid'.

[Intrepidity]

Janoz schreef op woensdag 26 oktober 2005 @ 15:51:
Blijft natuurlijk staan waarom je uberhaupt een ddmmjjjj veld opslaat in een enkele integer. Het is immers geen 'hoeveelheid'.

Dat staat in een databestand waarin dat nou eenmaal zo staat, daar mag ik zelf helaas niks aan veranderen..

Nem0's oplossing werkt perfect, danku

[ Voor 13% gewijzigd door Intrepidity op 26-10-2005 16:00 ]

[Janoz]

Dat iets in een databestand zo staat betekent toch niet dat je het ook in je programma zo moet gebruiken?

Daarnaast doelde ik niet op het ddmmjjj formaat, maar op het opslaan hiervan in een integer. Het is geen integer. Een string zou logischer zijn. Vergelijk het met een telefoon nummer. Dat zijn ook allemaal cijfers, maar het geheel is geen getal. Maar eigenlijk hoor je dit gewoon bij het inlezen van de data te converteren naar een datum formaat. Aangezien je het met een struct vergelijkt neem ik aan dat er al een datum formaat beschikbaar is. Waarom converteer je het ingelezene dan niet naar dat formaat?

[Bergie]

Ik zou die datum vanuit dat bestand ook in een struct of liever nog een aparte datum class inlezen. Dan kan je daar eventueel nog een methode aan toevoegen die de datum vergelijkt met een andere datum.

[Intrepidity]

Bergie schreef op woensdag 26 oktober 2005 @ 16:34:
Ik zou die datum vanuit dat bestand ook in een struct of liever nog een aparte datum class inlezen. Dan kan je daar eventueel nog een methode aan toevoegen die de datum vergelijkt met een andere datum.

Ben in principe net begonnen met C++, ben nog niet aan classes/OO toegekomen.. eerst file I/O maar eens 100% onder de knie krijgen

[prototype]

BartXP schreef op woensdag 26 oktober 2005 @ 18:01:
[...]

Ben in principe net begonnen met C++, ben nog niet aan classes/OO toegekomen.. eerst file I/O maar eens 100% onder de knie krijgen

Hehe, mjah, even terugkomend op je origineel 'probleem'. Als je die 'intgers aan elkaar wil plakken' is dit dan misschien niet handiger: YYYYMMDD ?
Zo is het op significantie van de eenheden gedaan zeg maar, en kun je de ene datum vergelijken met de ander in welke er b.v. groter is.

[renechaos]

je kunt in c++ ook een memberfunctie voor die struct maken om een integer te vergelijken met die struct.
bv een =operator maken maakt het wel makkelijker.

[ Voor 5% gewijzigd door renechaos op 27-10-2005 12:21 ]

[.oisyn]

Dat lijkt me een slecht ontwerp, je kunt een datum nou eenmaal niet vergelijken met een int. Maak dan een conversiefunctie zodat je een int om kunt zetten naar een datum, zodat je 2 datum objecten met elkaar kunt vergelijken.

[Verwijderd]

Als je een datum in een int wilt opslaan moet je het in een bepaalde eenheid stoppen. Neem bijv. milliseconden vanaf een bepaald tijd (1-1-1970 00:00). Op die manier kun je veel makkelijker rekenen en converteren.

[.oisyn]

Het is een datum, geen tijdsstip, dus het aantal milliseconden sinds 1970 lijkt me een beetje overkill. Daarnaast kun je met een 32 bits int dan maar 2³² / (24 * 60 * 60 * 1000) = 49.71 dagen aan informatie kwijt

[Verwijderd]

@oisyn: Dan neem je het aantal dagen vanaf 1 januari 1970. Om te rekenen (plus en min 1 dag) is veel makkelijker op die manier.
Maar 32 bits was inderdaad fout, moest een 64 bits int zijn (unix tijd).

[Hydra]

Janoz schreef op woensdag 26 oktober 2005 @ 16:09:
Daarnaast doelde ik niet op het ddmmjjj formaat, maar op het opslaan hiervan in een integer. Het is geen integer. Een string zou logischer zijn.

Je slaat het OF in een fatsoenlijke datetime struct op, OF je doet het op de huidige manier en vergelijkt gewoon die twee ints. In een string stoppen heeft geen enkel nut, en is gewoon minder efficient dan een int gebruiken.

Gezien het niveau van z'n vraag denk ik niet dat we moeten gaan zitten nitpicken.

.oisyn schreef op donderdag 27 oktober 2005 @ 13:18:
Het is een datum, geen tijdsstip, dus het aantal milliseconden sinds 1970 lijkt me een beetje overkill.

En laat dat nou net zijn wat de meeste datetime classes doen. Maar dan wel in een long. En bovendien wordt vaak met ticks gewerkt i.p.v. milliseconden.

2^64 ms = 500.000.000+ jaar.

[Woy]

Hydra schreef op donderdag 27 oktober 2005 @ 16:31:
[...]
En laat dat nou net zijn wat de meeste datetime classes doen. Maar dan wel in een long. En bovendien wordt vaak met ticks gewerkt i.p.v. milliseconden.

2^64 ms = 500.000.000+ jaar.

Ja DataTime functies wel maar voor een Date formaat is het nogal onzinnig om het met milliseconden te doen.

[.oisyn]

Hydra schreef op donderdag 27 oktober 2005 @ 16:31:
[...]


Je slaat het OF in een fatsoenlijke datetime struct op, OF je doet het op de huidige manier en vergelijkt gewoon die twee ints. In een string stoppen heeft geen enkel nut, en is gewoon minder efficient dan een int gebruiken.

Opslaan is wat anders dan het in het programma gebruikte interne datastructuur. Het moge duidelijk zijn dat je dan idd geen string gebruikt, tenzij om te pretty printen ("Donderdag 27 oktober 2005")

Maar dan wel in een long

Je bedoelt een 64 bits int natuurlijk, een long zegt weinig aangezien het aantal bits daarvan niet vast ligt (en het op de hedendaagse 32 bits architecturen over het algemeen gewoon 32 bits is)

Verder: wat rwb zegt.

[Hydra]

rwb schreef op donderdag 27 oktober 2005 @ 16:39:
Ja DataTime functies wel maar voor een Date formaat is het nogal onzinnig om het met milliseconden te doen.

Sure, maar waarom zou een API een aparte Date en Time class hebben? Het doet er verder ook gewoon niet toe.

.oisyn schreef op donderdag 27 oktober 2005 @ 17:08:
Opslaan is wat anders dan het in het programma gebruikte interne datastructuur. Het moge duidelijk zijn dat je dan idd geen string gebruikt, tenzij om te pretty printen ("Donderdag 27 oktober 2005")

'Opslaan' doe je ook in het geheugen, dat bedoelde ik. Hij heeft een int met een datumwaarde, hij vraagt om een methode een date struct om te zetten naar een dergelijke int. Laten we dan niet gaan zitten nitpicken.

Je bedoelt een 64 bits int natuurlijk, een long zegt weinig aangezien het aantal bits daarvan niet vast ligt (en het op de hedendaagse 32 bits architecturen over het algemeen gewoon 32 bits is)

Ik ben compleet Java/C# gebaseerd, en longs zijn daar (uitzonderingen daargelaten) 64 bit. En aangezien het prima duidelijk was wat ik bedoelde (2^64 ms = 500.000.000+ jaar, dat deel wat jij gemakshalve maar weggelaten hebt) snap ik niet helemaal waarom die reactie nodig is. Als ik over 2^64 begin hoop ik dat je snapt waar ik 't over heb.

[ Voor 4% gewijzigd door Hydra op 27-10-2005 18:15 ]

[Janoz]

Hydra schreef op donderdag 27 oktober 2005 @ 16:31:
Je slaat het OF in een fatsoenlijke datetime struct op, OF je doet het op de huidige manier en vergelijkt gewoon die twee ints. In een string stoppen heeft geen enkel nut, en is gewoon minder efficient dan een int gebruiken.

Het punt is meer dat het als String in het bestand staat. Een conversie naar een datum type is dan natuurlijk de eerste en meest logische keus (Zelfs een struct met 3 ints is al een datum type). Mocht je dat niet doen dan vind ik het persoonlijk logischer om het dan maar als string te laten. Juist omdat naast de waarde, ook de positie van de verschillende digits van belang is.

[.oisyn]

Hydra schreef op donderdag 27 oktober 2005 @ 18:14:
Ik ben compleet Java/C# gebaseerd, en longs zijn daar (uitzonderingen daargelaten) 64 bit. En aangezien het prima duidelijk was wat ik bedoelde (2^64 ms = 500.000.000+ jaar, dat deel wat jij gemakshalve maar weggelaten hebt) snap ik niet helemaal waarom die reactie nodig is. Als ik over 2^64 begin hoop ik dat je snapt waar ik 't over heb.

Voel je niet aangevallen, dit is een C++ topic en mensen zouden uit jouw reactie de onjuiste conclusie kunnen trekken dat een C++ long 64 bits is, wat lang niet altijd waar is.

[Verwijderd]

Janoz schreef op donderdag 27 oktober 2005 @ 19:21:
[...]


Het punt is meer dat het als String in het bestand staat. Een conversie naar een datum type is dan natuurlijk de eerste en meest logische keus (Zelfs een struct met 3 ints is al een datum type). Mocht je dat niet doen dan vind ik het persoonlijk logischer om het dan maar als string te laten. Juist omdat naast de waarde, ook de positie van de verschillende digits van belang is.

Als je het in een string opslaat dan kun je zo moeilijk data met elkaar vergelijken, en dat is nou net iets wat de topic starter wil.
Door het gewoon op te slaan als een eenheid (milliseconden of dagen maakt voor de discussie m.i. weinig uit) kun je veel makkelijker rekenen en vergelijken. Zo'n struct is alleen handig voor presentatie van de data.

[Janoz]

Dat zeg ik toch?

[Verwijderd]

Gezien het feit dat de TS weinig ervaring heeft met OO en C++ programmeren is het gebruiken van het formaat in YYYYMMDD in een integer toch prima? Je kunt zo gewoon de ene datum rechttoe rechtaan met een andere datum vergelijken.

Het is misschien netter om een klasse datum te maken (of te gebruiken) waar datum opgeslagen zit als een eenheid geteld vanaf 1970 en waarin > en < operators zijn overgeload, maar is dat voor de TS ook echt direct noodzakelijk?

[Verwijderd]

Verwijderd schreef op vrijdag 28 oktober 2005 @ 11:05:
Gezien het feit dat de TS weinig ervaring heeft met OO en C++ programmeren is het gebruiken van het formaat in YYYYMMDD in een integer toch prima? Je kunt zo gewoon de ene datum rechttoe rechtaan met een andere datum vergelijken.

Het is misschien netter om een klasse datum te maken (of te gebruiken) waar datum opgeslagen zit als een eenheid geteld vanaf 1970 en waarin > en < operators zijn overgeload, maar is dat voor de TS ook echt direct noodzakelijk?

Hoewel YYYYMMDD al een stuk beter is als DDMMYYYY ben ik het niet met je eens. Immers hoe kun je nou twee zulke datums met elkaar vergelijken:

C++:

  int d1 = 20050331;
  int d2 = 20050901;
  int d3 = d2-d1;
  std::cout << "Verschil: " << d3;

Wat heb je hier aan? Helemaal niks terwijl dit:

C++:

  int d1 = 584328; // aantal dagen vanaf 1-1-1970
  int d2 = 588433; // idem
  int d3 = d2 - d1;
  std::cout << "Verschil: " << d3;

wel een zinnige vergelijking is. Voor je presentatie dien je echter een conversie te maken, maar die functies zitten al in de stl.

[ Voor 4% gewijzigd door Verwijderd op 28-10-2005 11:28 ]

[Verwijderd]

Verwijderd schreef op vrijdag 28 oktober 2005 @ 11:27:
[...]

Hoewel YYYYMMDD al een stuk beter is als DDMMYYYY ben ik het niet met je eens. Immers hoe kun je nou twee zulke datums met elkaar vergelijken:

C++:

  int d1 = 20050301;
  int d2 = 20050931;
  int d3 = d2-d1;
  std::cout << "Verschil: " << d3;

Wat heb je hier aan? Helemaal niks terwijl dit:

C++:

  int d1 = 584328; // aantal dagen vanaf 1-1-1970
  int d2 = 588433; // idem
  int d3 = d2 - d1;
  std::cout << "Verschil: " << d3;

wel een zinnige vergelijking is. Voor je presentatie dien je echter een conversie te maken, maar die functies zitten al in de stl.

Ik zie nu dat we allebij aannames maken. Ik ga er van uit dat de TS enkel wil weten welk tijdstip eerder in de tijd plaats vond en jij gaat er van uit dat de TS het verschil tussen beide data wil weten.
Wat de TS precies wil weten we eigenlijk niet. Beide vallen immers ophet kopje vergelijken.
Gezien het feit dat applicaties over tijd nieuwe eisen krijgen en dus veranderd moeten worden is jouw methode natuurlijk veel beter. Echter, daarvoor is het ook belangrijk dat je OO kunt toepassen. Bovendien, als het een klein tooltje van een middag werk wordt, is het maar de vraag of het niet gewoon wordt vervangen als de eisen veranderen? (al bestaat het gevaar dat zo'n optie niet wordt overwogen en dat ze toch met je snel in elkaar geflanste code gaan doorhannesen).

Eigenlijk moet de TS zich gewoon verdiepen in OO en C++, maar ik weet niet op welke schaal en onder welke tijdsdruk de TS werkt. In ieder geval heeft hij in het topic nu genoeg input om over na te denken

[Verwijderd]

Verwijderd schreef op vrijdag 28 oktober 2005 @ 11:32:
[...]

Ik zie nu dat we allebij aannames maken. Ik ga er van uit dat de TS enkel wil weten welk tijdstip eerder in de tijd plaats vond en jij gaat er van uit dat de TS het verschil tussen beide data wil weten.
Wat de TS precies wil weten we eigenlijk niet. Beide vallen immers ophet kopje vergelijken.
Gezien het feit dat applicaties over tijd nieuwe eisen krijgen en dus veranderd moeten worden is jouw methode natuurlijk veel beter. Echter, daarvoor is het ook belangrijk dat je OO kunt toepassen. Bovendien, als het een klein tooltje van een middag werk wordt, is het maar de vraag of het niet gewoon wordt vervangen als de eisen veranderen? (al bestaat het gevaar dat zo'n optie niet wordt overwogen en dat ze toch met je snel in elkaar geflanste code gaan doorhannesen).

Eigenlijk moet de TS zich gewoon verdiepen in OO en C++, maar ik weet niet op welke schaal en onder welke tijdsdruk de TS werkt. In ieder geval heeft hij in het topic nu genoeg input om over na te denken

Helemaal mee eens...

[Verwijderd]

Janoz schreef op woensdag 26 oktober 2005 @ 16:09:
Dat iets in een databestand zo staat betekent toch niet dat je het ook in je programma zo moet gebruiken?

Daarnaast doelde ik niet op het ddmmjjj formaat, maar op het opslaan hiervan in een integer. Het is geen integer. Een string zou logischer zijn. Vergelijk het met een telefoon nummer. Dat zijn ook allemaal cijfers, maar het geheel is geen getal. Maar eigenlijk hoor je dit gewoon bij het inlezen van de data te converteren naar een datum formaat. Aangezien je het met een struct vergelijkt neem ik aan dat er al een datum formaat beschikbaar is. Waarom converteer je het ingelezene dan niet naar dat formaat?

Of je kan het converteren naar juliaanse datum, dan kun je met long variasbelen werken. Het grote voordeel is dat je dan het verschil tussen 2 data kan berekenen door de 2 variabelen van elkaar af te trekken.

[Verwijderd]

In mijn voorgaande post ging ik uit van de VB 16 bits integer, die te klein is om de juliaanse datum in op te slaan. Maar in C++ is de integer 32 bits en kan dus wel de juliaanse datum bevatten.

[farlane]

Verwijderd schreef op zondag 30 oktober 2005 @ 22:16:
In mijn voorgaande post ging ik uit van de VB 16 bits integer, die te klein is om de juliaanse datum in op te slaan. Maar in C++ is de integer 32 bits en kan dus wel de juliaanse datum bevatten.

In de meeste gevallen wel ja. Maar de uitspraak 'in C++ is de integer 32 bits' is niet correct.

[Verwijderd]

farlane schreef op maandag 31 oktober 2005 @ 09:14:
[...]


In de meeste gevallen wel ja. Maar de uitspraak 'in C++ is de integer 32 bits' is niet correct.

Daar heb je gelijk in, hoe het precies zit weet ik ook niet, maar ik geloof dat op een 32 bits platform integers 32 bits zijn, zodat een integer berekening in een (processor) stap gaat.
Maar wat ik dus wou zeggen, om een juliaanse datum te kunnen op slaan is een variabele nodig van minimaal 32 bits groot.