Newsgroup: it.comp.lang.c++
Titolo: resize che comando?

con che comando posso effettuare il resize di una immagine?
Grazie ciao

 con che comando posso effettuare il resize di una immagine?
std::set_image_size(dx,dy)
o no?
;)
-- 
Luc.

 Luc.

 ma e' un resize effettivo o un resize visivo
E' un resize avulso... da questo NG. 
-- 
Luc.

 dimensioni dell'immagine???
Magari esistessero cose del genere nello standard. Secondo me potrebbero
esistere benissimo, magari (come ho già detto qualche giorno fa) non
strettamente obbligatorie per un compilatore full compliant, in quanto
sono concetti slegati dalla singola piattaforma (qualunque sistema
operativo che supporti la grafica supporta immagini di qualche tipo).
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 ;)
LOL
Ciao
Eido

 
Beh, tanto per non perdere l'abitudine di essere OT :-)
Io creerei una libreria standard ma facoltativa, come hai detto tu,che
definisca i concetti di pixel, colore, insomma, la base della grafica,
che sia portabile ovunque esista un dispositivo che possa funzionare a
pixel, ovverosia praticamente dappertutto oggi. Anni fa i dispositivi
erano davvero orientati ai caratteri, anche perchè disponevano di così
poca memoria che rappresentare un qualcosa a pixel sarebbe stato troppo
dispendioso...ma ormai secondo me si potrebbe pensare di introdurre
qualcosa per la grafica. Come hai detto tu, una parte della libreria
standard potrebbe essere opzionale, ovvero funzionare solo sulle
piattaforme dove è supportata, ma funzionare dappertutto allo stesso
modo. Non credo sia impossibile...
Chiedo scusa per l'OT


 Io creerei una libreria standard ma facoltativa, 
Se è standard non può essere facoltativa.
Ciao
Azathot



Pechè no? Una libreria che sia possibile solo dove l'hardware lo
permette, ovvero oggi nel 70% e più dei dispositivi su cui dovrebbe
girare il C++, e che però funzioni allo stesso identico modo su tutte le
piattaforme software/hardware che la supportano. Tra l'altro, col
meccanismo delle eccezioni secondo me è molto facile segnalare mancanza
di supporto hardware per una certa combinazione, ad esempio di profindità
di colore o risoluzione...insomma, una cosa del genere in C era
praticamente impossibile e inutile, visto il target primario del C, ma in
C++ penso che sia quantomeno utile a molti, anche se di certo non
indispensabile

 Se è standard non può essere facoltativa.
Eppure, come è già stato detto da qualun'altro, ci sono già cose nello
standard intrinsecamente legate a determinati sistemi. Ad esempio, che
ne pensi della funzione time() e compagnia su un sistema senza orologio
interno? Secondo me una parte dedicata alla grafica di base farebbe solo
bene alla portabilità di un numero maggiore di applicazioni che
attualmente si devono appoggiare alle più eterogenee librerie esterne.
Forse in questo discorso sono un po' pragmatico e poco teorico però, in
fin dei conti, uno standard serve nel mondo reale, o sbaglio?
EMG


 
Beh, nell'informatica il pragmatismo è fondamentale...purtroppo ancora
non è una scienza completamente esatta, nel senso che la teoria e la
pratica non sempre si conciliano, spesso un concetto teorico ineccepibile
in pratica è impossibile, o molto poco vantaggioso...o sbaglio?

 in pratica è impossibile, o molto poco vantaggioso...o sbaglio?
No, dici bene. Sembra che ancora non siano molto chiare le relazioni tra
le forze, spesso opposte, presenti in un progetto informatico e quindi
si deve a volte essere più creativi che tecnici. :-)


 interno?
Tutti i dispositivi con microcontrollore hanno un contatore interno (non é
difficile visto che il clock ce l'hanno.
Comunque non escluderei che in alcune piattaforme questo genere di funzione
non venga eseguita. A dire il vero su alcune piattaforme mancano i
compilatori C++.

I concetti di pixel e colore sono indipendenti dall'hardware, ma se
consideri uno standard di colori, un display monocromatico come lo piloti?
Se inventassero un monitor ad "alta densità di pixel" tale da raggiungere
risoluzioni del tipo 8000x6000 in 10 pollici ci penseresti tu a rendere
portabile tutti i codici che sono stati definiti "standard".
Per avere una idea di come andrebbe affrontato il problema, magari
occorrerebbe studiare Java, ma occorre tenere in considerazione che in C++
non esiste una macchina virtuale. Infine rinnovo l'idea che questo non é un
problema, in quanto esistono librerie compilate su piu' piattaforme, e si
possono usare quelle senza scomodare il C++ standard.
Magari si potrebbe cercare di definire una serie di librerie
multipiattaforma gratuite ed estremamente slegate dalla piattaforma, cosi'
come fa Java, ovviamente vanno generate per i vari sistemi operativi (nel
vostro caso andrebbe modificato il compilatore ed il linker di ogni sistema
operativo e questo é molto più complesso).


 
E se fossero anche standard, cioè approvate dal comitato ISO, che male ci
sarebbe?

 sarebbe?
Finche' C++ e librerie rimangono ben separate nulla.

> Io creerei una libreria standard ma facoltativa
Se deve essere facoltativa se ne fa volentieri a meno...
-- 
Andrea Laforgia
Gioca a Tetris !
http://www.geocities.com/andrealaforgia/downloads.html

 definito un linguaggio non portabile. Questo e' il problema.
Scrivi un programma che usa la new. Lo esegui su una macchina funziona.
Lo esegui su un'altra e ti lancia un'eccezione. Hai definito anche in
questo caso un linguaggio non portabile?
EMG


 Se deve essere facoltativa se ne fa volentieri a meno...
La grafica rimane troppo legata alla piattaforma. Sono molto scettico sulla
fattibilità di uno standard del genere, tuttavia la presenza di troppe
librerie grafiche confonde e disturba molte persone. Si impara una libreria
si usa per qualche mese e dopo occorre impararne un'altra per fare le stesse
cose su un'altra piattaforma. E' sconfortante e irritante.

 
Non la penso così, d'altronde la mia opinione non conta molto... :-)


 
Io credo che il problema sia la definizione di portabilità. PEr me è
portabile un programma in grado di essere compilato senza modifiche su
tutte le piattaforme che hanno un compilatore per quel linguaggio. Se
invece per portabile intendiamo un programma che gira davvero dapertutto,
beh, allora non dipende più dal linguaggio, ma dal particolare programma.
Oppure si implementa una macchina virtuale come quella Java. Altrimenti,
se io ho un PC con 256 Mb di ram e alloco con new un array che me la
riempie praticamente tutta, se vado ad eseguire lo stesso programma su un
386 con 4 Mb di ram naturalmente non va, è normale!

Il punto é un diverso. Il fatto che il programma lanci una eccezione a
seconda dell'hardware é comprensibile, ma lo fa con dei concetti in comune
tra le varie piattaforme, la stessa cosa non é valida per la grafica. Vi
sono piattaforme che non sanno neanche cosa sia la grafica. La grafica non
può essere una specifica di linguaggio, deve rimanere all'interno delle
librerie e definibile come una astrazione attraverso il linguaggio di
programmazione.
Nel caso da te citato il linguaggio rimane portabile, il programma no perché
non c'é memoria disponibile. Se inserisci a priori la grafica come un
concetto C++ anche il linguaggio stesso non sarà più portabile e ciò non é
possibile.
Si può invece cercare di costruire una serie di classi standard che
riguardano la grafica e inserirle all'interno di librerie da fornire con
tutti i compilatori in commercio, ma il risultato sarebbe uno sforzo enorme
per ottenere una serie di librerie troppo generaliste per essere efficienti,
e tutti continuerebbero ad utilizzare quelle ottimizzate sulle varie
piattaforme e forse é per questa ragione che nessuno ha mai pensato di fare
questo lavoro.
Emanuele


La grafica rimane troppo legata alla piattaforma. 
Appunto.
-- 
Andrea Laforgia
http://www.geocities.com/andrealaforgia
/* shakespeare.c */
#define QUESTION ((bb) || (!bb))

 questo lavoro.
Non ne sarei tanto sicuro...


 Io credo che il problema sia la definizione di portabilità.
Certo. Comunque io non ho mai parlato di portabilità (credo, e se l'ho
fatto è stato per sbaglio) nella mia proposta. Ho solo detto che la
standardizzazione di alcune cose (non solo la grafica) oggi largamente
utilizzate farebbe solo bene all'informatica. Mentre la situazione
caotica che c'è ora fa bene solo al mercato. Tutto qui.


> Io credo che il problema sia la definizione di portabilità.
Hai centrato il punto.
Puoi avere un linguaggio portabile e un programma portabile (nei suoi
limiti).
Tuttavia con un linguaggio portabile si puo' scrivere un programma non
portabile, ne l senso che il tipo di risorse che richiede sono eccessive per
la maggior parte dei computer.
Da questo punto di vista mi sono espresso male riguardo l'eccezione dei
programmi cosi' come EMG ha fatto notare.
Tra la sintassi e i programmi in mezzo ci sono le librerie. Queste possono
essere portabili, tuttavia a causa dei differenti hardware in circolazione
(dai mainframe ai palm ai telefonini)  e' molto difficile costruire una
libreria e bollarla come standard, perche' la domanda successiva sarebbe:
standard per chi?
Da qui la ragione per cui secondo me e' meglio separare il C++ dalla grafica
e affidarsi alle librerie oggi in circolazione. Certo che la situazione oggi
non e' bella. Ci sono troppe librerie proprietarie e spesso compilatori
commerciali che non seguono gli standard  e rendono la vita molto complicata
a chi vuole avere un background di programmazione molto vario e
multipiattaforma.
Ciao
Emanuele

 non é valida per la grafica.
Spero che il punto si senta malgrado tutto a suo agio :-)
Non sono d'accordo con cio' che dici: ci sono sicuramente
tutta una serie di concetti come FrameBuffer e operazioni
sia vettoriali che matriciali su di esso (tra cui il resize)
che possono sicuramente essere definiti su qualsiasi
piattaforma.
Un oggetto FrameBuffer potrebbe essere tranquillamente
rappresentato come un vettore anche se la sottostante
memoria grafica fosse o assente o ad accesso non lineare
cosi' come un'operazione di base come l'allocazione di
memoria puo' essere in C++ ridefinita.
Insomma, terrei distinto il piano della logica nel quale
ogni concetto modellato e' in linea di principio portabile,
dal piano "fisico" che coinvolge dispositivi particolari.
In fondo anche i valori streamoff restituiti da tellg non
offrono, che io sappia, molte garanzie :-)
Ciao
Gian Michele

 
Infatti, la risposta era alla tua risposta!:-)
Io credo che non faccia bene nemmeno al mercato perchè alla fine non è
libera concorrenza, è solo confusione...

 
Forse a livello puramente teorico hai ragione, sarebbe meglio tenere
separate le due cose. Ma purtroppo l'informatica si distacca sempre dalla
teoria pura, e l'hai detto tu stesso che oggi la situazione è quella che
è.

 (non é difficile visto che il clock ce l'hanno.
???
es.
Hitachi serie H8S
Dov'è il real time clock???
-- 
Gerolamo