Pagina 2 di 10 primaprima 1 2 3 4 ... ultimoultimo
Visualizzazione dei risultati da 11 a 20 su 98
  1. #11
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,590
    Quote Originariamente inviata da signoredeltempo Visualizza il messaggio
    Odio Java.
    Plot twist.
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

  2. #12
    Quote Originariamente inviata da signoredeltempo Visualizza il messaggio
    Mi sembra abbastanza
    codice:
    void *dummy
    Nah, quello era necessario (è un callback stile C che deve avere quella firma lì).
    Volendo continuare, anche atoi è discutibile: se uno dei parametri non è rappresentabile in un int, .
    Assumi pure che i dati in input siano sempre buoni. C'è un problema ben più grosso, e che si verifica con praticamente qualunque valore.
    (la cosa bella è che è così da tipo tre anni ma non se n'è mai accorto nessuno perché quel callback non è mai stato chiamato ; settimana scorsa ho cambiato il codice che chiama il callback per cui effettivamente viene chiamato ed è successo il finimondo)
    Di cosa, poi?
    Del functore che si porta dietro. Avevo in mente che copiare std::function fosse equivalente ad avere un altro reference allo stesso functore (come funzionano i riferimenti a closure in qualunque altro linguaggio).
    Odio Java. Mi domando come chi lo usi (quanti e dove, poi?) non sia travolto dalla tremenda inconsistenza che lo forgia.
    Oh be' se parliamo di linguaggi inconsistenti c'è ben di peggio.
    Quote Originariamente inviata da Scara95 Visualizza il messaggio
    Plot twist.
    Amaro C++, il gusto pieno dell'undefined behavior.

  3. #13
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,590
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    Oh be' se parliamo di linguaggi inconsistenti c'è ben di peggio.
    E poi ci sono i linguaggi consistenti che sono peggio comunque, un quicksort in J tanto per:
    codice:
    (] (([: $: < # [) , (= # [) , [: $: > # [) {.)^:(# > 1:)
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

  4. #14
    Quote Originariamente inviata da Scara95 Visualizza il messaggio
    E poi ci sono i linguaggi consistenti che sono peggio comunque, un quicksort in J tanto per:
    codice:
    (] (([: $: < # [) , (= # [) , [: $: > # [) {.)^:(# > 1:)
    E questa è la versione non offuscata?
    Amaro C++, il gusto pieno dell'undefined behavior.

  5. #15
    Quote Originariamente inviata da Scara95 Visualizza il messaggio
    E poi ci sono i linguaggi consistenti che sono peggio comunque, un quicksort in J tanto per:
    codice:
    (] (([: $: < # [) , (= # [) , [: $: > # [) {.)^:(# > 1:)
    Però parliamo di un linguaggio virtualmente inutilizzato, non di uno ampiamente adottato e, per di più, ostenato come "semplice". Alcune cose sono più semplici (e consistenti) in asm, per esagerare.

  6. #16
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,590
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    E questa è la versione non offuscata?
    Questa è una versione standard:
    Divide gli elementi in < del primo e chiama ricorsivamente, = al primo, > del primo e chiama ricorsivamente. Continua finché la lista è 1+ elementi.
    Nulla di speciale insomma.

    Le chiamate ricorsive sono le $:

    @signoredeltempo quel linguaggio è derivato da apl, il quale è ancora utilizzato e le uniche implementazioni degne di nota sono commerciali e costose.

    Quel linguaggio si comporta in modo sime a K/Q, un altro linguaggio commerciale piuttosto costoso (sostanzialmente un database).


    Non sottovalutare...

    In ogni caso una volta compresa la sintassi è piuttosto semplice da comprendere.

    # > 1: controlla se la lista è più lunga di 1 elemento
    ^: esegue ciò che precede se ciò che segue è vero, altrimenti restituisce l'argomento
    ] verb {. passa come argomenti ] l'argomento (ovvero la lista intera) {. il primo elemento della lista
    , concatena

    < # [ seleziona gli elementi minori del primo elemento
    [: $: chiama ricorsivamente la funzione
    = # [ seleziona gli elementi uguali al primo
    > # [ seleziona gli elementi maggiori del primo
    [: $: chiama ricorsivamente la funzione

    Basta farci un attimo l'abitudine.
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

  7. #17
    Mi sfugge un attimo il meccanismo di salvataggio dei risultati temporanei... c'è uno stack implicito in tutta la vicenda? È una specie di FORTH all'ennesima potenza?
    Amaro C++, il gusto pieno dell'undefined behavior.

  8. #18
    Utente di HTML.it L'avatar di XWolverineX
    Registrato dal
    Aug 2005
    residenza
    Prague
    Messaggi
    2,565
    Vorrei un momentino fare un cambio totale di argomento: API Design.

    Chi di voi si è mai ritrovato a dover progettare e implementare delle API (che siano Web o meno) che verranno poi utilizzati dai vostri clienti? Quale è l'approccio che seguite? Avete voglia di condividere delle esperienze in merito?
    "Se proprio devono piratare, almeno piratino il nostro." (Bill Gates)

    "Non è possibile che 2 istituzioni statali mi mettano esami nello stesso giorno." (XWolverineX)

    http://xvincentx.netsons.org/programBlog

  9. #19
    Utente di HTML.it L'avatar di Scara95
    Registrato dal
    Jul 2009
    residenza
    Zimella (VR)
    Messaggi
    2,590
    Quote Originariamente inviata da MItaly Visualizza il messaggio
    Mi sfugge un attimo il meccanismo di salvataggio dei risultati temporanei... c'è uno stack implicito in tutta la vicenda? È una specie di FORTH all'ennesima potenza?
    C'è un meccanismo implicito di composizione di funzione.
    Una funzione v può prendere 1 o 2 argomenti:
    v y
    x v y
    Date tre funzioni v u w
    (v u w) y <-> (v y) u (w y)
    x (v u w) y <-> (x v y) u (x w y)

    una serie di funzioni
    f g u v w
    Viene interpretata come
    f g (u v w)
    E quindi ci si può rifare alle regole di cui sopra.
    Ci sono un altro paio di regole di composizione ma non sono utili alla comprensione del codice sopra.
    [: serve alla composizione di funzione com'è nella matematica
    ([: u v) y <-> u (v y)
    Un modo equivalente è usare la congiunzione @:
    (u@:v) y <-> u (v y)

    La valutazione procede da destra a sinistra, quindi un altro modo per comporre è
    u v y

    Una serie di funzioni
    f g u v w
    Viene interpretata come
    f g (u v w)
    E quindi si procede con le regole di composizione di cui sopra.
    Ci sono un altro paio di regole, ma non sono utili alla comprensione del codice.
    Ultima modifica di Scara95; 15-11-2015 a 15:56
    "Quid enim est, quod contra vim sine vi fieri possit?" - Cicerone, Ad Familiares

  10. #20
    Quote Originariamente inviata da XWolverineX Visualizza il messaggio
    Vorrei un momentino fare un cambio totale di argomento: API Design.

    Chi di voi si è mai ritrovato a dover progettare e implementare delle API (che siano Web o meno) che verranno poi utilizzati dai vostri clienti? Quale è l'approccio che seguite? Avete voglia di condividere delle esperienze in merito?
    È capitato abbastanza di rado, e l'ultima volta è fallito tutto (ma perché il cliente era un imbecille, non per le nostre API ), per cui non credo di poter dare consigli troppo validi tanto credo dipenda molto dal tipo di applicazione e di target di utilizzo delle API - un conto è se è un progetto pilota per un singolo cliente con API fatte su misura per lui, un altro è se sono Twitter e devo fare API per il pubblico generale. Tu in che caso rientri?
    Quote Originariamente inviata da Scara95 Visualizza il messaggio
    C'è un meccanismo implicito di composizione di funzione.
    Una funzione v può prendere 1 o 2 argomenti:
    v y
    x v y
    Date tre funzioni v u w
    (v u w) y <-> (v y) u (w y)
    x (v u w) y <-> (x v y) u (x w y)
    ...
    Credo di capicchiare... in realtà quindi le funzioni come sintassi tendono più verso l'idea degli operatori (unari e binari)... sostanzialmente è tutto un gioco di notazione infissa (vs prefissa => LISP, postfissa => FORTH, Postscript & co., prefissa in generale e infissa solo per alcuni operatori => più o meno tutto il resto).
    Amaro C++, il gusto pieno dell'undefined behavior.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.