Questo sito utilizza cookies, anche di terze parti, per mostrare pubblicità e servizi in linea con il tuo account. Leggi l'informativa sui cookies.
Username: Password: oppure
C/C++ - Ordinamento per data
Forum - C/C++ - Ordinamento per data - Pagina 4

Pagine: [ 1 2 3 4 5 ] Precedente | Prossimo
Avatar
nessuno (Normal User)
Guru^2


Messaggi: 6066
Iscritto: 03/01/2010

Segnala al moderatore
Postato alle 20:50
Sabato, 20/01/2018
Hai pensato, per il problema originale della union, a scrivere la struct così

typedef struct
{
    uint8_t giorno;
    uint8_t mese;
    uint16_t anno;
}data_struct;

?


Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
---
Il grande studioso italiano Bruno de Finetti (uno dei padri fondatori del moderno Calcolo delle probabilità) chiamava il gioco del Lotto Tassa sulla stupidità.
PM Quote
Avatar
Poggi Marco (Member)
Guru


Messaggi: 968
Iscritto: 05/01/2010

Segnala al moderatore
Postato alle 23:29
Sabato, 20/01/2018
Testo quotato

Postato originariamente da nessuno:

Hai pensato, per il problema originale della union, a scrivere la struct così

typedef struct
{
    uint8_t giorno;
    uint8_t mese;
    uint16_t anno;
}data_struct;

?



???
AldoBaldo, in un post, ha detto di aver invertito i membri delle struct.
Perché complicarsi la vita con le union? Non sono state create per questo scopo.
In ogni modo, esiste la struct tm, o time_t già pronto.
( Ovviamente con la libreria < crono > )

Ultima modifica effettuata da Poggi Marco il 21/01/2018 alle 9:57
PM Quote
Avatar
AldoBaldo (Member)
Expert


Messaggi: 533
Iscritto: 08/01/2015

Segnala al moderatore
Postato alle 0:54
Domenica, 21/01/2018
Sì, nessuno, ci avevo pensato e anche provato, infatti in quel modo funziona. Però, vista l'origine del problema, direi che si tratta di un aggiramento, non di una soluzione. Per questo ho tentato un'altra strada abbandonando l'idea della union. Peccato, perché mi era sembrata una gran genialata! :heehee:

Marco, il sistema del <time.h> usa una struttura molto più "ingombrante" perché ci immagazzina la data e l'ora, conteggiandole in secondi. Inoltre, come ti ho detto, per i sistemi a 32 bit siamo prossimi alla data di scadenza imposta dalla quantità di secondi massima rappresentabile. Altro inoltre oltre all'inoltre originale, non puoi spingerti più indietro del 1970. Mi verrebbe da inoltrarmi oltre nella catena degli inoltre, ma sembra già la fiera dell'Est! :rotfl:

Adesso che ci penso, avendo usato uint16_t per l'anno, anche la mia struct impone un limite minimo (anno 0) e un limite massimo (anno 65535). Forse avrei fatto meglio a usare un int16_t, per poter andare dall'anno -32768 all'anno 32765. Oh, intendiamoci, sono solo speculazioni fini a se stesse, tanto per ...passare il tempo! :rotfl:

P.S. Questa sera mi sento spiritoso. S'è notato?

Ultima modifica effettuata da AldoBaldo il 21/01/2018 alle 0:57
PM Quote
Avatar
tuttodiMC (Normal User)
Expert


Messaggi: 326
Iscritto: 29/10/2012

Segnala al moderatore
Postato alle 15:57
Domenica, 21/01/2018
Vista la complessità non troppo elevata del problema, non si potrebbe semplicemente riscrivere una funzione di sort che ordini per vettori paralleli? Oppure, non si potrebbe dichiarare e riempire un array di pair di tipo <char*, int> e ordinare quello? Correggetemi se mi sbaglio.

PM Quote
Avatar
nessuno (Normal User)
Guru^2


Messaggi: 6066
Iscritto: 03/01/2010

Segnala al moderatore
Postato alle 16:32
Domenica, 21/01/2018
In realtà la union non complica le cose, anzi.

Quello che viene fatto in

((uint32_t)anno)<<16)|(((uint32_t)mese)<<8)|((uint32_t)giorno

la union la fa in maniera "nativa" (tenuto presente il corretto ordine dei campi nella struttura).

Quindi, la utilizzerei senza problemi.


Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
---
Il grande studioso italiano Bruno de Finetti (uno dei padri fondatori del moderno Calcolo delle probabilità) chiamava il gioco del Lotto Tassa sulla stupidità.
PM Quote
Avatar
AldoBaldo (Member)
Expert


Messaggi: 533
Iscritto: 08/01/2015

Segnala al moderatore
Postato alle 19:16
Domenica, 21/01/2018
Non so se scrivo una stupidata, però "a naso" temo che neppure la versione con gli shift si possa considerare "sicura" rispetto alla questione delle endianness... sbaglio?

PM Quote
Avatar
nessuno (Normal User)
Guru^2


Messaggi: 6066
Iscritto: 03/01/2010

Segnala al moderatore
Postato alle 20:12
Domenica, 21/01/2018
Se sai su quale architettura stai operando, puoi scrivere codice ragionevolmente corretto.

Ovviamente, se vuoi scrivere del codice "universale", devi usare delle #if per valutare il tipo di CPU e operare di conseguenza.


Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
---
Il grande studioso italiano Bruno de Finetti (uno dei padri fondatori del moderno Calcolo delle probabilità) chiamava il gioco del Lotto Tassa sulla stupidità.
PM Quote
Avatar
lumo (Member)
Expert


Messaggi: 444
Iscritto: 18/04/2010

Segnala al moderatore
Postato alle 15:46
Lunedì, 22/01/2018
Sebbene la discussione abbia toccato temi "interessanti", direi che siamo andati un po' off-topic rispetto al problema originale dell'ordinamento.
Nel caso ci fosse ancora interesse a discutere di union e endianess, invito ad aprire un nuovo topic.

PM Quote
Pagine: [ 1 2 3 4 5 ] Precedente | Prossimo