OT Programmazione - rolling release

[MItaly]

Eh, perdonami tu per il ritardo ancora più clamoroso... Ti ringrazio per la panoramica d'uso, intanto anche dei nostri collaboratori lo stanno usando per loro progetti interni, vediamo come si evolve la cosa.

Meanwhile:

Due indovinelli (da bug veri che mi hanno fatto impazzire per giorni):

• void someFunctionCallback(void * dummy) {
      std::stringstream ss;
      ss << atoi(((std::string)parms("max_vel")).c_str()) * 1000;
      some_object->setParameter("max_vx", ss.str());
      some_object->setParameter("max_vy", ss.str());
      ss << atoi(((std::string)parms("max_vel_inout")).c_str()) * 1000;
      some_object->setParameter("max_vx_inout", ss.str());
      some_object->setParameter("max_vy_inout", ss.str());
  }

  Dove sta il problema?
• 
  

      // reimposto il locale perche' se linko le QT
      // viene impostato il locale della macchina
      char * locale = setlocale(LC_ALL, NULL);
      setlocale(LC_ALL, "C");
  
      FILE *mf=fopen(filename, "r");
  
      // ... un bel po' di fscanf & co. ...
  
      if (mf) fclose(mf);
      setlocale(LC_ALL, locale);

  Sintomi: "ogni tanto" nel caricamento di altri parametri del programma venivano o letti solo zeri, o valori assurdi (o meglio, il sintomo originario erano crash in parti assurde del programma, ma qui semplifichiamo ).
  Dove sta il problema? (qui ce n'è più di uno in realtà)

Altri angoli oscuri del C++ che ho scoperto per caso in tempi recenti:

• le regole di scoping del C++ sono sempre più strane di quel che sembra:
  

  if(auto *derived_ptr = dynamic_cast<Derived *>(base_ptr)) {
      derived_ptr->doSomething();
  } else {
      derived_ptr->doSomethingElse(); // <-- ho scritto derived_ptr per sbaglio, ma compila! (ovviamente crash)
  }

  IOW: lo scoping delle variabili introdotte a livello di condizione dell'if perdura anche negli else; non riesco a cogliere completamente l'utilità di questo fatto, ma prendo atto. Mi sembra quasi peggio delle list comprehension in Python, che "pisciano fuori" la variabile di iterazione nello scope di funzione.
• std::function non è reference counted, ma lavora per copia, per cui bisogna stare attenti a fare lambda che catturano per copia roba troppo grossa, visto che si tende a trattare la copia di std::function come copia di oggetti leggeri; non so perché, ma mi ero sempre immaginato che lavorasse per reference-counting;
• ho finalmente colto uno dei motivi per cui sto abusando di std::function: in un certo senso è un'incursione del duck typing in un linguaggio a tipizzazione statica - l'unica cosa che importa è che quello che passo abbia un'interfaccia compatibile a quella richiesta, senza menate di ereditarietà, gerarchie di classi e compagnia (e, rispetto all'uso tipico del C++, consente di mantenere un comportamento simil-polimorfico senza doversi esplicitamente portare in giro puntatori a roba allocata sullo heap); il fatto che, rispetto a linguaggi come Python, mantenga comunque un buon controllo a compile-time, rende la cosa particolarmente usabile. Mi chiedo se si riesce ad estendere in maniera sintatticamente comoda ad interfacce più complicate (rispetto alla singola funzione)

[signoredeltempo]

Due indovinelli (da bug veri che mi hanno fatto impazzire per giorni):

• void someFunctionCallback(void * dummy) {
      std::stringstream ss;
      ss << atoi(((std::string)parms("max_vel")).c_str()) * 1000;
      some_object->setParameter("max_vx", ss.str());
      some_object->setParameter("max_vy", ss.str());
      ss << atoi(((std::string)parms("max_vel_inout")).c_str()) * 1000;
      some_object->setParameter("max_vx_inout", ss.str());
      some_object->setParameter("max_vy_inout", ss.str());
  }

  Dove sta il problema?

Mi sembra abbastanza

void *dummy

Volendo continuare, anche atoi è discutibile: se uno dei parametri non è rappresentabile in un int, .

non so perché, ma mi ero sempre immaginato che lavorasse per reference-counting;

Di cosa, poi?

Odio Java. Mi domando come chi lo usi (quanti e dove, poi?) non sia travolto dalla tremenda inconsistenza che lo forgia.

[Scara95]

Odio Java.

Plot twist.

[MItaly]

Mi sembra abbastanza

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.

Plot twist.

[Scara95]

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:

(] (([: $: < # [) , (= # [) , [: $: > # [) {.)^:(# > 1:)

[MItaly]

E poi ci sono i linguaggi consistenti che sono peggio comunque, un quicksort in J tanto per:

(] (([: $: < # [) , (= # [) , [: $: > # [) {.)^:(# > 1:)

E questa è la versione non offuscata?

[Scara95]

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.

[signoredeltempo]

E poi ci sono i linguaggi consistenti che sono peggio comunque, un quicksort in J tanto per:

(] (([: $: < # [) , (= # [) , [: $: > # [) {.)^:(# > 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.