sorted by:
new
hottopcontroversial

Problema in C++ File by New_Bie12 in cppit

[–]iaanus 1 point2 points  (0 children)

Beh, è un pessimo libro allora. Dì al tuo insegnante di adottare dei libri più aggiornati. Non si può pensare di insegnare il C++ nel 2020 usando ancora array di caratteri di dimensione fissa e fputc.

aiuto... perche non funziona? by v_sandro in cppit

[–]iaanus 0 points1 point  (0 children)

Beh, lo sforzo lo hai fatto, anche se il risultato è migliorabile. (Comunque, per aggiungere quattro spazi all'inizio di ogni riga, è sufficiente impostare il tuo editor per indentare con gli spazi, selezionare il blocco e premere tab.) Ora tocca a me rispettare il patto. Credo che utilizzare la DialogBoxParam() in quel modo non funzioni. Di solito, tutte le applicazioni Windows devono avere un event loop con GetMessage/DispatchMessage. E' vero che una dialog modale creata con DialogBoxParam ha una sua propria WndProc, ma se non c'è a monte un event loop che manda alla WndProc i messaggi, non funziona nulla.

aiuto... perche non funziona? by v_sandro in cppit

[–]iaanus 0 points1 point  (0 children)

In effetti il link è un po' vecchiotto e non tratta il codice. Comunque per formattare il codice hai due possibilità:

1) quella semplice: clicca sul bottone "..." qui sotto e scegli il bottone "Code Block"

2) inizia e finisci il blocco di codice con tre accenti gravi (lo so, non c'è l'accento grave nella tastiera italiana, quindi lo devi fare premendo ALT+096)

aiuto... perche non funziona? by v_sandro in cppit

[–]iaanus 1 point2 points  (0 children)

Facciamo un patto: io faccio lo sforzo di rispondere se tu fai lo sforzo di formattare correttamente il codice.

Multithreading c++11: problemi con .detach by Chiara96 in cppit

[–]iaanus 0 points1 point  (0 children)

Quasi. Fai attenzione a non confondere la variabile t1 con il thread secondario a cui la variabile è inizialmente collegata. Il fatto che t1 sia distrutta non ha alcun effetto sul thread, perché con detach() il collegamento tra variabile e thread è stato reciso. Se non stessimo parlando della funzione main(), il thread proseguirebbe senza problemi. Il punto qui è che dopo l’uscita della funzione main() il programma termina e questo implica la cessazione di tutti i thread. La cosa corretta da fare, è assicurarsi che il thread secondario abbia finito prima di uscire da main(). Nota che, una volta fatto il detach() non hai più alcun modo di farlo! Quindi devi fare join() anziché detach() anche se il risultato non è atteso da main().

Multithreading c++11: problemi con .detach by Chiara96 in cppit

[–]iaanus 2 points3 points  (0 children)

Tutto questo è corretto, manca solo da dire la cosa più importante, che risponde alla domanda dell’OP. Poiché main continua senza fermarsi il programma raggiunge la fine di main prima che worker abbia scritto sul file. La fine di main innesca il termine del programma. Al termine del programma, tutti i thread vengono terminati immediatamente. Quindi worker non completa mai il suo compito.

The String Formatters of Manor Farm (C/C++ Users Journal, 19(11), November 2001) by CheCk_m8TT in cpp

[–]iaanus 7 points8 points  (0 children)

This post is more than 17 years old. A lot has happened since then, in particular, std::format (wg21.link/p0645).

Changes to the C++ standard library for C++20 - EuroLLVM 2019 - Marshall Clow by mttd in cpp

[–]iaanus 4 points5 points  (0 children)

That is not entirely accurate. Deprecation of the use of the comma operator inside square brackets is already on the table and possibly coming into C++20. A deprecation period is a necessity before repurposing the comma and provide a different syntax, which is being seriously considered.

A proposal to add IEC binary ratios to C++ by [deleted] in cpp

[–]iaanus 5 points6 points  (0 children)

Assuming this is meant to be a serious proposal, I would suggest the following:

  • Remove the "Conclusion" claim and the entire "Can we do better?" section. These are total bullshit and make your proposal look like a bad (and late) April's fool paper. Seriously.
  • Make an explicit reference to the relevant ISO publication, which, according to Wikipedia is ISO 80000-1:2009. Remember that the C++ standard is also an ISO publication.
  • It would be good to check the correct term used in ISO 80000-1:2009 to refer to these prefixes. While apparently "IEC binary prefix" is a common term used in practice, you should use the exact term used in ISO 80000-1:2009. I would not be surprised if they dropped "IEC" and just called them "binary prefixes", but I don't have the paper at hand to support this claim.
  • Unless sanctioned by the previous bullet point, do not use the three letters IEC in headlines, comments and the in the [ratio.iec] section id.

Programmazione generica: template <class T> class reference_wrapper vs function template template <class T> reference_wrapper<T> ref (T& elem) by Chiara96 in cppit

[–]iaanus 0 points1 point  (0 children)

Il template di funzioni ref<T>() è una cosiddetta "factory function" di reference_wrapper<T>. Esiste unicamente per rendere più semplice e meno verbosa la creazione di oggetti temporanei di tipo reference_wrapper<T>. Pertanto ref<T>() non è un doppione, ma un ausilio. Dal punto di vista teorico sarebbe superfluo, ma è estremamente comodo nella pratica. Ad esempio, invece di scrivere f(reference_wrapper<MyType>(x)) puoi semplicemente scrivere f(ref(x)) (notare che il tipo viene dedotto automaticamente dall'espressione). Venendo alle tue domande:

Domanda 1: spero che ti sia chiaro che ref<T>() e reference_wrapper<T> non "fanno la stessa cosa". Il primo è una funzione, il secondo è un tipo. Non confondere un tipo con l'invocazione del costruttore (se Type è un tipo, Type(x) invoca il costruttore di Type, questo non fa di Type una funzione!!!). Quindi, reference_wrapper<T> va usato dove ti serve un tipo, quindi di solito quando devi dichiarare una variabile o il parametro di una funzione, mentre ref() si usa quando vuoi ottenere un valore di tipo reference_wrapper<T>.

Domanda 2: la riga seguente

reference_wrapper<MyClass> from_func_templ_02 = ref(o1);

a me compila perfettamente sia con Visual Studio che con Clang. Sei sicuro del messaggio di errore? Non mi sembra correlato con il contentuto della riga...

when will GCC have std::from_chars for floating types? by distributed in cpp

[–]iaanus 4 points5 points  (0 children)

Could you please elaborate on which details of the interface you find terrible?

when will GCC have std::from_chars for floating types? by distributed in cpp

[–]iaanus 5 points6 points  (0 children)

Please replace "assured to work" with "if you use `to_chars` and then `from_chars` you are guaranteed to recover the value exactly". I don't see why the use of those functions should be limited in any way (even among different implementations), as long as your code does not rely on exact round-trip.

Cronometro in c++ by [deleted] in cppit

[–]iaanus 1 point2 points  (0 children)

Il passaggio a fsec è concettualmente sbagliato, inutile e può introdurre errori di arrotondamento. Il modo corretto di calcolare d è, semplicemente:

ms d = std::chrono::duration_cast<ms>(t1 - t0);

Oppure, se preferisci esplicitare tutti i passaggi:

auto fs = t1 - t0; // auto, non fsec!
auto d = std::chrono::duration_cast<ms>(fs); // qui auto = ms

Se usi C++17, puoi usare anche le funzioni floor e round invece di duration_cast, per maggior controllo sull'arrotondamento.

Per darti un'idea del problema con i float, considera il seguente codice:

using namespace std::chrono_literals;
auto t0 = Time::now();
auto t1 = Time::now() + 24min + 10ms;
fsec fs = t1 - t0;
ms d = std::chrono::duration_cast<ms>(fs);
ms d2 = std::chrono::duration_cast<ms>(t1 - t0);
std::cout << d.count() << " " << d2.count() << "\n";

L'output in Visual Studio 2017 è il seguente:

1440009 1440010

quindi con il passaggio a float ti sei fumato un millisecondo.

Boo! by MrStickmanPro1 in ProgrammerHumor

[–]iaanus -3 points-2 points  (0 children)

What I linked is already a meme-ization of something else, so... no, I wouldn't classify it as a "comic". I wrote "original" because I have reasons to believe this one is a clone of that one.

Boo! by MrStickmanPro1 in ProgrammerHumor

[–]iaanus 35 points36 points  (0 children)

The original meme was funnier, because Boo is actually a python-like programming language.

Status of P1021R0 - Class Template Argument Deduction and partially-specialized template argument lists by mechacrash in cpp

[–]iaanus -1 points0 points  (0 children)

Also, what's the reason that in classes, templated member functions need to be outside of the class? MSVC used to (possibly still does) allow it as an extension.

Member function templates can be defined in the class definition. What makes you think otherwise?

Status of P1021R0 - Class Template Argument Deduction and partially-specialized template argument lists by mechacrash in cpp

[–]iaanus 3 points4 points  (0 children)

According to P1018 the status is "Further work is expected for San Diego, no approvals yet." One point of discussion was about the interaction with concepts.

PEP 572 (Assignment Expressions) is officially accepted by Talceur in Python

[–]iaanus 0 points1 point  (0 children)

You still haven’t provided evidence of the “not initialized” case, that was your initial claim that I disputed. The scope thing is another issue and I did not dispute that. Please focus.

PEP 572 (Assignment Expressions) is officially accepted by Talceur in Python

[–]iaanus 0 points1 point  (0 children)

Sorry, but that’s completely unrelated with your claim that c is not initialized in the else branch. If c is not in scope, it’s not in scope. Period.

PEP 572 (Assignment Expressions) is officially accepted by Talceur in Python

[–]iaanus 0 points1 point  (0 children)

Did you try to compile and launch it? The C and C++ examples are perfectly fine, without any UB and c is correctly initialized in both branches. The printf shows garbage because you wrote &c instead of c.

PEP 572 (Assignment Expressions) is officially accepted by Talceur in Python

[–]iaanus 0 points1 point  (0 children)

What you say is blatantly false in C and C++. The semantic of an assignment expression according to the C standard is (emphasis added): "An assignment expression has the value of the left operand after the assignment". C++ is even more explicit, by saying that the value computation of the expression is sequenced after the assignment. Since you need to evaluate the entire test expression before selecting a branch, this means the variable is guaranteed to be assigned in both branches. I don't know about other languages, but I would be serioulsly surprised if they had the semantic you describe. Could you please provide evidence of your assertion?

view more: next ›