Newsgroup: it.comp.macintosh
Titolo: Borland e i "nuovi" MacIntel ... x Sviluppatori ... "informati" ... :-)

Salve a tutti,
c'è qualcuno che ha notizie in merito?
Uso Delphi fra le altre cose ed ultimamente ho dovuto necessariamente
"migrare" verso
Visual Studio ... devo interfacciarmi spesso e volentieri a MS SQL
Server ...
So che esisteva ( esiste ... ) Kylix per Linux del quale non è mai
stato fatto il porting
per PPC ... troppo tempo e risorse da investire ...
Delphi ( almeno fino alla 7 ) è un ottimo tool di sviluppo e mi
dispiacerebbe doverci
rininciare ... viste le nuove prospettive architetturali dei nuovi Mac
secondo Voi sarà
possibile che questa volta Borland si decida e porti il suo
meraviglioso Delphi anche
da "noi" ... sarebbe uno stupendo passo avanti ...
attendo news ...
Saluti

 sarebbe uno stupendo passo avanti ...
Possibile forse. Ma non credo. Dove le alternative serie ci sono hanno
floppato (in pratica su Win si sono piazzati perchè il concorrente
diretto era VB, e grazie tante).
Se poi parliamo della versione upgradata a .Net, su MacOS bisognerebbe
anche vedere quale è lo stato di mono *effettivo* (ovvero se sarebbe in
grado di prendersi su le librerie di borland).
Non ho news. Ma diciamo che non ci conterei troppo.
-- 
L'idiozia trascende il mezzo con cui viene espressa.

 Non ho news. Ma diciamo che non ci conterei troppo.
non mi resta che aspettare Mono ... in quest' ultima reliese 1.1.13 se
non erro danno anche la compatibilità con IronPython ... altro motivo
in + ... è un pò che vorrei dedicarmi a Python ... ma mi manca sempre
il tempo ... tra il lavoro e l'uny che si protrare per le lunghe ...
avrei bisogno dei gioni di 48 ore ... sarre FerPetto! che è meLio di
PerFetto! ...
:-)

:

Per me il processore non conta assolutamente nulla in questo contesto,
soprattutto per una software house che aveva già in casa Kylix.
Non c'è il mercato, Kylix per dire è stato un mezzo fallimento sotto un
punto di vista puramente economico (se non erro è stato dismesso no?),
fossi in te ci farei una croce sopra, si tratterebbe di portare Kylix e
wrapparlo attorno ad OSX, e se va a finire come per Kylix è un mezzo
disastro IMHO. 
  ngw

 in + ... è un pò che vorrei dedicarmi a Python ... 
Ma per farlo basta che apri il terminale e scrivi "python" senza bisogno
di mono o che....


 di mono o che....
gia... ma non da' soddisfazione... e poi dov'e' l'icona? <g>
-- 
Le aquile non volano a stormi

 corto...circuitati? intendi +=, /= etc? :)
ehm no intende quando scrivi A OR B
se A e' true B non viene valutato stessa cosa con A AND B (e A false)

 se A e' true B non viene valutato stessa cosa con A AND B (e A false)
ah... comodissimo, ma prono a utilizzi "da hacker"


 ah... comodissimo, ma prono a utilizzi "da hacker"
???
e' solo una ottimizzazione

 e' solo una ottimizzazione
uhm... mai visto costrutti simili?
//...
int altrimenti_fai_questo()
{
   // fa qualcosa
   return 1;
}
//...
if (se_va_bene || altrimenti_fai_questo())
{
   //etc. etc.


 uhm... mai visto costrutti simili?
si, che hanno di strano? 

 if (se_va_bene || altrimenti_fai_questo())
Uso pratico standard:
BOOL isDir;
if ([[NSFileManager defaultManager] fileExistsAtPath:forseUnaDirectory
isDirectory:&isDir] && isDir) {
   // forseUnaDirectory esiste ed e' una directory
}
 - ∞

A me risulta che Delphi abbia gli operatori "cortocircuitati". Infatti 
se scrivo:
if (funzione1) or (funzione2) then
...
e funzione1 ritorna true, funzione2 non viene eseguita.
Ciao,
Fabrizio
uliano ha scritto:


 e funzione1 ritorna true, funzione2 non viene eseguita.
possibile, ma dillo a Enrico, l'affermazione e' sua ,)

 A me risulta che Delphi abbia gli operatori "cortocircuitati".
Allora hanno cambiato la semantica del Pascal. Una particolarità di
Pascal era proprio la mancanza dei cortocircuitati.
Comunque Delphi supporta entrambe le cose (giusto per fare un po' di
confusione aggiuntiva):
Complete versus short-circuit Boolean evaluation
The Delphi compiler supports two modes of evaluation for the and and or
operators: complete evaluation and short-circuit (partial) evaluation.
Complete evaluation means that each conjunct or disjunct is evaluated,
even when the result of the entire expression is already determined.
Short-circuit evaluation means strict left-to-right evaluation that
stops as soon as the result of the entire expression is determined. For
example, if the expression A and B is evaluated under short-circuit mode
when A is False, the compiler won't evaluate B; it knows that the entire
expression is False as soon as it evaluates A.
A me un linguaggio che cambia radicalmente semantica a seconda di uno
switch di compilatore mi sembra una minchiata anche più grossa... boh. 


 ah... comodissimo, ma prono a utilizzi "da hacker"
No. Fondamentale per scrivere codice compatto *e* sicuro.
Per esempio in C puoi fare una cosa
check_bound && check_something
all'interno di un while/for. In pratica se sei fuori dall'array il
secondo check (che andrebbe a leggere in un'area di memoria non valida)
non viene eseguito. 
Se non hai il cortocircuito devi scrivere
while(check_bound)
  if (check_something)
che dal mio punto di vista è più prolisso e meno leggibile.
Evidentemente vista la diffusione del corto circuito (che permette anche
diverse ottimizzazioni) la faccenda deve essere stata preferita da
molti.


 =:-ooo
Ti stanno sulle balle? :)


 switch di compilatore mi sembra una minchiata anche più grossa... boh.
Nah, dai, e` normale!
helen:~ alex$ python -c'print 2/3'
0
helen:~ alex$ python -Qnew -c'print 2/3'
0.666666666667
helen:~ alex$ 
Quando un linguaggio introduce delle novita` (come il / nontroncante in
Python, ad esempio) e` sacrosanto introdurre compiler switches per
abilitarle (a tutta prima) e poi compiler switches per disabilitarle
(per un bel po' dopo che le nuove feechurz sono divenute default).
Se Object Pascal ha fatto la stessa scelta relativamente alla natura
cortocircuitante o meno di and/or, ha fatto benone.
Alex

 macche', mi sconvolge che non ci siano
Beh, abbiamo scoperto che li hanno aggiunti. ;)


 (per un bel po' dopo che le nuove feechurz sono divenute default).
Continuo a pensare che la cosa non mi finisce di piacere, specie se
rompe molto codice (e la feature di Delphi potenzialmente lo fa, voglio
dire cambia proprio tutta la forma degli alberi).


 > A me un linguaggio che cambia radicalmente semantica a seconda di uno
 > switch di compilatore mi sembra una minchiata anche più grossa... boh.
Non per polemizzare, ma la maggior parte dei linguaggi/ambienti possono 
cambiare la semantica. Guarda le opzioni di compilazione del C del C++ 
di Visual Studio, per non parlare del gcc.
Per quanto riguarda il C ci sono almeno tre standard da selezionare.
Ciao,
Fabrizio
Enrico Franchi ha scritto:


 macche', mi sconvolge che non ci siano
Conta che in VB nessun operatore e' shortcircuited, si e' dovuto
aspettare .NET...
E li' hai due varianti e puoi scegliere quella che vuoi (And e Or senza
corto circuito, AndAlso e OrElse col corto circuito).
A me pare una capperata.
 - ∞




 A me pare una capperata.
Fa sorridere, ma almeno è una certezza.


while(check_bound)
  >if (check_something)
si poteva scrivere
while(check_bound && check_something)
e si risparmiava una riga ... :-)
Secondo Voi con il cambio di architettura ci saranno più tool di
sviluppo anche sulla nostra piattaforma?
Non mi interessa che sia Pascal, C#, Python o che dir si voglia a me
interessa un tool di sviluppo alla "Delphi" che mi permetta di produrre
codice compilabile e "runnabile" anche sulle altre piattaforme ... una
sorta di RealBasic
... "evoluto" però!
Un tool grafico con compilatore e al momento della compilazione si
scelglie la piattaforma di destinazione
OSX
Linux
Winzoz
Sun
ecc ecc

 Sun
secondo me?
secondo me no

 scelglie la piattaforma di destinazione
Ma perchè proprio compilato... ad ogni modo se le di cui sotto sono le
tue esigenze non vedo perchè non usa Python + QT /Python + wx.


 non vedo perchè non usa Python + QT /Python + wx.
Perchè al momento sono più le occasioni di mettere mano via web (
.NET )
o via rete con un applicazione StandAlone su MS SQL che le tempistiche
di realizzo sarebbero tropo lunghe con la combinata Python + QT /Python
+ wx.
Con Delphi e .NET devo solo preoccuparmi di gestore cosa sta dietro
senza preoccuparmi troppo che una determinata combobox piuttosto che
una editext sia collegata al DB, o la faccio in VisualMode o "al volo"
da codice.
Sì si potrà fare sicuramente anche con la suddetta accoppiata ma non
in tempi produttivi quanto quelli che si ottengono con Delphi...
mio malgrado questa per me è una grande ammissione ... per il momento
quando devo lavorare per inerfacciami a MS SQL devo necessariamente
utilizzare Delphi che oltre a facilitarmi di molto e produttivo in
termini di velocità.
Con il suddeto problema non è altretanto produttivo realBasic che non
ha i driver nativi per MS SQL e appoggiandosi agli ODBC anvhe con
quelli a pagamento ci sono "fortissime" limitazioni ci ho sbattuto il
muso questa estate ... e ne ho scoperti ilimiti ...
continuo a sperare profondamente in Mono ...
.-)

 termini di velocità.
Ma è proprio necessario MS SQL?


 A me pare una capperata.
Se non sbaglio viene dal famoso linguaggio Ada, parto sommo degli
Informatici, dove lo spelling e` "and then" e "or else" rispettivamente.
Alex

 piacere per forza :))
E quindi cosa proporresti?  Che un linguaggio non possa cambiare MAI, ma
debba eternamente restare inchiodato all'esatta semantica della
primissima implementazione o standard?  O che, se cambia, non ci possa
essere nessun supporto di compatibilita` col passato, che garantisce
durante la transizione di poter continuare noninvasivamente a compilare
codice "legacy"?  Secondo me entrambe le opzioni sarebbero assurde.
Alex

 Ma è proprio necessario MS SQL?
Non c'è niente di necessario ... ma non posso far cambiare il parco
macchine o fregarmene della licenza pagata dal cliente per MSSQL.
Molto spesso ci sno già applicativi che lo utilizzano quindi anche i
nuovi prelevano ed elaborano i dato che ci sono sopra ...

 primissima implementazione o standard? 
Intanto bisogna vedere un po' cosa cambia e che cosa "rompe" il
cambiamento (tu dirai "con gli switch in se non rompe nulla").
Da parte mia avrei preferito un'"aggiunta" ad un cambiamento. Ovviamente
questo richiede che le cose vengano pensate a lungo, altrimenti ci si
trova con un linguaggio ingestibile in breve tempo.
Io poi non sviluppo linguaggi. Non mi interesso nemmeno tanto di questa
problematica, a me interessa "analizzare" programmi [ e tristemente non
è possibile farlo con il linguaggio che più mi piace ].
In effetti sui linguaggi dinamici la semantica stessa (appena
consideriamo un po' di libreria, probabilmente non nel linguaggio
stesso, a seconda di come è fatto il linguaggio) è abbastanza mutevole
di suo. Questo è fondamentalmente è inevitabile.
Ma su un linguaggio statico non avere le possibilità espressive di un
dinamico e contemporaneamente non avere le certezze che sarebbero
teoricamente possibili... non è una cosa che mi faccia impazzire. Tutto
qui.
Poi chiaramente il più noto fra questi linguaggi e il suo figlioccio non
hanno manco la semantica totalmente definita e uno se ne fa una ragione.


 >> Sì con Delphi lo sapevo che si poteba fare ...
 >> in Pascal --> while(check_bound and check_something)
 >
 > None. Non puoi farlo, non con la stessa semantica. È proprio li
 > l'inghippo, non in tutti i casi puoi effettivamente farlo.
Scusami, non ho capito: cosa non puoi farlo?
A proposito di freepascal: è compatibile con Delphi (almeno fino ad una 
certa versione), per cui ha la maggior parte delle caratteristiche in 
comune, compresa la valutazione ottimizzata delle espressioni logiche.
Inoltre esiste una versione per OSX ed è integrabile negli xtools.
Comunque, personalmente amo Objective-C e Cocoa, anche se secondo me 
dovrebbero rendere gli xtools un po' più RAD di come sono ora.
Ciao,
Fabrizio
Mc Osten ha scritto:


 dovrebbero rendere gli xtools un po' più RAD di come sono ora.
Forse si. Io mi ci trovo parecchio bene, ma non faccio testo.
Sostanzialmente non sopporto gli IDE.


 hanno manco la semantica totalmente definita e uno se ne fa una ragione.
Le certezze sarebbero possibili ma totalmente inutili.
Pensa agli assiomi di un gruppo.  Puoi dedurre da essi se il gruppo ha
un numero pari o dispari di elementi?  No, non c'e` modo.  Aaargh, una
certezza che sarebbe possibile e invece non ci viene data, disastro!!!
E allora perche` l'algebra astratta NON ha una teoria dei "gruppi pari"
distinta da quella dei "gruppi dispari" e magari un'altra separata per i
"gruppi infiniti"?  Perche` dagli assiomi di un gruppo non puoi neppure
dedurre se e` finito o infinito?!
La teoria delle categorie, l'hai fatta?  Se si`, posso dare esempi anche
piu` pepati...!-)  (Se no, e puoi ancora infilarla in curriculum, fallo,
fuor di polemica: sta all'algebra astratta come essa sta alla matematica
"volgare" delle scuole medie, insegna il valore dell'astrazione a
livello assolutamente orbitale, e` la cosa piu` mind-exploding che ho
imparato per conto mio dopo aver lasciato l'universita`, dove trent'anni
fa non la insegnavano proprio... beh, la logica modale ci va vicino, in
termini di farti esplodere il cervello, ma per qualche ragione non mi ha
mai arrapato altrettanto, boh).
Alex

 Sostanzialmente non sopporto gli IDE.
E` bello vedere che i dinosauri non si estingueranno con la mia
generazione, pero`!-)  Stamane partecipavo a un dibattito di SDForum su
Python e fra le domande c'era "quale IDE usate".  Gli altri, Eclipse,
ecc.  Io: vi + shell.  (Gli Emacsisti intanto deridevano me quanto gli
altri;-).  Ma Xcode mi sembra molto usabile.  Certo, se e` valido solo
per quegli ormai-pochi che non sopportano le IDE, brutto segno!-)
Alex

Come già detto a Enrico, lo puoi fare nel modo piu assoluto:
if (length(miastringa)>10) and (miastringa[11]='A') then
	xxxx
Considerando che gli indici stringa in Delphi iniziano da 1, la seconda
parte non verrà mai eseguita se la lunghezza di miastringa è minore
di 10.
 > Forse si. Io mi ci trovo parecchio bene, ma non faccio testo.
 > Sostanzialmente non sopporto gli IDE.
A parte l'interface builder, xtools è poco piu' che un editor. Non credo
che si possa facilmente fare a meno di un editor.
PS: sono nuovo e anche stupito dalla quantità di messaggi che vengono 
postati ogni giorno su questo newsgroup, è difficile stargli dietro...
Ciao,
Fabrizio
Mc Osten ha scritto:


 macchine o fregarmene della licenza pagata dal cliente per MSSQL.
Quindi si, è necessario. Non era una critica, era una domanda
sull'ambiente in cui devi lavorare. 


 Alex
Io Eclipse non riesco ad usarlo (alla faccia del mio professore di ing.
software che ha tentato per un anno a farmelo usare per fare i suoi
stupidi esercizi con i pattern...)
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 era una domanda sull'ambiente in cui devi lavorare.
Purtroppo a volte ... "molte" ... devo ...
.-)

 piu` pepati...!-) 
Qualcosa si. Non tantissimo purtroppo. Ho seguito di recente un
seminario che mirava a riformulare la topologia tutta all'interno della
teoria delle categorie.
Interessante, purtroppo troppo poco tempo e alla fine ne abbiamo visto
poco, oltre che esserci stancati molti.
Generalmente fra i corsi di matematica previlegio i corsi di logica,
quindi non mi stupirebbe che approfondirà le categorie. Purtroppo non
avuto troppo le mani libere nel triennio[0]. Speriamo che nel biennio le
cose vadano diversamente.
Per dire in un corso da tre crediti su Teoria degli Insiemi per fare un
po' di giochetti con le successioni di Goodstein mi sono dovuto fare a
casa da solo paginate di lavoro "extra" per andare più alla svelta,
lasciando poi fuori cose interessanti come la dimostrazione formale del
teorema di Kirby e Paris.


 di 10.
Stavamo parlando di Pascal. E il Pascal tradizionale tu stesso hai detto
che non funziona come Delphi.
Dopo di che, sarebbe disturbo quotare correttamente in modo da mantenere
facile la discussione da seguire?


 già spiegato ... ha i suoi limiti ...
Anche perchè i programmatori non *vogliono* programmare in modo
corretto.


Mc Osten ha scritto:
 > Stavamo parlando di Pascal. E il Pascal tradizionale tu stesso hai detto
 > che non funziona come Delphi.
 >
 > Dopo di che, sarebbe disturbo quotare correttamente in modo da mantenere
 > facile la discussione da seguire?
Chiedo scusa! Spero non ti abbia rovinato la giornata per questo ;-)
Pascal "originale" è morto e sepolto. Quando si parla di Pascal, si 
parla, a mio avviso, delle implementazioni attuali.
Ciao,
Fabrizio
Mc Osten ha scritto:


 di più.
A dimostrare di piu`, sempre (se gli assiomi aggiunti sono tali e non
gia` teoremi della teoria precedente), ma non tutti gli assiomi sono
'cognati', infatti non vedi una teoria dei gruppi finiti pari e una dei
gruppi finiti dispari; potresti dimostrare di piu` con l'assioma del
numero finito e dispari di elementi, ma non in modo 'sensato' rispetto
al resto della teoria.
Quindi non si specifica mai TUTTO, come invece vorresti che facessero i
linguaggi di programmazione, ma una serie accuratamente calibrata di
insiemi MINIMALI di assiomi, lasciando non specificato quel tanto che
basta per la generalita`, proprio come i linguaggi di programmazione
fanno nella realta` (ma di questi ti lamenti, di come e` strutturata
l'algebra astratta no, o com'e`?-)
Mi ricorda gli alti lai del Wittgenstein ventenne del Tractatus rispetto
alla profondita` e maturita` del Wittgenstein cinquantenne delle
Untersuchungen, ma forse sono parabole che ciascuno deve seguire
personalmente nel corso della traiettoria della sua vita;-).
Alex

 lavorando con Cocoa, glade wxglade per gtk e wx, qtdesigner indovina per
Certamente, molti buoni progettisti di GUI pensano in modo visuale e
quindi preferiscono usare di questi strumenti (indipendentemente dal
linguaggio di programmazione poi usato per "dar vita" alla interfaccia).
Alex

 per quegli ormai-pochi che non sopportano le IDE, brutto segno!-)
io mc + vim + shell
-- 
()_() | NN KAPISCO XK' CELLHAVETE T'ANNTO CN ME SL         | +----
(o.o) | XK' SKRIVO 1 P'HO VELLOCE MA HALL'ORA DITTELO      | +---+
'm m' | KE SIETE VOI K CI HAVVETE PROBBLEMI NO PENSATECI   |  O  |
(___) | HE SENZA RANKORI CIAOOOO                           |
                    raffaele punto salmaso at gmail punto com

 lavori con QT ci metti comunque il tempo necessario per apprendere QT).
non ho mai usate QT ...
Comunque graSSie dlle delucidazioni ... sarà ora che comnci a
frequentare iclp ... .-)

 per quegli ormai-pochi che non sopportano le IDE, brutto segno!-)
Anche io lo trovo ben fatto.


 Chiedo scusa! Spero non ti abbia rovinato la giornata per questo ;-)
No, ma se procedi allo stesso modo mi chiedo se non mi stai prendendo
per il culo. :)


 frequentare iclp ... .-)
Puoi chiedere anche di Postgres li.


 no, che non si estingueranno :) (me 30 anni)
*nonno*!
-- 
22,5

 
Ma cosa sbaglio?
PS: scusa sono nuovo!
Fabrizio

 Vale anche per wx o qualunque altra cosa. Era un esempio.
saluti

 PS: scusa sono nuovo!
Nessun problema allora. Avevi il nick che mi ricordava un altro (e che
non era novellino).


 Hai un link diretto?
Al dibattito?  No, non l'hanno filmato, era solo dal vivo...
Alex

 Paragone diretto con MS SQL io come dicevo non uso MS SQL.
Ho programmato anche quello, ormai sono un tot di anni (puo` darsi che
sia molto cambiato di recente), ma: a differenza di altri robi MS lo
trovai un prodotto valido, sempre parlando da programmatore e non da
DBA.  Sentivo (se ben ricordo) dai DBA che l'amministrazione e` tutta
GUI oriented, che facilita i novellini ma sta veramentre sul gozzo al
DBA esperto (pero` e` anche vero che Oracle non sa proprio fare GUI
semidecenti, in confronto persino MS e` brava).
Mi dicono che al giorno d'oggi PostgreSQL gira benino anche su Windows
ma non ho davvero esperienze in merito; personalmente, se un povero
disgraziato e` condannato (certo per karma molto brutto accumulato in
vite precedenti) a girare un DB enterprise su Windows, gli suggerirei MS
SQL sulla base della mia limitata esperienza, proprio come gli
suggerirei IBM DB2 se gira su mainframe IBM.  Suggerirei certamente
PostgreSQL su qualsiasi Linux o BSD, non saprei se suggerire PostgreSQL
o Oracle per Solaris, HPUX o simili... forse Oracle ha ancora piu`
potenziale ma ci vogliono eccellenti DBA, mica cascano dal cielo...
(Su MacOSX Server non ho molta esperienza, ho usato PostrgreSQL su
MacOSX normale, ma solo per sviluppare e programmare, mai tenuto in
piedi un vero DB di produzione in MacOSX Server quindi nunzo`).
Alex

 *nonno*!
'stardo :D
non rigirare il coltello nella piaga
Raffaele che arriverai anche tu sarai nonno :P


 22,5
Ma dai...
-- 
 
www.filacchione.it
 
 "If you're dumb, surround yourself with smart people. If you're smart,
  surround yoursef with smart people who disagree with you."

 Raffaele che arriverai anche tu sarai nonno :P
Ma come scrivi? L'arteriosclersi avanza, eh?


 Ma come scrivi? L'arteriosclersi avanza, eh?
ROTFL! :)


 Ma dai...
Perchè? Non sono mai stato esplicito, ma nemmeno tanto reticente.
Se ci pensi ho detto più volte che sono alla triennale e che sono in
tesi/dovrei cercare di laurearmi...
[ poi sono in tesi, ma non ho ancora fatto moltissimo, visto che ho un
tot di esami da finire.... ]


 tot di esami da finire.... ]
Ah, allora faccio sempre in tempo ad avere ragione ! :D


 piedi un vero DB di produzione in MacOSX Server quindi nunzo`).
Questo mi incuriosisce ... visto che non ho un buon ricordo di MySQL
... senza SP, viste, cataloghi ... ( comunque buono per farsi le ossa
... )
E' free? o a pagamento?
grazie

 Ah, allora faccio sempre in tempo ad avere ragione ! :D
Porti rogna? :)


 E' free? o a pagamento?
Libero e più che libero. Licenza BSD. Se hai bisogno di "supporto
commerciale" viene offerto anche quello (ovviamente a pagamento).


 Porti rogna? :)
Moi ? Mai.. :D


 piedi un vero DB di produzione in MacOSX Server quindi nunzo`).
Nemmeno io :)
Ho tutto su FreeBSD però.
  ngw

 E' free? o a pagamento?
MySQL non mi piace, ma PostgreSQL e` tutta un'altra cosa; l'unica cosa
che hanno in comune e` di essere gratis.
Alex

 piedi un vero DB di produzione in MacOSX Server quindi nunzo`).
Sarebbe carino sapere se presenta lo stesso problema di MySQL...
problema che Oracle non ha.


 printf("%d %d\n", x++, ++x);
Cavolo è vero!!!
Escuzione sotto Win: 1 1
Escuzione sotto Linux (FC4): 1 2
Come mai l'operatore '++' non ha un comportamento standard?

 wrote:

Ce l'ha.  Ma in una singola espressione e` vietato imporre molteplici
"side effects" sulla stessa variabile (o anche imporne uno solo e
pretendere di usare la variabile "effettata" sempre entro la stessa
singola espressione); inoltre l'ordine in cui vengono valutati gli
operandi dell'espressione e` generalmente arbitrario (con specifiche
eccezioni per alcuni operatori come &&, || e ?:).  Questo frammento
viola i vincoli semantici suddetti quindi ogni compilatore ci fa un po'
quello che vuole (un buon compilatore, a richiesta [e.g. gcc -Wall], e`
in grado di darti un warning relativo a questi problemi).
Alex

 Come mai l'operatore '++' non ha un comportamento standard?
Non è l'operatore (anzi, gli operatori, visto che sono 2) ++ a non avere
un comportamento standard. È che (come detto più volte in questo thread)
l'ordine di valutazione delle espressioni non è parte dello standard.
Ognuno lo interpreta come vuole.
Su Windows succede:
1) viene valutato il secondo x++. x è incrementato.
2) il terzo parametro formale è il valore 1 
3) viene valutato il primo ++x. il secondo parametro formale è ancora 1
4) x viene posto a 2 (te ne accorgeresti se stampassi).
In pratica i parametri sono valutati da destra a sinistra.
Su Linux i numeri mi paiono strani: su mac OS X ho
0 2
1) viene valutato il primo x++. il secondo parametro formale è 0
2) viene incrementato x. Ora è 1.
3) viene valutato il secondo ++x, x è incrementato a 2
4) il terzo parametro formale è 2.


Will ha scritto:

Forse dipende dall'ordine in cui vengono passati i parametri ad una 
funzione?
Mi pare c'era stdcall, cdecl, etc...
Ciao,
Fabrizio

 4) x viene posto a 2 (te ne accorgeresti se stampassi).
Infatti a riprova, il seguente codice (sotto Win) da in output:
1 1
3 3
4
#include <stdio.h>
int main()
{
     int x = 0;
     printf("%d %d\n", x++, ++x);
     printf("%d %d\n", x++, ++x);
     printf("%d\n", x);
     return 0;
}
Quindi nel 'x++' prima viene incrementato x e poi viene stampato, mentre 
++x prima viene stampato e poi incrementato.

 in grado di darti un warning relativo a questi problemi).
Scusami tanto, ma non ho capito bene...cosa intendi per imporre più side 
effects in una stessa espressione? Cioè è sbagliato mettere nella stessa 
instruzione sia 'x++' sia '++x'?
In realtà quello che non capisco è come mai non sia stato chiarito, in 
maniera univoca, l'ordine di valutazione di tale operatore e anche degli 
altri qualora ce ne fossero.
Cioè non sarebbe stato più semplice indicare due comportamenti diversi 
per ++x e per x++? C'è bisogno forse di aggiungere una nuova regola alla 
grammatica?

 grammatica?
++x e x++ _hanno_ due comportamenti diversi, ma non e` questo il
problema.  Considera ad esempio una chiamata f(x++, y++) (che e`
perfettamente lecita).  Supponi che le convenzioni di chiamata della CPU
in gioco richiedano di fare i push da sinistra a destra e che per
ipotesi lo standard del C obbligasse invece a valutare gli operandi da
destra a sinistra (o viceversa in entrambi i casi): obbligheresti allora
il compilatore a "parcheggiare" il valore che valuta per primo in
un'area temporanea (magari un registro, ma se non ha registri liberi, in
memoria, con ulteriore rallentamento) per poterne fare il push solo dopo
l'altro.  In altri termini, senza nessun beneficio imporresti solo un
inutile aggravio alle prestazioni del codice generato.  L'ottimizzatore
_potrebbe_ aggirare l'inghippo se e solo se e` in grado di dimostrare
che gli effetti collaterali delle due sottoespressioni non
interferiscono fra di loro; ora supponi che gli argomenti siano (*x)++ e
(*y)++, per dimostrare se interferiscono puo` essere necessaria una
quantita` arbitraria di inferenze per vedere se i due puntatori x e y
possano o meno avere lo stesso valore in quel dato momento...
Il successo, anzi, diciamo meglio, il TRIONFO del C, che gli ha permesso
di spazzar via tutti i linguaggi paragonabili e divenire la base per un
verso o per l'altro della gran parte dei linguaggi della generazione
successiva, viene proprio anzitutto dalla saggezza dei progettisti
(Ritchie anzitutto, poi Thomson, Kernighan, Pike, ..., in ruoli di
importanza relativa descrescente) nel NON mettere troppi vincoli
inutili, rendendo possibile e persino facile la generazione di codice
assai veloce pur con un compilatore semplice e limitato.
Alex

 assai veloce pur con un compilatore semplice e limitato.
Uhm, ora mi è abbastanza più chiaro, anche se a questo punto mi 
piacerebbe scoprire effettivamente quali e quanti sono questi vincoli 
non imposti, in modo tale da poterli tener d'occhio e non aver poi 
brutte sorprese in fase di esecuzione.
Cmq ti ringrazio molto della spiegazione e della pasienza :)

 brutte sorprese in fase di esecuzione.
Se leggi qualche buon manuale di C potrebbe fartele notare (magari non
un manuale "di base", ma uno appena piů avanzato). O anche su alcuni di
C++ [ da quel punto di vista molte cose sono le stesse ].
In rete ci sono anche molti documenti e discussioni sui gruppi
specializzati (iclc iclc++ clc clc++).
Magari prova qui: alt.comp.lang.learn.c-c++


 possano o meno avere lo stesso valore in quel dato momento...
Tra l'altro stiamo lavorando un po' sul problema dell'aliasing. Farlo in
maniera sufficientemente generale non per nulla banale. Tipicamente ci
va un sacco di tempo nella migliore delle ipotesi, specie in quanto
effettivamente bisogna dimostrare che le aree di memoria puntate non
overlappino.
Il gcc potrebbe ottimizzare molto di più e fare più verifiche sul codice
(molte tecnologie ci sono), ma non viene fatto per ragioni puramente
pratiche. Quando uno si deve compilare per dire Linux gradisce metterci
meno di 12 ore, per dire :))
Ad ogni modo grazie alla spiegazione sull'ottimizzazione [ io
francamente non avevo provato a pensare a livelli di macchina ] ho
capito cosa intendevi nel resto della discussione.


 ++x prima viene stampato e poi incrementato
Invece che "stampato" io direi "pushato". Quello che ci fa la funzione
chiamata è poi irrilevante. :)


 un manuale "di base", ma uno appena più avanzato). O anche su alcuni di
Il classico immortale e` "C Traps and Pitfalls" di Koenig, secondo me. 
E` un elenco, molto importante e non brevissimo, di tutti i "fili
invisibili tesi a 20 cm da terra" che il linguaggio C (e in buona parte
i suoi successori, da C++ a Objective C, e per certi versi persino Java)
provvede generosamente per l'inciampo dei programmatori, e, in vari
casi, modi importanti per evitare queste trappole sistematicamente.  In
questo elenco, i due fatti che l'ordine di valutazione delle espressioni
non e` definito, e che e` un errore avere piu` di un side effect sulla
stessa variabile in una singola istruzione, sono minuzie...;-).
C++ in particolare di traps and pitfalls ne ha parecchie di piu`, ma non
conosco un libro equivalente al Koenig che le copra sistematicamente
tutte; bisogna metterle assieme a partire da parecchi altri libri,
Koenig incluso.
Alex

 capito cosa intendevi nel resto della discussione.
Ma prego!  Scusami se non ero stato cosi` esplicito da subito, a volte
si tende erroneamente a dare per scontato qualcosa nell'ipotesi che
l'interlocutore ne sia gia` a conoscenza (in un certo senso e` un
implicito complimento all'interlocutore;-).
Alex

 Magari prova qui: alt.comp.lang.learn.c-c++
Ok, sottoscritto ;)

 Il classico immortale e` "C Traps and Pitfalls" di Koenig, secondo me. 
Ok proverò a cercarlo, ma mi sa che non sarà così facile da trovare il 
libreria...magari lo ordino :)

 libreria...
Amazon, senza pensarci due volte. Trovo di tutto e sto comodo comodo a
casa mia. A meno che non abiti un grossa città (per esempio a Milano da
Hoepli trovi un sacco di testi scientifici...
io ci ho quasi preso il knuth e ci ho preso svariati testi o'really,
common lisp di steele, testi su cocoa... etc etc 


 implicito complimento all'interlocutore;-ì
 Spesso sono cose semplicemente cui uno non pensa, in quanto arriva da
un altro punto di vista. Effettivamente ormai mi capita molto di rado di
pensare alla macchina sotto come funziona *davvero*.
Io poi non sono mai stato particolarmente appassionato di hardware o di
assembly, metti insieme che ora stiamo smadonnando (in realtà lo
smadonnamento inizierà a breve, ora sto preparando esami e leggendo un
po' di documentazione) suj


 pensare alla macchina sotto come funziona *davvero*.
Buffo, si discuteva proprio di questo tema in questo giorni: quanto
conta la conoscenza dei livelli inferiori di un'astrazione per potere
avere la padronanza di quelli superiori?  Io ho sempre pensato
"qualcosina, ma poco", ma Joel Spolski in uno dei suoi saggi dice "alla
abstractions leak" e argomenta (come al solito) benino, anche se non mi
convince appieno.  
Il buffo e` che mia moglie l'ha sempre pensata come Joel (anche prima di
leggerlo): lei considera di soffrire della mancanza di svariati livelli
di astrazione, fra la fisica sotto e la programmazione ad alto livello
sopra -- come funziona un transistor in termini fisici, come lo si usa
come interruttore controllato, come si fanno i gate logici con
interruttori controllati, e via salendo.  Il buffo e` che, essendo
ingegnere elettronico, io tutti questi livelli intermedi li ho e non ho
mai pensato che mi tornassero poi tanto utili; ma Anna dice che sono
quelle cose di cui non ti accorgi neppure se le hai, ma ne senti la
mancanza se non lei hai (come per me, che so, la conoscenza del greco
antico o del sanscrito -- questione di "sfondo culturale").
Abbiamo finito per prenderle "Code", di Petzold, che nonostante il
titolo copre proprio questa gamma di argomenti, "a volo d'uccello" e in
modo assai accessibile; vedremo.  Anna pensa che un'infarinatura di
questi strati l'aiutera` nel lato piu` informatico dei suoi studi
("cognitive sciences", con la speranza di passare al nuovo corso di
"symbolic systems" se l'accettano a Stanford), proprio come una buona
base di biologia l'aiuta nel lato psicologico e antropologico degli
stessi...
Alex

 convince appieno.
Ma io sostanzialmente sono d'accordo. Un po' sapere come funziona conta
molto. Questo non significa essere veri esperti in materia, ma a naso
dice quello che è stupido fare e quello che invece no.
Ma anche in altri campi. Era diverso sentire il mio esame di analisi
numerica e quello di altri ragazzi che facevano "solo informatica" (e
quindi molta poca matematica, per cui molte cose erano "calate dal
cielo") oppure quello di altri miei compagni che facevano "solo
matematica" e quindi avevano tutta la base matematica, ma poi
sull'algoritmica e sulla programmazione [ nonostante qualche esamuccio
si faccia ] erano molto più su terreno minato. Mi viene in mente un
progetto che dovevamo fare portare per una parte d'esame.
 
Non ricordo nemmeno quale fosse l'argomento. Quello che ricordo è che
riuscivamo a fare girare il programma in tempi utili solo con set di
dati ridottissimi, molto meno di quanto ci aspettavamo.
Allora siamo andati a vedere il codice "di base". Il problema era la
parte che aveva fatto un ragazzo: in pratica aveva un ciclo for poderoso
dentro al quale aveva infilato istruzioni [ pure molto poderose ] che
però potevano essere svolte una volta per tutte fuori dal ciclo.
Un'ottimizzazione assolutamente banale. Cretina. Ovvia. Ma lui non ci
aveva pensato perchè non è assolutamente abituato a pensare in quei
termini.
Poi chiaramente spesso si riesce ad andare avanti anche con basi
"ridotte" e a fare cose molto interessanti. Io stesso per certi versi
lavoro a basi ridotte dal tuo punto di vista, dopo tutto io sotto
l'assembly non scendo (e sono anni che non lo faccio, a parte qualche
giochetto ogni tanto).
Tra l'altro è uno dei miei più grossi problemi. Fatico moltissimo a
lavorare senza sapere quello che succede almeno al livello sottostante
in genere. Mi sono rifiutato di dare esami di fisica fino a quando non
avevo svolto in maniera rigorosa tutta la matematica necessaria. 
Ho avuto grossi problemi con Cocoa all'inizio perchè sul libro che avevo
c'era un sacco di magia [ e ho dovuto sudare a capire come funzionassero
davvero alcune cose del framework, curiosamente di recente ho trovato un
libro che le stesse cose le spiega in maniera chiarissima, ed è un libro
per principianti, meno avanzato di quello che avevo scelto prima ].
Poi sono pronto per "dimenticare" le cose sotto o meglio fare
information hiding [in senso metaforico], ma sapendo che se
l'interfaccia è mal fatta, posso sempre scendere ad un livello più
basso.


 basso.
...o anche, se ha ragione Joel che _tutte_ le astrazioni "perdono"
(leak), le volte che questo succede anche con l'interfaccia meglio fatta
del mondo...
Alex