Windows XP Beta per AMD 64

Windows XP Beta per AMD 64

In coincidenza del lancio di Athlon 64 da parte di AMD, Microsoft rilascia una release beta di Windows XP che supporta tale nuova tecnologia

di pubblicata il , alle 13:48 nel canale Programmi
AMDMicrosoftWindows
 
I migliori sconti su Amazon oggi
-7%

FRITZ!Repeater 600 Edition International, Ripetitore - Wi-Fi extender fino a 600 Mbit/s (2,4 GHz), Mesh, Access Point, Interfaccia in italiano

29.49 27.49€ Compra ora
-7%

Lefant M330Pro Robot Aspirapolvere Lavapavimenti con Mappatura, Navigazione dToF, Zona vietata, Evitamento ostacoli PSD, Aspirazione 5000Pa, 150 minuti, Pulizia programmata, Alexa/APP/WiFi,Nero

Compra ora
-24%

ECOVACS DEEBOT T50 PRO OMNI Gen2 Robot Aspirapolvere Lavapavimenti, (Migliorato da T30 PRO), 21000 Pa, Spazzola Laterale Estensibile e Lavapavimenti, Aggiunta Automatica Soluzione Detergente

499.00 379.00€ Compra ora
75 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
ilsensine02 Ottobre 2003, 09:06 #61
Originariamente inviato da cdimauro
Allora, premesso che di standard non si tratta, come ho già detto, perché le specifiche del linguaggio non entrano (giustamente) nel dettaglio implementativo

Sono convenzioni implementative; non ufficialmente standard ma ormai standard "de facto".

(insomma: non mi piace la facilità con cui si scambiano interi e puntatori. :rolleyes.

A volte è necessaria, per evitare una atroce aritmentica dei puntatori. Probabilmente le memory management dll ne fanno largo uso.

Andando decisamente oltre, non capisco perché nei linguaggi non siano stati introdotti degli strumenti sintattici o dei tipi per specificare delle quantità "standard".

Ad esempio int[8] (nuova sintassi) o int8 (nuovo tipo, nessun cambiamento di sintassi)...

Perché se ne sono "accorti dopo". In effetti si sta parlando solo da un pò di estensioni allo standard per ovviare a questi problemi; avrai notato che ormai tutti i compilatori mettono a disposizione cose tipo uint_8_t, int16_t o nomi più o meno esotici. Ora tutto sta a mettersi d'accordo su "come chiamarli"
cionci02 Ottobre 2003, 09:24 #62
Sì...anche VC++ ha:

__int8, __int16, __int32, __int64....
ilsensine02 Ottobre 2003, 10:27 #63
Sì infatti, ognuno ha i suoi nomi

Questo vuol dire che se vuoi scrivere un programma portabile, devi inventarti la tua ennesima definizione e typedeffare su quella in base al compilatore...

Tra parentesi, ho avuto tempo fa un problema originato da un compilatore che considerava di default char come unsigned char...ok ingenuità mia, ma DANNAZIONE CHI CI VA A PENSARE?
Raven02 Ottobre 2003, 11:16 #64


... miii... mi fate sentire un ignorante totale...

cionci02 Ottobre 2003, 11:40 #65
Originariamente inviato da ilsensine
Tra parentesi, ho avuto tempo fa un problema originato da un compilatore che considerava di default char come unsigned char...ok ingenuità mia, ma DANNAZIONE CHI CI VA A PENSARE?

Quale ? Bellina la faccina
cionci02 Ottobre 2003, 11:43 #66
Bella recensione, l'avete vista ?
http://www.aceshardware.com/read.jsp?id=60000256
ilsensine02 Ottobre 2003, 12:09 #67
Originariamente inviato da cionci
Quale ? Bellina la faccina

gcc cross-compiatore per arm.
Hanno fatto quella scelta in quanto gli unsigned char sull'arm sono più veloci dei signed. Non lo sapevo e mi mandava a puttane una mia dwt grrrr
cdimauro02 Ottobre 2003, 14:10 #68
Originariamente inviato da ilsensine
Sono convenzioni implementative; non ufficialmente standard ma ormai standard "de facto".

Beh, diciamo di sì, ma limitandoci ai sistemi più diffusi...
A volte è necessaria, per evitare una atroce aritmentica dei puntatori.

Bene o male il C possiede un'ottima gestione dei puntatori (è il suo cavallo di battaglia), per cui l'esigenza di passare da intero a puntatore e viceversa è veramente limitata, almeno per l'esperienza che ho avuto in merito...
Probabilmente le memory management dll ne fanno largo uso.

Un gestore di memoria comunque deve tenere conto del tipo di architettura sul quale sta girando, per cui utilizzare qualche "trucchetto sporco" penso sia normale...

Perché se ne sono "accorti dopo".

Se non erro l'ANSI C è stato standardizzato intorno al 1985, per cui hanno avuto ampii margini di tempo per sistemare questa "rogna"...
In effetti si sta parlando solo da un pò di estensioni allo standard per ovviare a questi problemi;

Per è un problema molto vecchio e conosciuto: magari non interessava più di tanto prima, ma con tutte le architetture che sono fiorite dagli anni '80 in poi, sarebbe stato meglio metterlo fra le priorità...
avrai notato che ormai tutti i compilatori mettono a disposizione cose tipo uint_8_t, int16_t o nomi più o meno esotici.

Sì perché, appunto, un programmatore ha bisogno di certezze per poter lavorare con tranquillità...
Ora tutto sta a mettersi d'accordo su "come chiamarli"

Non a caso parlavo di estensioni rientranti nello standard...
cdimauro02 Ottobre 2003, 14:11 #69
Originariamente inviato da cionci
Bella recensione, l'avete vista ?
http://www.aceshardware.com/read.jsp?id=60000256

Non ho ancora avuto tempo!!!
cdimauro02 Ottobre 2003, 14:13 #70
Originariamente inviato da ilsensine
gcc cross-compiatore per arm.
Hanno fatto quella scelta in quanto gli unsigned char sull'arm sono più veloci dei signed. Non lo sapevo e mi mandava a puttane una mia dwt grrrr

Discrete Wavelet Transformation? Ma guarda un po', in questi giorni dovrei iniziare uno stage + tesi di laurea all'SGS Thompson che riguarda l'implementazione del codec JPEG2000...

Comunque anche per l'attributo signed/unsigned vale il discorso di cui sopra...
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
Notizie
tutte le news »
^