Eine Qt>2 Lizenz für Windows ist allerdings ein bisschen pricey.
Für nicht kommerzielle Projekte die (auch) unter Windows laufen sollen wohl ein Argument gegen Qt.
Beiträge von Lord Binary
-
-
-
Hab ja nicht behauptet, daß dieses Ergebnis
(realloc meistens schneller als new/delete/new) überraschend ist.
Eher als "Rechtfertigung" für meine Verwunderung
Ja, ich seh' da genauso wie PK auch keine (wirkliche) ERKLÄRUNG.
Auch wenn's natürlich richtig ist, daß vectoren/STL nett sind, und oft realloc ersetzen können.
(Und natürlich elegant und praktisch sind)
Aber nicht immer ... ich meine da insbesondere den Overhead, den man nicht in allen Fällen vernachlässigen/akzeptieren kann.
Es gibt natürlich noch andere Möglichkeiten, z.B Templates für Arrays mit speziellem Speichermangement (u.a realloc) zu definieren, den globalen new operator neu zu implementieren, (u.a mit realloc Eigenschaften) und, und, und, ...
aber alles eher Profi stuff ...
Kurzum: Verstehs noch immer ned ..
Aber danke für Eure Antworten, renew scheint's halt nicht zu geben ... Punktum ... -
Vielleicht eine etwas merkwürdige und umständlich formulierte Frage, aber ich stell sie trotzdem mal
old-school C: Da gibts malloc zum anfordern von dynamischem Speicher (am Heap), delete um ihn wieder freizugegeben.
Das entspricht in C++ new und delete.
Grob gesprochen ...
Oki, soweit nichts Aufregendes
In C gibt's auch realloc ... welche Entsprechung hat das in C++ ?
Das ist etwas wohl eine merkwürdige Frage .. braucht noch ein paar Präzisierungen ...
Natürlich kann man auch in C++ malloc & friends verwenden ... sollte man halt nur konsequent machen ...
Das ist mir klar ...
Ebenso, daß der globale "compiler default" new operator in der Regel einfach nur ein kleiner "Wrapper" für malloc ist.
(Muß nicht sein, ist aber in der Regel so)
Also, angenommen ich möchte in einem C++ Programm auf malloc & co ganz verzichten, wie kann ich die Funktionalität von realloc bekommen ?
Bleibt nur ptr=new[size], delete[] ptr, ptr=new[newsize] ... ?
Gut, letzlich tut realloc nichts anderes.
Aber in meinem Fall ist realloc nachweislich deutlich(!) flotter als new/delete.
Wenn ich nun realloc verwenden will, müßte ich aber die entsprechenden new/deletes in malloc/frees umwandeln.
-> eher hässlich.
-> Gibts tatsächlich kein renew[] oder Ähnliches in C++?
Nun, letzlich hab ich mein konkretes Problem durch Vermeidung "gelöst". Speichermanagement redesignt.
Mfg, LB -
Zitat
aber bei der tu studentenlizenz gibts aber auch keinen reparatur punkt, bei einer vollversion allerdings schon....
doch.
zumindest bei meiner tu-studentenversion ... -
Doch, mich, thx for info
Wußte, daß es geht, aber nicht wie.
Eigentlich sehr einfach. -
Fav-Strasse 9-11, insbesondere Sem 185/2, 184/2-3.
Gut möglich daß ich ziemlich alleine bin mit diesem Begehr' :shinner:
Aber das war ja nicht gefragt ... -
-
Zitat
PPP over Ethernet (PPPoE)aon.at ist einmalig
Im Umgang mit Kunden und daß pppoe nicht unterstützt wird.
Man braucht pppd.
Wenn der router das nicht untersützt siehts schlecht aus.
sprich
Zitat
Brauch ich gar eine anderen Router?denke ja, wenn's kein pppd gibt.
-
Anmerkung: signatur updates funktionieren nur im tu net.
wenn man das nicht automatisch ist (z.B "tu asdl"), ein bisschen mühsam.
zur konkrete frage: keine ahnung -
Nixda, damit war auch RAM gemeint
Nicht unähnlich zu so tollen Sachen wie Linux unter Vmware für Windows laufen zu lassen.
Zitat
Wobei, die Tools of Choice für mich zum arbeiten mit NTFS-Dateisystemen sind eher fdisk und mkfs ;>
:devil: -
Zitat
Allerdings gibt's eine Lösung ähnlich ndiswrapper für verkrüppelte WLAN-Karten, nur eben für den NTFS-Dateisystemtreiber, nennt sich Captive.
ntoskrnl.exe kommt mir nicht auf meine Linux Kiste :))) -
Nein, nur mit vielen unpraktibaklen Einschränkungen.
z.B können keine neuen Datein erstellt werden. -
Zu dem was amok und Plantschkuh gesagt haben, gibts eigentlich nichts oder fast nichts mehr hinzuzufügen.
Eleganz ist ohnehin subjektiv.
Wichtiger ist ganz genau zu wissen, was ein
#define, const keyword, enum .. etc tut.
Kanns nur nochmal betonen, daß const's oft nicht das tun was man sich intuitiv erwartet.
Sich genau zu üerlegen, WARUM globale Variablen
problematisch sein können und warum machmal doch nicht.
Dann von Fall zu Fall entscheiden.
Allgemein gültige Regeln dazu gibts IMHO nicht.
z.B
NIEMALS globale Variablen benutzen.
Niemales #defines benutzen.
consts sind immer eleganter als #defines, ...
Alles nonsense.
Yo! -
Ok, agree
Power over Ethernet: Das waren alles properitäre "Lösungen", sprich der AC muß das explizit unterstützen etc.
Hatte mal so einen installiert, funktioniert problemlos seit Jahren. Allerdings ein "very high price" Ding.
Standardisiert ist POE erst seit ca einem Jahr,
nennt sich IEEE 802.3af DTE Power via MDI.
Keine Ahnung ob's da schon was gibt bzw keine Erfahrung damit.
Kurzversion: Gut funktionieren tut's schon, aber ist wohl schwer einen AC zu finden, der das kann und "leistbar" ist. -
Zitat
hab meine Vorstellungen mitlerweile wieder bissal abgeändert. ich wür die AP's natürlich über einen switch untereinander und mit dem server Verbinden.
Ist definitv sehr zu empfehlen, aber:
... dann gibt's ja erst recht wieder mühsame Kabelverlegerei ?!?
Ist da noch ein großer Unterschied - aufwandsmäßig - zu vollem Kabel-Lan ? -
hmmm, also vor zwei Wochen oder so gings.
(Allerdings mit einem Windows Centrino Laptop)
WLAN aktiviert bei deinem Account ?
Per KOM Account management ?
Kein WEP, nur SSID=tunet ? -
Tja, am besten den Hersteller damit nerven.
Klingt ein bisschen nach Kopierschutz.
bzw Problemen damit.
Mancht machmal auch Probleme bei Originalen.
"Offiziell" geben das Hersteller eher nur selten zu.
Aber das ist nur geraten. -
Errrrr, seit wann zählt denn z.B emule zu Warez ?
(es gibt genug freeware "saug-progs")
Was mit dem Ding gemacht wird, darum ging's ja ned.
Darüber sollte man tatsächlich hier schweigen
(und geniessen)
Also, emule -> http://www.emule.de
Nick des urspünglichen Posters, den find ich auch grenzgenial
Den Rest ... weniger
Mfg, LB -
Erspart nicht das Verlegen von Kabeln, und ohne (meist teuren) GB-Switch kein Unterschied zu fast Ethernet.