01:37:29 dot joined the channel
05:10:08 Indiana joined the channel
05:18:34 Schrompf joined the channel
05:32:11 IceMichael: Hakko
05:33:56 Schrompf: Hajjo!
05:46:43 joeydee joined the channel
05:46:49 joeydee: https://debeste.de/upload/339d198134bcdcad9228a03e787460b58159.jpg
05:49:22 Schrompf: eins davon könnte man durch ein Schulterzucken ersetzen
05:57:26 joeydee: Der links schwätzt auch ein bischen viel in der vorletzten Antwort.
05:58:17 joeydee: Aber für den Wochenreport ist damit eigentlich alles gesagt.
06:19:25 xq: moin
06:19:55 Schrompf: ah, stimmt, nachvoicen hätte ich auch tun sollen
06:20:22 Schrompf: ich denke aber, wir könnten +m allgemein wieder abschaffen
06:20:41 Schrompf: andere kanäle jedenfalls fahren schon ne weile ohne und die spampfeiffen sind schon ne weile nicht merh dagewesen
06:21:05 xq: https://mq32.de/public/fbe32da193d05e4f285aa508f85b72ace5770d55.jpg
06:21:13 xq: ich bepiss mich grade vor lachen
06:22:08 Schrompf: gemein
06:22:24 xq: joeydee, deines ist auch schön :D
06:23:00 xq: Tiles geht mir grade aber auch wieder aufn Sack
06:23:36 joeydee: :D
06:23:59 Schrompf: du weißt, wie das in foren ist? wenn du nix nettes sagen kannst...
06:24:14 xq: ja, darum halt ich grade auch die fresse
06:24:37 Schrompf: guter mann
06:24:58 xq: und schwelgt in nostalgie, die er nie erlebt habt
06:25:00 xq: *hat
06:27:51 joeydee: "Benutze die Rundbürste auf dem senkrechten Flugzeug" - Gemeint war "Benutze den Rundpinsel auf der vertikalen Ebene", ich finde Video-Übersetzungen immer lustig.
06:28:02 xq: hihi
06:28:35 xq: Schrompf, hier ist noch ein dummer Witz für dich: https://i.redd.it/1g1d8jkalu971.jpg
06:29:46 joeydee: LOL
06:30:11 xq: das is so herrlich dumm
06:31:23 Schrompf: seufz
06:44:18 IceMichael: @Witz: oh..
08:48:09 Schrompf: retak retakt mal wieder hart
08:50:15 xq: ohja
08:52:23 IceMichael: oh! mal schauen
08:52:37 IceMichael: och nö, wo denn? ich bin wieder nicht im richtigen channel :(
08:53:02 Schrompf: #c++ und es ist auch schon durch
08:53:14 IceMichael: ah, gut, lesen
08:56:33 IceMichael: jup, ok
08:56:52 IceMichael: wobei ich mittlerweile in vielen Fällen finde, dass der Pointer ein thombstone sein sollte
08:57:01 IceMichael: also Page's ref auf doc
08:57:29 Schrompf: das sehe ich ganz entschieden anders
08:58:09 xq: meinst du tombstones?
08:58:22 IceMichael: yeah, meine englische Aussprache ist nicht so gut manchmal :)
08:58:35 IceMichael: also wenn es performancekritisch ist, jo, dann meinetwegen nicht
08:58:47 IceMichael: aber mit dem tombstone ist die Integrität halt gewahrt, dangling pointer sind schon scheiße
08:59:52 Schrompf: ist halt eine philosophiefrage
09:00:11 Schrompf: du denkst, dangling pointer sind unvermeidlich und deswegen muss man im code vorsehen, dass es daran nicht scheitert
09:00:47 Schrompf: ich bin der meinung, dangling pointer sind durch design (und genau solche kommentare wie bei retak) vermeidbar und ich werde *keinen* extra code investieren, um diesen vermeidbaren menschenfehler zu behandeln
09:01:00 IceMichael: retaks Problem ist aber doch ein anderes?
09:01:09 Schrompf: retak hat viele probleme :-)
09:01:37 IceMichael: das ja nun mal eh :)
09:01:44 IceMichael: das Design verhindert aber nicht, dass du auf einen danglin pointer zugreifst
09:01:48 Schrompf: hier: er glaubt lieber, dass irgendne random coderin ihren eigenen code mit dummheit ergänzt, anstatt seine interpretation der doku anzuzweifeln
09:02:08 IceMichael: wie gesagt, darum geht's mir ja nicht
09:02:09 Schrompf: richtig. das design sagt hier: wenn du pages aus nem doc erstellst, muss das doc länger leben als die pages
09:02:11 Schrompf: fertig
09:02:25 IceMichael: ach so
09:02:29 Schrompf: das kannst du als nutzer der lib so tun, oder halt nicht, dann crasht es
09:02:38 IceMichael: mein Denken war, man kann eine Seite auch ohne Dokument benutzen, weil man sie rausreißt
09:02:40 IceMichael: gut, das ist was andres
09:02:50 Schrompf: ja, das ist dann usecase, was man halt haben will
09:03:02 IceMichael: ja, aber wenn man das halt so hat, wäre der tombstone gut
09:03:08 IceMichael: wenn das kein use case ist, dann ist es überflüssig
09:03:21 IceMichael: das Design sagt für mich hier: ist überflüssig
09:03:23 IceMichael: also alles gut, mein Fehler
09:04:03 IceMichael: ich hab so viele blöde Bugs bei mir im Code gefunden, die durch nen Tombstone verhindert worden wären
09:04:26 xq: der tombstone ist halt halt mitigation
09:04:28 xq: statt fixes
09:04:33 IceMichael: ja
09:04:37 xq: da fällt mir eine lustige sache ein:
09:04:37 Schrompf: ja weil du denkst, dangling pointer wären unvermeidlich. ich bin der meinung, man solle lieber dangling pointer verhindern als den crash zu verhindern, der durch dangling pointer entsteht
09:04:40 IceMichael: wenn du ungesichert zugreifst, fliegst du trotzdem auf die Schnauze
09:04:48 IceMichael: aber wenn du nen optional-getter dazupackst, hast du es
09:05:02 Schrompf: und musst halt überall damit umgehen, dass das weg ist
09:05:05 IceMichael: Schrompf, aber genau das sage ich ja hier?
09:05:13 Schrompf: das gibt nochmal ne exra kategorie an problemen :-)
09:05:24 IceMichael: ein Tombstone verhindert für mich dangling pointer
09:05:32 IceMichael: das ist doch der Zweck
09:05:51 xq: IceMichael: tut er nicht
09:05:57 xq: er mitigiert einen zugriff auf einen dangling pointer
09:06:03 Schrompf: get(tombstone)... was gibt der zurück? initStuffOnTopOf(tombstone)... muss ich jetzt echt nen fehlerstate durch mein komplettes system ziehen, wenn der tombstone schon weg ist
09:06:12 IceMichael: du wirst aber nicht auf 0x1237894 zugreifen dadurch, nie
09:06:16 Schrompf: richtig
09:06:18 IceMichael: es wird vll ein nullptr-Zugriff
09:06:24 IceMichael: aber kein dangling-ptr-Zugriff
09:06:37 Schrompf: was dann genauso crasht wie use-after-free
09:06:43 Schrompf: nuja, egal, mach wie du denkst
09:06:53 IceMichael: ja, crash
09:06:59 IceMichael: dangling-ptr-Zugriff ist oft UB
09:07:03 IceMichael: das ist wesentlich besser
09:07:44 xq: nullptr ist genauso UB wie dangling pointer
09:07:44 Schrompf: ich boote re
09:08:00 IceMichael: erfahrungsgemäß crasht nullptr-Zugriff bei mir eigentlich immer
09:08:09 IceMichael: und dangling-ptr-Zugriff selten
09:08:40 IceMichael: Und: Bei einem Tombstone weiß ich ja, dass ich checken muss
09:08:46 IceMichael: genau so wie unique_ptr return type mir sagt: du hast ownership
09:09:10 IceMichael: außer wir sagen jetzt, wir ignorieren die semantische Ebene komplett (was wir sicherlich nicht tun)
09:10:23 IceMichael: aber nochmal: ich kann den getter auf Document in Page zB zu einem std::optional
09:11:55 xq: IceMichael: damit hast du runtime cost für implementierungsfehler
09:12:20 IceMichael: wenn es nicht performancekritisch ist, baust du damit aber bessere Software, weil immer Bugs auftreten
09:12:37 IceMichael: und wenn es nicht performancekritisch ist, sind die Kosten an der Stelle vernachlässigbar
09:13:40 IceMichael: das ist wohl wieder das typische API-bauen vs. Anwendungssoftware bauen :)
09:13:50 IceMichael: die trade-offs sind da komplett unterschiedlich
09:14:06 IceMichael: du baust halt fast nur API, da würd ich das auch nie so machen
09:15:16 IceMichael: bau ein UI und es ist erfahrungsgemäß äußerst sinnvoll so ein Sicherheitsnetz zu bauen (andere Coder machen murks mit deiner Klasse, du hast doch nen Bug eingebaut, der dann automatisch vermieden wird, du verbringst weniger Zeit mit Bugfixen, das Produkt kommt schneller voran uvm.)
09:15:51 joggel joined the channel
09:15:59 joggel: olla o/
09:16:26 Schrompf joined the channel
09:16:39 IceMichael: moin joggel!
09:16:40 Schrompf: re
09:17:50 xq: moin joggel
09:17:59 Schrompf: moin joggel.
09:18:45 joggel: servus
09:18:59 joggel: Sagt mal ihr Qt-Cracks, ich muss euch mal was fragen
09:19:07 joggel: moment, Screenshot kommt gleich
09:19:28 xq: joggel: zu deiner frage von gestern:
09:19:34 xq: der link zur doku geht zu Qt 4.8
09:19:39 xq: aktuell sind 5.XX oder 6.XX
09:19:47 joggel: oh. Ja, moment
09:20:39 xq: Schrompf, IceMichael: https://zig.godbolt.org/z/voMd7o7TW
09:20:45 joggel: Ja, es tut ja jetzt auch. Habe mich nur gewundert, weil man beim connect ja immer die ParameterTypen mit angegeben hat... zumindest war mir so
09:20:47 joggel: https://doc.qt.io/qt-5/qsplitter.html#splitterMoved
09:22:32 IceMichael: xq, ok, ich wart mal auf deinen Context-Text, bevor ich den Code lese, macht wohl mehr Sinn :)
09:22:44 IceMichael: joggel, neues connect braucht keine Paramtypen
09:22:59 IceMichael: außer du hast mehrere Slots/Signals überladen, dann hilft aber QOverload
09:23:10 xq: IceMichael: scroll einfach mal zur main ;)
09:23:14 xq: und schau den output an
09:23:14 IceMichael: seh ich
09:23:17 IceMichael: sah ich
09:23:30 xq: jo
09:23:39 xq: das wäre imho die einzig okayishe anwendung von tombstones
09:24:38 IceMichael: was für ne Anwendung? Point sollte kaputt sein und du gibst es trotzdem aus
09:24:49 xq: na
09:24:53 xq: genau das was du gesagt hast
09:24:55 xq: dangling pointer
09:25:00 xq: hier simuliert durch ein smaller scope
09:25:09 xq: das ist *genau* der use case, von dem du gesprochen hast
09:25:38 IceMichael: ja, aber dein Tombstone funktioniert nicht, weil du einfach casten kannst und das umgehst?
09:26:25 xq: nein...
09:26:28 xq: der funktioniert hervorragend
09:26:42 xq: assertion im debug mode, UB in release
09:26:42 IceMichael: hä?
09:27:00 xq: na, das ist sauberes verhalten
09:27:10 xq: fängt programmierfehler beim entwickeln und ist flott wie ein normaler pointer im release
09:27:18 IceMichael: puh, in wie großen Teams arbeitest du denn?
09:27:24 IceMichael: ich verstehe deinen Punkt
09:27:46 IceMichael: du hast halt alles, was ich dazu geschrieben habe, wieso man die Laufzeitkosten in Kauf nehmen darf, ignoriert
09:28:01 IceMichael: und dein Beispiel bringt keinen Mehrwert für die Diskussion, weil du damit nichts Neues zeigst
09:28:05 xq: weil ich die philosophie nicht teile
09:28:14 IceMichael: weil du nur APIs baust und deine Teams klein sind
09:28:14 xq: programmierfehler auf *alle user* mitigieren ist scheiße
09:28:16 xq: und kostet geld
09:28:21 IceMichael: ne, es spart Geld
09:28:27 xq: nein
09:28:28 IceMichael: doch
09:28:30 xq: overall kostet es gelkd
09:28:31 IceMichael: du gehst von den perfekten Codern aus
09:28:36 IceMichael: overall spart es Geld
09:28:37 xq: vllt. ist es für dich als egoist billiger
09:28:45 IceMichael: eben nicht
09:28:48 xq: schnelle software = billiger
09:28:54 IceMichael: puh
09:29:02 xq: kann ich dir gerne durchrechnen
09:29:04 IceMichael: irgendwie bist du in deinem Mikrokosmus gefangen :D
09:29:22 xq: 1 cycle weniger runtime kostet die wikimedia foundation im monat 0,13 cent weniger serverkosten
09:29:29 IceMichael: wenn du ne Anwendungssoftware baust, ne Business App, dann sind Kosten durch solche Extrachecks völlig vernachlässigbar
09:29:36 IceMichael: da sind einzelne Cycles total wurscht
09:29:44 IceMichael: ich sag ja, du machst µC und APIs, aber keine Anwendungssoftware
09:29:54 xq: rate mal, womit ich mein geld verdiene
09:29:57 IceMichael: daher sag ich das die ganze Zeit, aber entweder überliest du es oder hast zu wenig Erfahrung in dem Bereich, um das zu verstehen
09:30:34 IceMichael: die Performance, die du durch so was verlierst, ist fast immer völlig irrelevant
09:30:45 xq: außer du machst software, die von mehr als 10 usern benutzt wird
09:30:53 IceMichael: machst du das?
09:31:00 xq: ja
09:31:02 xq: nicht sonderlich viel mehr
09:31:13 xq: uns kostet jede extrasekunde geld
09:31:15 IceMichael: meine Privatsoftware hat 1000e User und unsere Unternehmenssoftware hat dutzende Großkunden
09:31:21 IceMichael: ja, weil das dein sehr spezieller Fall ist
09:31:28 xq: jede firma kostet das geld ;)
09:31:33 xq: jeden non-privaten user
09:31:49 IceMichael: ok, mal einfaches Beispiel
09:31:57 IceMichael: wenn du Qt als UI-Framework nutzt, dann ist so ein dadurch gesparter Cycle gar nix
09:32:14 xq: immer noch relevant
09:32:16 IceMichael: wenn du ein REST (oder andres) Web-Backend hast und nen Tombstone im Frontend nutzt, dann ist ein dadurch gesparter Cycle auch gar nix
09:32:18 IceMichael: ne
09:32:20 IceMichael: überhaupt nicht
09:32:21 xq: außer deine software tut nichts relevantes in compute
09:32:25 IceMichael: wenn du 1000 Calls darauf hast, ja
09:32:29 IceMichael: wenn es ein seltener ist, ist es 100% egal
09:32:42 IceMichael: wenn du dadurch nen Bug vermeidest, bei dem ein Entwickler zwei Tage sucht, dann hast du wesentlich mehr Geld gespart
09:33:21 xq: für dich persönlich? vielleicht
09:33:25 IceMichael: nope
09:33:30 xq: auf 10 Jahre nutzungsdauer gerechnet, mit 10k usern: sicherlich
09:33:39 IceMichael: nein
09:34:14 IceMichael: wenn du auf den Tombstone zB wegen ner user interaction zugreifen musst, also bei typischer Reaktionszeit vll alle 100ms, wenn der schnell ist, dann fällt das niemals auf
09:34:23 xq: 1 sekunde shaveoff per day
09:34:27 xq: 1 jahr nutzungsdauer
09:34:29 xq: 1 user
09:34:31 IceMichael: schau dir einfach mal bei nem Click mit Debugger in Qt den Stacktrace an, das sind gern mal 50 Layer. Da einen Tombstone zu checken, ist egal
09:34:39 IceMichael: 1s pro Tag kriegst du damit nicht, niemals
09:34:45 xq: 20€ stundenlohn
09:34:51 xq: sind 1,47€ / Jahr gespart
09:34:52 xq: pro user
09:35:04 IceMichael: bei den falschen Annahmen...
09:35:28 IceMichael: So ein Zugriff ist im ns-Bereich, mit viel Pech vll µS
09:35:36 xq: EIN EINZELNER JA
09:35:48 xq: wenn du davon ausgehst, dass dein tombstone check genau einmal am tag passiert
09:35:49 xq: klar
09:35:58 IceMichael: ne, es reicht einmal pro Klick
09:36:06 IceMichael: der User kann nicht instant reagieren im µS-Bereich
09:36:07 xq: wenn bei jedem klick mehrere passieren wirds spannender
09:36:17 IceMichael: und dass ich oben schrieb, dass es nen Unterschied von 1000en Zugriffen vs nen einzelnen macht, hast du einfach überlesen oder wie?
09:36:18 xq: der punkt ist:
09:36:23 xq: alle solche mitigations summieren sich
09:36:31 IceMichael: ich habe auch geschrieben "kommt drauf an"
09:36:34 xq: hast du das mal verwendet?
09:36:38 IceMichael: der nutzt kein Qt...
09:36:48 IceMichael: du optimierst einfach an der völlig falschen Stelle, wenn du so argumentierst
09:36:53 xq: selbst bei Qt kannst du dinge optimieren
09:36:59 IceMichael: leider nicht genug
09:37:25 IceMichael: wenn du zB ein bisschen grafisch unterwegs bist und QPainter nutzt, dann verschlingt der alles an Performance, und das ist ms-Level
09:37:39 IceMichael: man kann da cachen uvm., aber es ist sehr, sehr ätzed
09:38:00 IceMichael: na ja, du ignorierst jedenfalls komplett, dass ich gemeint habe, dass es drauf ankommt
09:38:21 IceMichael: es gibt Klassen zB Controller im UI-Bereich, darauf greift man in Summe einfach bei einem Klick oder ner user interaction <10 mal zu
09:38:38 IceMichael: willst du sagen, da fällt was im ns-Bereich ins Gewicht?
09:38:41 IceMichael: sicher nicht
09:39:00 IceMichael: hab ich gesagt, dass man IMMER alles überall mit Tombstones vollklatschen soll?
09:39:01 IceMichael: nö
09:39:07 IceMichael: hab ich gesagt, es gibt darum, dass es performancekritisch sein muss?
09:39:09 IceMichael: mehr als einmal
09:39:30 IceMichael: wenn du nur die Hälfte liest und dir rauspickst, was dir gerade in deine engstirnige Sicht passt, dann machst es echt keinen Sinn mit dir zu schreiben
09:40:12 Schrompf: den bug-aspekt sehe ich ein. speziell bei qt sind objekt-lebenszeiten manchmal hardcore schwierig
09:40:40 Schrompf: und wenn man irgendwo da mit tombstones für die großen gui-objekte arbeitet, könnte das ernsthaft geld ersparen. die performance ist da echt unkritisch
09:40:48 IceMichael: ja, denn im echten Leben arbeitet man nicht unter perfekten Umständen, mit perfekten Coderinnen-Kollegen, mit perfekten Frameworks, mit Umständen, wo ne micro optimization wirklich was bewegt
09:40:53 Schrompf: rettet dich bei multithreaded allerdings auch nicht
09:41:04 IceMichael: ja klar, ist kein Allheilmittel
09:41:05 Schrompf: da ist der pointer noch da, aber das objekt mitten im abbau.
09:42:09 IceMichael: danke Schrompf
09:42:19 IceMichael: wenigstens einer, der kapiert, dass Performance nicht immer in allen Fällen das wichtigste ist
09:42:33 IceMichael: vor allem, dass das wirtschaftlicher sein soll, mit so Milchmädchenrechnungen, ich glaube es geht los
09:44:39 joggel: okay... ich werf mal meine Frage jetzt rein^^
09:44:46 joggel: folgendes Bild: https://ibb.co/vJkB4Zx
09:45:17 joggel: Der rechte Bereich ist viel zu breit. Wie zur hölle bekomme ich das auf eine Breite die ich selber angebe?
09:45:57 IceMichael: ah, splitter sizes angeben ist ätzend und leider etwas buggy. Layouting sollte auf alle Fälle abgeschlossen sein (und das passiert nicht komplett synchron...), aber dann kann man
09:46:15 IceMichael: https://doc.qt.io/qt-5/qsplitter.html#setSizes nutzen
09:46:33 IceMichael: du meintest jetzt programmatisch, oder? Ich weiß gerade nicht, wie die properties das abdecken
09:47:04 IceMichael: und sorry für den rant...
09:47:16 joggel: Naja, zur Not auch im Code. Aber dachte das das evtl im Designer auch geht
09:48:45 joggel: aber dieses QSplitter::setSizes(..) verstehe ich nicht. Welche sizes? Und wieso ist das eine Liste?
09:49:58 IceMichael: also es ist nicht soo geil dokumentiert, bei mir haben pixel sizes gut funktioniert
09:50:18 IceMichael: setSizes({100,200}) bei width=300 macht linken Splitterteil 100px breit und rechten 200px breit
09:50:44 IceMichael: ist width zB 600 SOLLTE er es zwar auch 1:2 aufsplitten, das funktioniert bei mir aber nicht immer
09:50:52 IceMichael: hab wie heute hier leider auch damit viel Zeit verschwendet...
09:50:58 joggel: ich teste auch mal per HardCode
09:51:08 IceMichael: ok, viel Erfolg!
09:51:37 IceMichael: falls dein Layout sich im Aufbau befindet, kannst du (testweise) setSizes in nem Timer mal setzen, bei mir musste ich setSizes ganz am Ende machen
09:52:25 joggel: ok
10:18:44 joggel: Okay... das mit dem QSplitter::setSizes funktioniert schon mal
10:18:55 joggel: nun noch eine Frage
10:21:41 joggel: oder ich probiere erst mal
10:21:50 joggel: hihi proBIERe^^
10:28:22 joggel: okay. klappt alles :)
11:13:44 IceMichael: hehe, bier
11:13:49 IceMichael: freut mich zu hören :)
12:14:20 joeydee joined the channel
12:16:01 joeydee: Wieder so ne Stilblüte: "Give your drawings a general polish" - "Gib deinen Zeichnungen ein allgemeines Polnisch"
12:20:49 IceMichael: :D