Seite 39 von 252

Re: Jammer-Thread

Verfasst: 12.09.2011, 19:31
von CodingCat
Mit noch mehr Lifecycle-Management- und Workflow-Tools!

Bild

Nächster Halt: Der Auftraggeber IST der Programmierer, und entwickelt Software in bunten Wolkendiagrammen.

Bonus: Ein veraltetes Boost.FileSystem, gratis und built-in!

The true native Renaissance: Kleinkinder brauchen kein Spielzeug für Erwachsene.

Re: Jammer-Thread

Verfasst: 12.09.2011, 19:35
von klickverbot
Aber Kristhy, dafür sind deine std::vector-Instanzen jetzt 4 Byte kleiner! :P

Re: Jammer-Thread

Verfasst: 12.09.2011, 19:35
von Chromanoid
Es erfüllt mich immer wieder mit Häme wenn ich diesen Thread hier, der ja eine Art C++ jammer-Thread ist, mit dem Java Hass Thread vergleiche. :D

Re: Jammer-Thread

Verfasst: 12.09.2011, 19:37
von CodingCat
Wieso? Weil Java seit Jahren nicht mal die elementarsten Sprachfeatures richtig auf die Reihe kriegt? ;-)

Re: Jammer-Thread

Verfasst: 12.09.2011, 19:39
von Chromanoid
Wahrscheinlich ;) :D

Re: Jammer-Thread

Verfasst: 12.09.2011, 19:42
von Aramis
Naja, manche Dinge sind es eben nicht wert dass man ueber sie jammert :-)

Re: Jammer-Thread

Verfasst: 12.09.2011, 19:57
von Krishty
Mein Einwand wäre eher gewesen, dass die C++’ler hier ausschließlich über fremdes Versagen jammern, während Javanoiden die Fehler grundsätzlich früher oder später bei sich selber finden ;)

Re: Jammer-Thread

Verfasst: 12.09.2011, 20:42
von Chromanoid
Das ein ganz besonderer Pluspunkt für C++, nicht wahr :D

Re: Jammer-Thread

Verfasst: 12.09.2011, 21:41
von j.klugmann
CodingCat hat geschrieben:Wieso? Weil Java seit Jahren nicht mal die elementarsten Sprachfeatures richtig auf die Reihe kriegt? ;-)
Muahahaha, C++ doch auch nicht, oder? :P

Re: Jammer-Thread

Verfasst: 13.09.2011, 11:57
von Aramis
Ich habe einen Antwortbash fuer Haskell vorbereitet, und der wird Legen … wait for it … wait for it … hold on … uh das wird heute nichts mehr, aber ich kann dir formal nachweisen dass er irgendwann mal lazy ausgefuehrt werden wird … :P

Re: Jammer-Thread

Verfasst: 13.09.2011, 12:33
von kaiserludi
Aramis hat geschrieben: … wait for it … wait for it … hold on … uh das wird heute nichts mehr [...] lazy
Hat was :lol:

Re: Jammer-Thread

Verfasst: 13.09.2011, 12:51
von Schrompf
Abseits aller Programmiersprachen-Sticheleien: mich kotzt das mächtig an. Es gibt eine Menge schicker C++0x-Features, die mein Leben wirklich angenehmer machen würden. Und ich kann mir ehrlich nicht vorstellen, welches Feature davon einen einzelnen VC-Programmierer für mehr als ein paar Tage beschäftigen würde. WARUM ZUR HECKE baut die Features also nicht ein?

Re: Jammer-Thread

Verfasst: 13.09.2011, 13:55
von CodingCat
Many of you complained that Visual Studio offered several ALM features, only when talking about .NET development.
[...]
There were more, though: productivity features in the IDE. How could it happen that something so well-established in the .NET worlds like Code Snippets were never available in C++? That was what many of you guys asked us as well.
[...]
C++ AMP for heterogeneous parallelism in CPUs, GPUs and other cores.
[...]
In this struggle to put C++ back at the main scene, we must decide and allocate resources wisely in order to get some progress in ALM, developer productivity –including performance-, C++11 standard compliance, parallelism, and many other aspects related with your ultimate goal, that is shipping software.
Na klar, ALM und IDE statt Sprachfeatures! Textfarbe ist eh immer wichtiger als der Inhalt.
A careless answer would state "because MS just doesn't care."
Puh, dann ist ja gut.
Stephan T. Lavavej hat geschrieben:Since January 2007 (when I moved from Outlook Search to VC Libraries), I've been the only MS dev working on the STL. I work with Dinkumware, headed by P.J. Plauger - the original author of the C++ Standard Library implementation that MS has licensed.
S.T.L. arbeitet alleine an der STL?
I assume you have a dedicated compiler team. What have they been working on?
This story has a happy ending, though! Jonathan Caves, our compiler front-end lord, investigated this and found that something our tuple implementation was doing [...]
Ah, klar, Bugfixing! Warte, sprachen wir von Team?

Re: Jammer-Thread

Verfasst: 13.09.2011, 15:16
von j.klugmann
Aramis hat geschrieben:Ich habe einen Antwortbash fuer Haskell vorbereitet, und der wird Legen … wait for it … wait for it … hold on … uh das wird heute nichts mehr, aber ich kann dir formal nachweisen dass er irgendwann mal lazy ausgefuehrt werden wird … :P
Haskell ist eindeutig schneller als du denkst. ;)

Re: Jammer-Thread

Verfasst: 13.09.2011, 15:18
von j.klugmann
Schrompf hat geschrieben:Abseits aller Programmiersprachen-Sticheleien: mich kotzt das mächtig an. Es gibt eine Menge schicker C++0x-Features, die mein Leben wirklich angenehmer machen würden. Und ich kann mir ehrlich nicht vorstellen, welches Feature davon einen einzelnen VC-Programmierer für mehr als ein paar Tage beschäftigen würde. WARUM ZUR HECKE baut die Features also nicht ein?
Das ist sowieso das größte Problem. Es gibt einen recht guten Standard und auch die Compiler sind wirklich gut, allerdings nützt einem der Standard auch nichts, wenn niemand ihn richtig implementiert. Das ist eigentlich der zentrale Kern meiner Kritik an C++. ;)

Re: Jammer-Thread

Verfasst: 13.09.2011, 18:40
von Krishty
Ich habe heute festgestellt, dass VC (ohne Nutzung von Intrinsics und speziellen Datentypen) deutlich besseren Gleitkomma-Vektortext erzeugt, wenn man allen seinen Vektoren und Matrizen einen operator = () gibt, der via memcpy() implementiert ist.

So vom Augenmaß her würde ich auf 20 % weniger Anweisungen (insbesondere mov) tippen; kann es aber nicht objektiv messen, da jetzt auch wesentlich mehr Funktionen geinlined werden als vorher.

Meine Vermutung ist: struct Vector { double x, y, z; }; verarbeitet der Compiler von Haus aus so, dass jede Zahl einzeln in ein XMM-Register geladen und verarbeitet wird. Erst durch das memcpy() – das ja als Intrinsic implementiert ist und versucht, 128 Bits auf einmal durch die Register zu schieben – bekommt man zufälligerweise hin, dass der Compiler auch mal zwei Zahlen in dasselbe Register schiebt und dann plötzlich erkennt, dass er die ja parallel verarbeiten kann und nebenbei noch deutlich weniger Register verbraucht.

Einen Kopierk’tor mit memcpy() konnte ich nicht testen, weil meine Klassen dann endgültig den POD-Status eingebüßt hätten und noch langsamer geworden wären.

Das muss man sich mal reinziehen: Nicht einmal POD kriegt diese Wurst von Compiler optimiert.

Re: Jammer-Thread

Verfasst: 13.09.2011, 20:15
von kaiserludi
Lasst uns einfach auf MS solange Druck ausüben, bis sie Krishty als weiteren Compiler-Coder einstellen, damit er das Ding mal füruns auf Vordermann bringt :)

Re: Jammer-Thread

Verfasst: 13.09.2011, 20:44
von Krishty
Lasst uns einfach alle auf Clang umsteigen und glücklich werden

ohne tausend Dollar dafür hinzublättern, dass wir jetzt alle Stakeholder in bunten Wolkendiagrammen einordnen können

Re: Jammer-Thread

Verfasst: 13.09.2011, 21:08
von kaiserludi
Cloud-Computing ist halt in ;)
Clang ist auch nicht perfekt, habe ich auch schon genug Issues mit gehabt (wenn ich mich recht ensinne, war es Clang, der bei dem Code "if(a = b)" nicht nur wie der GCC via Warning gefragt hat, ob ich auch wirklich nicht "if(a == b)" meine, sondern der nicht mal bei "if((a = b))" oder gar "if(!!(a=b))" Ruhe gab. Dass er mich da unbedingt zu "if((a = b) != false)" zwingen will, empfinde ich da einfach als Bevormundung. Der Maschinencode ist hinterher eh der gleiche; wenn ich nicht mehr selbst entscheiden darf, ob ich eine Zuweisung implizit oder explizit auf true teste, dann kann ich ja gleich in C# coden...).

Re: Jammer-Thread

Verfasst: 14.09.2011, 12:33
von Schrompf
Ich habe gerade eben eine Rundmail unseres internen Forums bekommen, in der ich zur üblichen Splitterwelten-Teamkonferenz einlade. Vom 12. März 2011. Kein Wunder, dass zu dem Meeting kaum jemand da war.

Was ist aus dieser Welt geworden, wenn man sich nichtmal mehr auf so primitive Sachen den Mailer verlassen kann.

Re: Jammer-Thread

Verfasst: 14.09.2011, 13:04
von CodingCat
Kein C++11 und dafür ein neues C++/CLI. Da wird der schönste Tag zum Alptraum.

Re: Jammer-Thread

Verfasst: 14.09.2011, 16:53
von eXile
'std::tr1::shared_ptr<_Ty> std::tr1::make_shared(_Arg0 &&,_Arg1 &&,_Arg2 &&,_Arg3 &&,_Arg4 &&,_Arg5 &&,_Arg6 &&,_Arg7 &&,_Arg8 &&,_Arg9 &&)' : expects 10 arguments - 11 provided

Fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck fuck. Was ist der schönste Weg _NMAX höher zu stellen?

(Variadic templates gibt es übrigens ja auch mit Visual Studio vNext nicht.)

Nachtrag: In der Dokumentation steht das ganz klar als variadic template drin. Und nichts von _NMAX = 10. Damit würde ich das schon fast als Fehler bezeichnen.

Noch ein Nachtrag: Ich habe weiter in den Headern gewühlt; es scheint sogar noch mehr als nur _NMAX mit der 10 verdrahtet worden sein. Ich wette, das hat einer von Hand geschrieben. Jetzt hab ichs halt auf zwei Zeilen aufgeteilt. Alles Mist.

Re: Jammer-Thread

Verfasst: 14.09.2011, 18:27
von kaiserludi
Wenn man nicht alles selber macht:
Wie zur Hölle kann man auf die Idee kommen, einen bool Parameter names useTcp, bei dem false zu udp führt, auf eine andere Platform zu portieren, indem man ihn in useUdp umbenennt und false dann tcp bedeutet?

Re: Jammer-Thread

Verfasst: 15.09.2011, 11:09
von glassbear
Ich habs getan. :cry: :cry: :cry:

Re: Jammer-Thread

Verfasst: 15.09.2011, 13:28
von kaiserludi
Was mich an Clan auch stört, ist, dass er nicht in der Lage ist, bei ">>" abhängig vom Kontext zu ermitteln, ob es sich um 2 schließende Klammern eines geschachtelten Templates handelt oder um den >>-Operator, so dass man bei Templates immer "> >" schreiben muss. Die Leerstelle wirkt stylistisch einfach hässlich und VS checkt auch prima ohne sie, wann es um Templates geht.

Re: Jammer-Thread

Verfasst: 15.09.2011, 14:02
von joggel
was ist Clan?
Um weiterzujammern:
Qt sucks(heute zumindest)


Edit:
Naja. Zumindst bin ich heute zu blöd.
Ein Dockwidget, das 2 Frames enthält, eines davon ist eine Scrollarea sammt Inhalt. Nur irgendwie zeigt der nicht die Scrollbar an.
Ich verstehs nicht... :x

Re: Jammer-Thread

Verfasst: 15.09.2011, 14:18
von CodingCat
Vermutlich redet er von Clang. Soweit ich weiß, erkennt auch Visual Studio erst in der aktuellsten Version mehrere ungetrennte schließende Template-Klammern als solche. Tatsächlich wird dieses Verhalten auch erst ab C++11 vom Standard vorgeschrieben, zuvor wurde es im Standard so nicht spezifiziert, d.h. das Nichterkennen ist bis C++03 korrektes Verhalten. Sofern Clang konsequent C++11 Features aufnimmt, wird also auch diese Verhalten dort irgendwann zu finden sein.

Re: Jammer-Thread

Verfasst: 15.09.2011, 15:18
von kaiserludi
CodingCat hat geschrieben:Vermutlich redet er von Clang. Soweit ich weiß, erkennt auch Visual Studio erst in der aktuellsten Version mehrere ungetrennte schließende Template-Klammern als solche. Tatsächlich wird dieses Verhalten auch erst ab C++11 vom Standard vorgeschrieben, zuvor wurde es im Standard so nicht spezifiziert, d.h. das Nichterkennen ist bis C++03 korrektes Verhalten. Sofern Clang konsequent C++11 Features aufnimmt, wird also auch diese Verhalten dort irgendwann zu finden sein.
Ja, irgendwie vergesse ich das g in clang immer :oops:
Visual Studio versteht das selbst in Version 2005 aka VS 8 bereits. Aber immerhin, bei Clan ist davon auszugehen, dass die C++ 11 auch tatsächlich relativ schnell im wesentlichen vollständig unterstützen, bei VS weiß man das nie so genau, C99 Support haben sie ja bis heute noch nicht...

Re: Jammer-Thread

Verfasst: 15.09.2011, 15:25
von CodingCat
kaiserludi hat geschrieben:Visual Studio versteht das selbst in Version 2005 aka VS 8 bereits.
Tatsächlich, auf diese Besonderheit ist man so häufig hingewiesen worden, dass man es gar nicht mehr versucht hat. ;-)

Re: Jammer-Thread

Verfasst: 15.09.2011, 15:31
von Aramis
Nun, ich wuerde einfach praeventiv fuer die naechsten 5 Jahre > > schreiben. Man will ja als braves kleines Programmierlein nicht anecken.