Original von M.A.X.
Vor allem Mac User achten auch auf das Äußerliche und eine QT-Oberfläche ist in den meisten Fällen einfach nur hässlich...

Dem kann ich persönlich nur voll und ganz zustimmen! Ein Mac OS X Programm welches nicht wie Mac OS X aussieht und sich auch nicht so bedienen lässt wird nicht lange auf meinem Mac verweilen dürfen.

Ein Grund, warum OpenOffice/NeoOfficeJ auch nur zu Analysezwecken für ein Projekt auf meinem Mac verweilen dürfen und nicht wirklich produktiv eingesetzt werden.

Ich würde ein plattformübergreifendes Programm entweder mit Java/Swing (wobei mir Swing nicht wirklich gefällt), oder noch besser unter MVC entwickeln und die Oberflächen an jedes OS individuell anpassen. Letztes ist zwar aufwändiger jedoch passt das Ergebniss sehr viel besser zum jeweiligen OS als ein Standard GUI, welches verschiedene Betriebssystem abdecken muss. Mit MVC hast Du weiterhin den Vorteil dass die Logik komplett vom GUI getrennt ist und quasi als eigenständiges Framework implementiert werden kann und somit auch wiederverwendbar wird.

In Deinem Fall implementiere die Logik daher einfach komplett in C++ (auch wenn jetzt wieder einige meckern werden) und dann kannst Du erst einmal das GUI unter Mac OS X mit Objective-C++ implementieren (geht mit Hilfe des Interface Builder auf alle Fälle viel schneller als direkt mit qt zu Fuss). Wenn Dein Programm dann komplett läuft und entsprechend MVC aufgeteilt ist, dann kannst Du das qt Fontend, in einem weitern Projekt welches nur auf den Model-Teil aufsetzt, implementieren und schon hast Du Dein Programm für alle qt Plattformen zur Verfügung. Ich würde jedoch wetten, dass fast 100% der Mac OS X Anwender das Cocoa Fontend Deines Programmes installieren werden.

Zum Einstieg in MVC lies Dir doch schon einmal mal das hier durch.

Michael

hmm, hast du QT nach /Developer/qt entpackt? Geht das Zeug unter /Developer/qt/examples/ ? Benutzt du Xcode?

Du mutmaßt zu wissen, was ein String sein könnte, den du außerhalb des reservierten bereiches zusammenkettest.

BTW: Wer hat hier erst in den letzten Tagen Arrays und Pointer verwechselt? Ich habe mich aus dem Thread mal herausgehalten ...

Also, einiges ist hier ja schon gesagt worden:

1. Portierung ist nicht nur Frage des Frameworks. Damit kann man das zwar leidlich hinbekommen, aber man bleibt auf einem "Zwischensystem". Nichts Ganzes und nichts Halbes.
2. Man benötigt zu allererst eine Programmiersprache, die auf allen System läuft.
3. Man muss im MVC - Paradigma programmieren. Das erspart einen 90 % der Portierungsarbeit.
4. Die Views sollte man nativ programmieren. Dies ist in der Regel ohnehin der kleinste Teil der Arbeit, weil System - Views weit bringen.

Das Ganze ist also eine Frage des Systems, nicht eine Frage des Frameworks xyz.

Ich streite mich nur ungern mit dir, aber was sollen bitte die vorwürfe

Original von Tom9811
Du mutmaßt zu wissen, was ein String sein könnte, den du außerhalb des reservierten bereiches zusammenkettest.

hä? was du meinen?

BTW: Wer hat hier erst in den letzten Tagen Arrays und Pointer verwechselt?

Dann erkläre mir bitte den Unterschied. Und bitte auch, woran ich erkenne, ob char* ein Array ist oder nur ein Pointer. Mir ist klar, dass ein array nur mit einem Pointer deklariert wird. Und wo hab ich hier was verwechselt?

Ich habe mich aus dem Thread mal herausgehalten ...

Hättest du's doch nur getan.

Original von Tom9811
Du mutmaßt zu wissen, was ein String sein könnte, den du außerhalb des reservierten bereiches zusammenkettest.
hä? was du meinen?

Ziemlich genau das. Geh mal auf die Seite irgendeines Sicherheitsdienstleisters und suche dort nach Buffer Overflow & Co. Du hast bestimmt eie Trefferquote von > 80 %.

Ohne C-Arrays gäbe es kaum ein Sicherheitsproblem ...

Dann erkläre mir bitte den Unterschied. Und bitte auch, woran ich erkenne, ob char* ein Array ist oder nur ein Pointer. Mir ist klar, dass ein array nur mit einem Pointer deklariert wird. Und wo hab ich hier was verwechselt?

Bisher meinte ich gar nicht, obwohl du dich irgendwie auch daran beteiligt has, allerdings mutmaßlich, weil der OP sich schlecht ausdrückte.

Unterschiede? Die Frage müsste eigentlich lauten, was sie gemeinsam haben. Die Antwort darauf: Alleine den Datentypen, sonst rein gar nichts. Ein paar Beispiele:



Ein Array hat soviel gemeinsam mit einem Pointer wie mit einem Integer abzgl. einer Warning. Das war's.

Original von Tom9811
Ziemlich genau das. Geh mal auf die Seite irgendeines Sicherheitsdienstleisters und suche dort nach Buffer Overflow & Co. Du hast bestimmt eie Trefferquote von > 80 %.

Ohne C-Arrays gäbe es kaum ein Sicherheitsproblem ...

was hat das jetzt mit dem thema zu tun. Von malloc noch nie was gehört.

Unterschiede? Die Frage müsste eigentlich lauten, was sie gemeinsam haben. Die Antwort darauf: Alleine den Datentypen, sonst rein gar nichts. Ein paar Beispiele:

nett. Vielleicht legst du das string auch falsch an:


damit sind array1 und array2 beides array, auf die du über die selben indizes zugreifen kannst du wenn du jetzt nach lenght() von beiden fragst, dann bekommst du das selbe. nach sizeof zu fragen ist reichlich sinnbefreit.

Ein Array hat soviel gemeinsam mit einem Pointer wie mit einem Integer abzgl. einer Warning. Das war's.

Vielleicht verwundert es dich, aber ein pointer ist auch nur ne int.

was hat das jetzt mit dem thema zu tun. Von malloc noch nie was gehört.

Es hat etwas mit dem Thema Unterschiede Pointer und Arrays zu tun.
Ob ich etwas davon gehört habe? Klar, das ist aber irrelevant. Die Programmierer der Sicherheitslöcher haben übrigens davon noch nie etwas gehört. Das sind alles Idioten. Nur Max nicht, der ist schlau, nur merkt man es an seinen "Ratschlägen" nicht ...

nett. Vielleicht legst du das string auch falsch an:

Wenn man es unterschiedlich anlegen muss, sind sie nicht gleich. Das gebieten bereits die Denkgesetze.
Notier dir das also gleich als weiteren Unterschied ...
Ach ja, was ich noch sagen wollte: Sie haben den gleichen Datentypen, sonst nichts gemeinsam, siehe deine Anmerkung.

damit sind array1 und array2 beides array

Nein, sind sie nicht.

haben nicht die gleiche Wirkung.
Ach ja, was ich noch sagen wollte: Sie haben den gleichen Datentypen, sonst nichts gemeinsam, siehe deine Anmerkung.

Vielleicht verwundert es dich, aber ein pointer ist auch nur ne int.

Abgesehen davon, dass das nicht stimmen muss, weil die Datenlänge unterschiedlich sein kann. Sieht man davon ab, dann ist jeder skalare Datentyp auch nur ein int.
So kann man das sehen. Das hat dann allerdings nichts mit Hochsprachen zu tun.

Original von Tom9811
Es hat etwas mit dem Thema Unterschiede Pointer und Arrays zu tun.
Ob ich etwas davon gehört habe? Klar, das ist aber irrelevant. Die Programmierer der Sicherheitslöcher haben übrigens davon noch nie etwas gehört. Das sind alles Idioten. Nur Max nicht, der ist schlau, nur merkt man es an seinen "Ratschlägen" nicht ...

Ich kann mir nicht helfen aber dein Sicherhietsgequatsche hat nichts mit arrays und pointern zu tun, sondern mit Fehlern in Programmen.

Wenn man es unterschiedlich anlegen muss, sind sie nicht gleich. Das gebieten bereits die Denkgesetze.

Wenn du damit gearbeitet hättest wüsstest du es besser. Denn das speziell angelegte ist ein dynamisches Array, das andere ein statisches. Warum wird char[] auch akzeptiert, wenn du char* übergeben musst?????? Weil der compiler die statischen Array so übersetzt, dass es doch nur wieder ein pointer ist, nur dass du dich nicht um anlegen und zerstören kümmern musst. Aber das geht wohl zu weit...

Nein, sind sie nicht.

Quellcode

1. free( array1 );
2. free( array2 );

Doch sind sie. Das eine ist ein statisches Array und das andere ein dynamisches. Aber das geht wohl zu weit. Nur so viel: statisch brauchst du nicht befreien, dynamische solltest du.

Abgesehen davon, dass das nicht stimmen muss, weil die Datenlänge unterschiedlich sein kann. Sieht man davon ab, dann ist jeder skalare Datentyp auch nur ein int.

Es gibt ja nicht nur einen typ von integern. int hat bei mir als abkürzung fungiert, nicht als datentyp. Und wenn, dann ist es auch egal, nimm nicht alles so pingelich. pointer sind UInt32s auf einer 32-bit cpu und (wer hätte es gedacht) UInt64 auf 64-bit cpus.

Will mich ja nicht einmischen...

Ich haette gesagt, ein Array ist eine Aneianderkettung von Speicherbereichen. Der Datentyp gibt die groesse des Bereichs an, der gelesen oder geschrieben werden soll. Man kan aso durch casting byteweise oder 4byte weise lesen oder schreiben.

Wie man das Array nun erzeugt, ob:


oder so:


ist meiner Meinung nach voellig egal.

Nein, weil du im letzteren Falle ein Mem Leak hast.

Du kannst über einen Pointer ein Array erzeugen. Du kannst auch ein Array an einen Pointer zuweisen. Das war es.

Du kannst auch über einen int ein Array erzeugen. Du kannst das sogar über einen float, wenn du nur ordentlich castest.

Original von Tom9811
Nein, weil du im letzteren Falle ein Mem Leak hast.

Naja, klar. Mass muss halt zwischen statisch und dynamisch erzeugt unterscheiden.
Das dynamische muss man halt explizit wieder free'n, weil es auch in einem anderen Speicherbereich angelegt wurde (Heap).
Das erledigt sich bei statischen Arrays automatisch entweder durch Stack oder statischer Programm-Speicher, die wieder freigegeben werden, wenn es an der Zeit ist.


so long

Ebendt(tm)!