amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > UniverC [ - Search - New posts - Register - Login - ]

-1- [ - Post reply - ]

2003-12-03, 21:36 h

mrbbc
Posts: 101
User
Zitat:
Original von Mad_Dog:
Zitat:
Original von mrbbc:
Das ist aber eben meine Rede: warum so viel Arbeit ins Portieren einzelner Programme verschwenden, wenn man mit einer universellen Bibliothek nur neu kompilieren bräuchte...

Wie willst Du das den anstellen? Das Problem bei Portierungen sind System-Api Aufrufe bzw. GUI-Elemente. Ferner gibt's da noch das Endian-Problem. Mit einer Bibliothek wie der ixemul ist es nicht getan. Aber wenn Du einen interessanten Ansatz hast - her damit. :)

Zum einen ist Endian kein großes Problem in C: ein Quelltext verhält sich unter beiden Plattformen weitgehend identisch, solange man nicht z.B. in einem 32-Bit-Wert byteweise zugreift.

Problem 2 sind Dateien, die von der verkehrten Plattform erzeugt wurden. Für das kann man aber einfach eine Kennung einbauen, wie bei Unicode/UTF16, wodurch man weiss, dass man die Codes alle spiegeln muss.

Funktionen zum Umdrehen von Integerwerten sind ausserdem schon vorhanden.

Die System-API-Aufrufe werden alle neu abgebildet. Fehlende GUI-Elemente gegf. nachprogrammiert. Bestimmte Features, die eine Plattform nicht hat, z.B. Tray-Icons, liefern beim Versuch nur eine Fehlermeldung zurück.

Grundsätzlich basiert alles darauf, dass man klar definiert, was die Funktionen machen, und das dann einfach auf jeder Zielplattform so gut es geht umsetzt.

Zitat:
Was schwebt Dir den da konkret vor? X-Aufrufe nach Intuition umleiten etwa ?

UniverC ist wie eine vollständige API - oder wie die ISO C Bibliotheken, nur mit allen Funktionen die man für alle Arten von Programmen braucht.

Man muss also ein Programm schon mit den UniverC-Funktionen schreiben...

--
it obvisiously seems to have been hard to write

[ - Answer - Quote - Direct link - ]
2003-12-04, 08:12 h

Solar
Posts: 3680
User 		Wir hatten uns ja schon einmal darüber unterhalten, trotzdem nochmal die Frage:

Wo ist, für einen nicht-Amiganer, der Mehrwert gegenüber z.B. Java, oder C#?

Ich weiß, ich weiß, ich bin auch kein Freund von C#, und bei Java gehen die Meinungen auseinander.

Aber wie, denkst Du, kannst Du nicht-Amiganer dazu bewegen, sich für UniverC zu interessieren, wenn es u.a. schon die beiden oben genannten Methoden gibt, portierbare, wenn nicht sogar binärkompatible Software zu erstellen?

[ - Answer - Quote - Direct link - ]
2003-12-04, 16:21 h

Mad_Dog
Posts: 1944
User
Zitat:
Original von mrbbc:

Zum einen ist Endian kein großes Problem in C: ein Quelltext verhält sich unter beiden Plattformen weitgehend identisch, solange man nicht z.B. in einem 32-Bit-Wert byteweise zugreift.

Problem 2 sind Dateien, die von der verkehrten Plattform erzeugt wurden. Für das kann man aber einfach eine Kennung einbauen, wie bei Unicode/UTF16, wodurch man weiss, dass man die Codes alle spiegeln muss.

Dann schau Dir mal folgenden Code an:

code:
/*  BMP.c
 *  (Windows-)BMP loader routines for Amiga computers
 *  Author: Norman Walter
 *  Additional ideas by Thore Sitly
 *  Date: 29.12.2002
 *
 *  DISCLAIMER: This software is provided "as is".  No representations or
 *  warranties are made with respect to the accuracy, reliability, performance,
 *  currentness, or operation of this software, and all use is at your own risk.
 */


#ifndef BMP_H
#include "bmp.h"
#endif

/* WORD and LONG SWAP */

#define SWAPW(a) (WORD)(((UWORD)a>>8)+((((UWORD)a&0xff)<<8)))
#define SWAPU(a) (UWORD)(((UWORD)a>>8)+((((UWORD)a&0xff)<<8)))
#define SWAPL(a) (LONG)(((ULONG)a>>24)+(((ULONG)a&0xff0000)>>8)+(((ULONG)a&0xff00)<<8)+ (((ULONG)a&0xff)<<24))

// LoadBMP
// desc: Returns a pointer to the bitmap image of the bitmap specified
//       by filename. Also returns the bitmap header information.
//       No support for 8-bit bitmaps.
unsigned char *LoadBMP(char *filename, BITMAPINFOHEADER *bitmapInfoHeader)
{
    FILE *filePtr;                          // the file pointer
    BITMAPFILEHEADER    bitmapFileHeader;   // bitmap file header
    unsigned char       *bitmapImage;       // bitmap image data
    int                 imageIdx = 0;       // image index counter
    unsigned char       tempRGB;            // swap variable

    // open filename in "read binary" mode
    filePtr = fopen(filename, "rb");
    if (filePtr == NULL)
        return NULL;

    // read the bitmap file header

    fread(&bitmapFileHeader, sizeof(BITMAPFILEHEADER), 1, filePtr);

    // Intel -> Motorola conversion

    bitmapFileHeader.bfType = SWAPW(bitmapFileHeader.bfType);
    bitmapFileHeader.bfSize = SWAPL(bitmapFileHeader.bfSize);
    bitmapFileHeader.bfReserved1 = SWAPW(bitmapFileHeader.bfReserved1);
    bitmapFileHeader.bfReserved2 = SWAPW(bitmapFileHeader.bfReserved2);
    bitmapFileHeader.bfOffBits = SWAPL(bitmapFileHeader.bfOffBits);

    // verify that this is a bitmap by checking for the universal bitmap id
    if (bitmapFileHeader.bfType != BITMAP_ID)
    {
        fclose(filePtr);
        printf("Not a BMP Filen");
        return NULL;
    }

    // read the bitmap information header

    fread(bitmapInfoHeader, sizeof(BITMAPINFOHEADER), 1, filePtr);

    // Intel -> Motorola conversion

    bitmapInfoHeader->biSize = SWAPL(bitmapInfoHeader->biSize);
    bitmapInfoHeader->biWidth = SWAPL(bitmapInfoHeader->biWidth);
    bitmapInfoHeader->biHeight = SWAPL(bitmapInfoHeader->biHeight);
    bitmapInfoHeader->biPlanes = SWAPW(bitmapInfoHeader->biPlanes);
    bitmapInfoHeader->biBitCount = SWAPW(bitmapInfoHeader->biBitCount);

    bitmapInfoHeader->biCompression = SWAPL(bitmapInfoHeader->biCompression);
    bitmapInfoHeader->biSizeImage = SWAPL(bitmapInfoHeader->biSizeImage);
    bitmapInfoHeader->biXPelsPerMeter = SWAPL(bitmapInfoHeader->biXPelsPerMeter);
    bitmapInfoHeader->biYPelsPerMeter = SWAPL(bitmapInfoHeader->biYPelsPerMeter);
    bitmapInfoHeader->biClrUsed = SWAPL(bitmapInfoHeader->biClrUsed);
    bitmapInfoHeader->biClrImportant = SWAPL(bitmapInfoHeader->biClrImportant);

    // allocate enough memory for the bitmap image data
    bitmapImage = (unsigned char*)malloc(bitmapInfoHeader->biSizeImage);

    // verify memory allocation
    if (!bitmapImage)
    {
        free(bitmapImage);
        fclose(filePtr);
        return NULL;
    }

    // move file pointer to beginning of bitmap data
    fseek(filePtr, bitmapFileHeader.bfOffBits, SEEK_SET);

    // read in the bitmap image data

    fread(bitmapImage, 1, bitmapInfoHeader->biSizeImage, filePtr);

    // make sure bitmap image data was read
    if (bitmapImage == NULL)
    {
        fclose(filePtr);
        return NULL;
    }

    // swap the R and B values to get RGB since the bitmap color format is in BGR

    for (imageIdx = 0; imageIdx < bitmapInfoHeader->biSizeImage; imageIdx+=3)
    {
        tempRGB = bitmapImage[imageIdx];
        bitmapImage[imageIdx] = bitmapImage[imageIdx + 2];
        bitmapImage[imageIdx + 2] = tempRGB;
    }

    // close the file and return the bitmap image data
    fclose(filePtr);
    return bitmapImage;
}

Da kann man auf die Swaps (im Header) nicht verzichten. Oder wie würdest Du das sonst machen?

Zitat:
UniverC ist wie eine vollständige API - oder wie die ISO C Bibliotheken, nur mit allen Funktionen die man für alle Arten von Programmen braucht.

AFAIK ist in Geek Gadgets doch auch ein UniverC Compiler enthalten?
Hab's noch nicht angetestet...

Zitat:
Man muss also ein Programm schon mit den UniverC-Funktionen schreiben...

Eben. Da aber die meisten Programme aus der Linux/Windows-Welt in (ANSI) C/C++ geschrieben sind...

...bleibt einem bis weilen nichts anderes übrig, als die (OS-nativen) API-Aufrufe von Hand herauszufriemeln.



--

http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 04.12.2003 editiert. ]

[ - Answer - Quote - Direct link - ]
2003-12-04, 17:11 h

gni
Posts: 1106
User
Zitat:
Mad_Dog:
[Beispiel entsorgt]
*grusel*

[ - Answer - Quote - Direct link - ]
2003-12-04, 19:00 h

Mad_Dog
Posts: 1944
User
Zitat:
Original von gni:
Zitat:
Mad_Dog:
[Beispiel entsorgt]
*grusel*

Yo! :) Versuch mal auf nem Big Endian Rechner ein BMP File ohne den ganzen SWAP-Quatsch zu laden...

Wenn Du einen besseren Vorschlag hast: Her damit. :)
Zumindest funktioniert es so :)

--

http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 04.12.2003 editiert. ]

[ - Answer - Quote - Direct link - ]
2003-12-04, 20:12 h

mrbbc
Posts: 101
User 		Zum einen ist UniverC eine Bibliothek, kein Compiler; ich hätte auch nichts dergleichen je gelesen...

UniverC ist reines C - naja, abgesehen davon dass z.B. "char" als "int8", "long" als "int32" getypdef'd sind usw.

---

Der Mehrwert gegenüber Ciss ist, dass es nicht nur unter Windows läuft. M$ mag behaupten was es mag, aber viel mehr als Hello World wird man von MSIL nicht erwarten können - das wär' ja geschäftsschädigend: ein Grund mehr, sich doch einen Mac an zu schaffen...

Gegenüber Java: es ist performanter und offen, d.h. es kann auf jede Plattform portiert werden. Die Eigenportierung von Apple für MacOS 9 war ja bekanntlich nicht so berauschend...

Es macht C-Programmierung erheblich einfacher, z.B. Verwaltung von Konfig-Dateien, Lokalisierung, Stringmanipulation.

Für die meisten Spieleschmieden mag das vorerst egal sein, aber OpenSource-Projekte können davon profitieren. - anders wird es wohl, wenn UniverC auch auf Spielekonsolen portiert wird...

---

Das SWAP-Makro sind bei mir die Funktionen ucmirror<n>s/u();

Das Laden/Erzeugen von Bilderdateien im Speziellen übernimmt aber ohnehin eine Tool-Bibliothek.

Dafür hab' ich so eine Art Pluginkonzept erdacht, d.h. man spezifiziert z.B. mit einem Parameter "JPEG", dass man eine JPEG-Datei erzeugen will... Das gibt's auch für PCM-Sound, Video und Archivdateien...

Es sind ja auch nicht unbedingt die Dinge, um die sich der Anwendungsprogrammierer noch kümmern sollte...

Und wenn der Anwendungsprogrammierer nicht aufpasst, ist das Schlimmste halt, dass eine von ihm erzeugte Datei nur auf der gleichen Plattform benutzt werden kann...

XML bzw. alle Textdateien sind davon aber nicht betroffen. Wenn man also z.B. ein Textdokument als Textdatei speichert, und nicht als kryptische Binärdatei, dann stellt sich einem das Problem erst gar nicht...

[ - Answer - Quote - Direct link - ]
2003-12-04, 22:13 h

Holger
Posts: 8116
User
Zitat:
Original von mrbbc:
Der Mehrwert gegenüber Ciss ist, dass es nicht nur unter Windows läuft. M$ mag behaupten was es mag, aber viel mehr als Hello World wird man von MSIL nicht erwarten können - das wär' ja geschäftsschädigend: ein Grund mehr, sich doch einen Mac an zu schaffen...
Nunja, mehr als ein Hello World erwarte ich von Deinem Projekt ja auch nicht.
Aber Du wirst mir bestimmt auch erklären, warum sich jemand einen teureren Mac anschaffen sollte, nur weil C# auf ihm das selbe kann, wie unter Windows oder Linux.
Zitat:
Gegenüber Java: es ist performanter und offen, d.h. es kann auf jede Plattform portiert werden. Die Eigenportierung von Apple für MacOS 9 war ja bekanntlich nicht so berauschend...
Ich verstehe.
Irgendwer könnte Deine Bibliothek auf ein System portieren und das wird dann von selbst besser sein als Apple's Java-VM für MacOS 9. Habe das jetzt richtig verstanden?
Und natürlich ist Deine Bibliothek performanter als Java und zwar aus dem selben Grund, warum AmigaOS so schlank und effizient ist: Wo keine Features sind, verbraucht man auch keine Zeit und keinen Speicher.
Zitat:
Es macht C-Programmierung erheblich einfacher, z.B. Verwaltung von Konfig-Dateien, Lokalisierung, Stringmanipulation.
Und der Unterschied zu z.B wxWindows ist?
Ich meine, abgesehen von Deiner nervenden selbstüberschätzenden Werbung in diesem Forum.
Zitat:
Und wenn der Anwendungsprogrammierer nicht aufpasst, ist das Schlimmste halt, dass eine von ihm erzeugte Datei nur auf der gleichen Plattform benutzt werden kann...
Na ja, is ja nich so schlimm.
Für eine Bibliothek, die sich anmaßt, genau diese Probleme wie von Geisterhand automatisch zu lösen....
Zitat:
XML bzw. alle Textdateien sind davon aber nicht betroffen. Wenn man also z.B. ein Textdokument als Textdatei speichert, und nicht als kryptische Binärdatei, dann stellt sich einem das Problem erst gar nicht...
Oder anders gesagt, Unicode spielt in Deinen Gedankengängen gar keine Rolle.
Dann wirst Du außerhalb der Amiga-Welt kaum noch jemanden dafür begeistern können. Und innerhalb der Amiga-Welt hat ja Deine nervenden Werbung sowieso für Abschreckung gesorgt.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2003-12-05, 09:04 h

Solar
Posts: 3680
User
Zitat:
Original von mrbbc:
UniverC ist reines C - naja, abgesehen davon dass z.B. "char" als "int8", "long" als "int32" getypdef'd sind usw.

Der Maitre empfiehlt "#include <stdint.h>". Ta-Daaaaa!

Zitat:
Der Mehrwert gegenüber Ciss ist, dass es nicht nur unter Windows läuft.

Google mal nach "Mono", und erschreck' Dich nicht zu sehr.

Zitat:
Gegenüber Java: es ist performanter und offen, d.h. es kann auf jede Plattform portiert werden.

Hier muß ich Holger Recht geben: Performanter wahrscheinlich auch nur aus Mangel an Features.

Und es kann auf "jede" Plattform portiert werden... im Gegensatz zu Java, das schon auf alle relevanten Plattformen portiert worden ist, nicht wahr?

Weiteres Beispiel: Wo liegt der Vorteil gegenüber GTK, mit dem Du schon heute GUI-Anwendungen in C/C++ schreiben kannst, die unter Windows und Linux laufen?

Zitat:
Es macht C-Programmierung erheblich einfacher, z.B. Verwaltung von Konfig-Dateien, Lokalisierung, Stringmanipulation.

So wie tausende anderer, bekannterer, verbreiteter Tools auch.

[ - Answer - Quote - Direct link - ]
2003-12-05, 09:20 h

gni
Posts: 1106
User
Zitat:
Mad_Dog:
Versuch mal auf nem Big Endian Rechner ein BMP File ohne den ganzen SWAP-Quatsch zu laden...
Das war nicht der Punkt. Der Code mag "portabel" sein, aber von Korrektheit ist er meilenweit entfernt...

[ - Answer - Quote - Direct link - ]
2003-12-05, 13:47 h

mrbbc
Posts: 101
User
Zitat:
Original von Solar:
Zitat:
Original von mrbbc:
Der Mehrwert gegenüber Ciss ist, dass es nicht nur unter Windows läuft.

Google mal nach "Mono", und erschreck' Dich nicht zu sehr.

Mono wird niemals mit dem Windows.NET kompatibel sein. Dafür steht Microsoft mit seinem Namen.

Zitat:
Zitat:
Gegenüber Java: es ist performanter und offen, d.h. es kann auf jede Plattform portiert werden.

Hier muß ich Holger Recht geben: Performanter wahrscheinlich auch nur aus Mangel an Features.

Es läuft nativ/nicht interpretiert und übernimmt nicht die Speicherverwaltung auf eigene Faust, was dann in enormen Speicherhunger mündet.

Zitat:
Weiteres Beispiel: Wo liegt der Vorteil gegenüber GTK, mit dem Du schon heute GUI-Anwendungen in C/C++ schreiben kannst, die unter Windows und Linux laufen?

Sie kann alles, nicht bloss Fensteranwendungen. Das heisst: EINE Syntax; nicht so viele, wie man Bibliotheken zusammenlinken muss.

--
it obvisiously seems to have been hard to write

[ - Answer - Quote - Direct link - ]
2003-12-05, 13:54 h

Solar
Posts: 3680
User
Zitat:
Original von mrbbc:
Mono wird niemals mit dem Windows.NET kompatibel sein. Dafür steht Microsoft mit seinem Namen.

Niemals vollständig, da gebe ich Dir recht. Aber auch ein mit UniverC's Hilfe geschriebenes Programm kann - und wird! - nicht über alle Plattformen portierbar sein, weil das in C einfach nicht funktionieren kann. Irgendwo wird die Portabilität immer durchbrochen, UniverC oder C#.

Zitat:
Es läuft nativ/nicht interpretiert und übernimmt nicht die Speicherverwaltung auf eigene Faust, was dann in enormen Speicherhunger mündet.

Zum einen gibt es Java-to-native Compiler.

Zum zweiten ist Java heute in vielen Anwendungen vergleichbaren Hochsprachen (z.B. C++ oder Delphi) kaum noch unterlegen.

Zum dritten ist Garbage Collection für mindestens ebensoviele Anwendungen eine absolut geniale Technik. Selbst für C++ gibt's inzwischen reichlich gc-Implementierungen.

Zitat:
Sie kann alles, nicht bloss Fensteranwendungen. Das heisst: EINE Syntax; nicht so viele, wie man Bibliotheken zusammenlinken muss.

Pfff. Du denkst in einer Welt, in der UniverC akzeptiert und von vielen Entwicklern verwendet wird.

Du scheinst aber keinen Gedanken daran verschwendet zu haben, wie UniverC zu diesem Grad der Akzeptanz gelangen soll.

[ - Answer - Quote - Direct link - ]
2003-12-05, 14:48 h

Mad_Dog
Posts: 1944
User
Zitat:
Original von gni:
Zitat:
Mad_Dog:
Versuch mal auf nem Big Endian Rechner ein BMP File ohne den ganzen SWAP-Quatsch zu laden...
Das war nicht der Punkt. Der Code mag "portabel" sein, aber von Korrektheit ist er meilenweit entfernt...

Wenn das so sein sollte, dann habe sowohl ich, als auch der Compiler was übersehen. Und das Programm läuft.

Auf einem Little-Endian Rechner macht das Programm natürlich völligen Quatsch, weil dann die Werte im Header verdreht sind. Das Programm ist also nur für Big Endian Rechner vorgesehen.

Und von "portabel" war nicht die Rede. Es ging darum, zu zeigen, daß es durchaus Endian-Konflikte geben kann, die man nicht so einfach "wegzaubern" kann.

--

http://www.norman-interactive.com

[ - Answer - Quote - Direct link - ]
2003-12-05, 18:46 h

Holger
Posts: 8116
User
Zitat:
Original von mrbbc:
Zitat:
Zitat:
Gegenüber Java: es ist performanter und offen, d.h. es kann auf jede Plattform portiert werden.
Hier muß ich Holger Recht geben: Performanter wahrscheinlich auch nur aus Mangel an Features.
Es läuft nativ/nicht interpretiert und übernimmt nicht die Speicherverwaltung auf eigene Faust, was dann in enormen Speicherhunger mündet.
Und dieser enorme Speicherhunger Deiner Bibliothek ist für Dich ein Vorteil?
Zitat:
Zitat:
Weiteres Beispiel: Wo liegt der Vorteil gegenüber GTK, mit dem Du schon heute GUI-Anwendungen in C/C++ schreiben kannst, die unter Windows und Linux laufen?
Sie kann alles, nicht bloss Fensteranwendungen. Das heisst: EINE Syntax; nicht so viele, wie man Bibliotheken zusammenlinken muss.
Das ist Dein Hauptproblem. Du glaubst alles besser machen zu können und bist noch nicht einmal in der Lage, ordentlich zu recherchieren, was es schon an bestehenden Lösungen gibt.
Ich habe Dir das Beispiel wxWindows aufgeführt. Habe ich bisher noch nie etwas mit zu tun gehabt, aber einfaches googlen und auf der hp fünf Minuten lesen reicht ja schon, um den Funktionsumfang zu kennenzulernen. Im Gegensatz zu Dir behaupten die Autoren nicht, "Sie kann alles". Sie umfaßt eben nur folgende Kategorien:
  • Managed windows
  • Miscellaneous windows
  • Common dialogs
  • Controls
  • Menus
  • Window layout
  • Device contexts
  • Graphics device interface
  • Events
  • Validators
  • Data structures
  • Run-time class information system
  • Logging features
  • Debugging features
  • Networking classes
  • Interprocess communication
  • Document/view framework
  • Printing framework
  • Drag and drop and clipboard classes
  • File related classes
  • Stream classes
  • Threading classes
  • HTML classes
  • Virtual file system classes
  • XML-based resource system classes
  • Online help
  • Database classes
  • Miscellaneous

    Es gibt garantiert noch mehr Lösungen, die einen solchen Umfang, vielleicht noch mehr, bieten. Aber wenn einem fünf Minuten Recherche schon zu viel sind, dann muß man natürlich von vornherein alles schlecht reden und eine Bibliothek, die alles kann ankündigen.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Answer - Quote - Direct link - ]

    		•
    2003-12-05, 19:52 h

    Mad_Dog
    Posts: 1944
    User
    Zitat:
    Original von Holger:

    Es gibt garantiert noch mehr Lösungen, die einen solchen Umfang, vielleicht noch mehr, bieten. Aber wenn einem fünf Minuten Recherche schon zu viel sind, dann muß man natürlich von vornherein alles schlecht reden und eine Bibliothek, die alles kann ankündigen.

    Wie mir scheint, bringt mrbcc folgendes durcheinander:
    Eine Bibliothek, die dazu gedacht ist von der Hardware und dem Betriebssystem zu abstahieren, ermöglicht noch lange nicht einen x-beliebigen C/C++ Code durch pures Neucompileren auf ein anderes Zielsystem zu portieren. Das würde voraussetzen, daß der entsprechende Code bereits in der speziellen API dieser Bibliothek vorliegt. Beispiel: Hat man ein C-Programm, das Grafik mittels OpenGL ausgibt, die Fenster mittels GLUT öffnet, und IO ebenfalls mittels GLUT macht, kann man das durchaus ohne Änderung im Code durch Neucompilierung auf ein anderes System übertragen.

    Aber sobald irgend etwas OS-Natives oder Low-Level Code dabei ist versagt das Konzept.
    --

    http://www.norman-interactive.com

    [ - Answer - Quote - Direct link - ]
    2003-12-05, 20:05 h

    mrbbc
    Posts: 101
    User
    Zitat:
    Original von Holger:
    Das ist Dein Hauptproblem. Du glaubst alles besser machen zu können und bist noch nicht einmal in der Lage, ordentlich zu recherchieren, was es schon an bestehenden Lösungen gibt.

    Das ist auch nicht wirklich einfach. Aber wxWindows ist mir bekannt, wie TCL/TK, GTK, QT, Allegro und SDL, naja, und ISO C, POSIX und X11, ausserdem natürlich GEM wenn man so will.

    Alle haben den gleichen Nachteil: sie decken nicht die gesamte Programmierung ab. Das eine ist für graphische Programme/Spiele, das andere für Fensteranwendungen.

    Will/muss man das kombinieren, geht man einen schwierigen Weg: niemand kann garantieren, dass zwei verschiedene Bibliotheken wirklich zusammenpassen.

    Zitat:
    Im Gegensatz zu Dir behaupten die Autoren nicht, "Sie kann alles".

    Weil sie dem Projekt diese Grenzen gesetzt haben. Ich strebe hingegen die absolute Perfektion an. Daher sollen nicht nur alle Funktionen alles abdecken, sondern auch mnemotechnisch so ausgeklügelt sein, dass es für Programmieranfänger geeignet ist und man sein Programm über möglichst weite Strecken aus dem Kopf tippen kann.

    Ich kenne durchaus meine Grenzen; mein herausragendstes Talent ist wohl, meine Grenzen zu kennen. Ich habe mir ein viel zu breites Wissenspektrum angeeignet, um in irgendeiner Kategorie Spitzenleistungen erbringen zu können.

    Daher suche ich eben Leute mit Erfahrung; welche, die sich in eine Plattform hineingekniet haben. Ich bring' es ehrlich gesagt in meinem ganzen Leben auf keine 12 Stunden mit der Workbench.

    Noch besser sind natürlich Leute, die schon größere Programme von einer Plattform auf eine andere portiert haben.

    Und wie gesagt, hab' ich mich nicht spezialisiert. Es gibt einige Algorithmen, die ich unmöglich selber schreiben kann.

    Ausserdem sehen vier Augen immer mehr als zwei.

    [ - Answer - Quote - Direct link - ]
    2003-12-05, 23:01 h

    Mazze
    Posts: 263
    User     		Hi mrbbc,

    mit Deinen Sprüchen erreichst Du nur, dass Dich niemand ernst nimmt. Ich empfehle Dir, dass Du mal Deinen Sourceforge-Auftritt überarbeitest: Kein CVS-Eintrag und im Download-Bereich eine leere Datei, die man sich praktischerweise von 10 Servern herunterladen kann. Jemand, der bei der Suche nach nach einer plattformunabhängigen Bibliothek auf Deinen Sourceforge-Eintrag stößt, wendet sich da schnell mit Schaudern ab.

    MFG Matthias :shoot3:

    [ Dieser Beitrag wurde von Mazze am 05.12.2003 editiert. ]

    [ - Answer - Quote - Direct link - ]
    2003-12-06, 12:15 h

    mrbbc
    Posts: 101
    User
    Zitat:
    Original von Mad_Dog:
    Wie mir scheint, bringt mrbcc folgendes durcheinander

    Ich bring gar nichts durcheinander.

    Zitat:
    Eine Bibliothek, die dazu gedacht ist von der Hardware und dem Betriebssystem zu abstahieren, ermöglicht noch lange nicht einen x-beliebigen C/C++ Code durch pures Neucompileren auf ein anderes Zielsystem zu portieren. Das würde voraussetzen, daß der entsprechende Code bereits in der speziellen API dieser Bibliothek vorliegt.

    Es setzt voraus, dass die Bibliothek auf der Zielplattform implementiert ist.

    Zitat:
    Aber sobald irgend etwas OS-Natives oder Low-Level Code dabei ist versagt das Konzept.

    Das soll eben nicht mehr nötig sein. Und das ist auch der Haken vieler plattformübergreifender Bibliotheken: du kannst z.B. keine Ordner anlegen oder nach Dateien suchen - weil es dafür keine Funktionen gibt.

    Wenn du etwas plattformspezifisch optimieren willst, dann machst du das in der Bibliothek und nicht im Programm. Damit optimierst du dann auch gleichzeitig alle anderen UniverC-Programme...

    Inline-Assembler verbietet sich natürlich.

    [ - Answer - Quote - Direct link - ]
    2003-12-06, 12:33 h

    mrbbc
    Posts: 101
    User
    Zitat:
    Original von Mazze:
    Ich empfehle Dir, dass Du mal Deinen Sourceforge-Auftritt überarbeitest: Kein CVS-Eintrag und im Download-Bereich eine leere Datei, die man sich praktischerweise von 10 Servern herunterladen kann.

    Ich muss den Arbeitsaufwand so gering wie möglich halten. Vielleicht finde ich mal die Zeit, die Downloads auf sf.net rüber zu schieben...

    Derzeit verweise ich aber sowieso praktisch nur auf http://www.univerc.org und nicht dem SF-Eintrag, der im Übrigen nur den Sinn hat, Entwickler an zu werben, und nicht eine Alpha-Alphaversion zu beziehen.

    Ich hab im Laufe der Jahre übrigens hunderte Downloads der Bibliothek verzeichnet, aber fast gar kein Feedback.

    [ - Answer - Quote - Direct link - ]
    2003-12-08, 20:54 h

    Holger
    Posts: 8116
    User
    Zitat:
    Original von mrbbc:
    Das ist auch nicht wirklich einfach. Aber wxWindows ist mir bekannt, wie TCL/TK, GTK, QT, Allegro und SDL, naja, und ISO C, POSIX und X11, ausserdem natürlich GEM wenn man so will.

    Alle haben den gleichen Nachteil: sie decken nicht die gesamte Programmierung ab. Das eine ist für graphische Programme/Spiele, das andere für Fensteranwendungen.
    Ach ja.
    Ich ahnte es schon. Da habe ich Dir die Arbeit, mal auf der Webseite nachzulesen, schon erspart und das Wesentliche hier gepostet, aber selbst das mal zu Lesen, ist für Dich zu viel Arbeit. Anders kann man Deine Antwort ja nicht interpretieren. Egal, ob Du es jetzt in den Bereich "graphische Programme/Spiele" oder in den Bereich "Fensteranwendungen" reininterpretiert hast, kannst Du lesen?
    Zitat:
    Noch mal:
    Sie umfaßt eben nur folgende Kategorien:
  • Managed windows
    ...
  • Run-time class information system
  • Logging features
  • Debugging features
  • Networking classes
  • Interprocess communication
  • Document/view framework
  • Printing framework
  • Drag and drop and clipboard classes
  • File related classes
  • Stream classes
  • Threading classes
  • HTML classes
  • Virtual file system classes
  • XML-based resource system classes
  • Online help
  • Database classes
  • Miscellaneous
    • Es übersteigt schon Deine Möglichkeiten nur diese Punkte vollständig zu implementieren, aber Du hast gleiche den Anspruch, "die gesamte Programmierung" abzudecken.
    Kleiner Tip: das ist prinzipiell unmöglich, da es sich bei der "gesamten Programmierung" um eine dynamische Menge handelt.
    Zitat:
    Weil sie dem Projekt diese Grenzen gesetzt haben. Ich strebe hingegen die absolute Perfektion an.
    Viel Erfolg auf diesem Weg.
    Zitat:
    Ich kenne durchaus meine Grenzen; mein herausragendstes Talent ist wohl, meine Grenzen zu kennen.
    Das ist es offensichtlich nicht. Es scheint eher Dein größter Schwachpunkt zu sein.
    Zitat:
    Ich habe mir ein viel zu breites Wissenspektrum angeeignet, um in irgendeiner Kategorie Spitzenleistungen erbringen zu können.
    Dann solltest es Du eher mal bei "Wer wird Millionär" versuchen.
    Zitat:
    Daher suche ich eben Leute mit Erfahrung; welche, die sich in eine Plattform hineingekniet haben. Ich bring' es ehrlich gesagt in meinem ganzen Leben auf keine 12 Stunden mit der Workbench.

    Noch besser sind natürlich Leute, die schon größere Programme von einer Plattform auf eine andere portiert haben.
    Von AmigaInc lernen, heißt siegen lernen?
    Nach dem Motto: suche Dumme, die die Arbeit machen?
    Es wird nicht funktionieren.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ Dieser Beitrag wurde von Holger am 08.12.2003 editiert. ]

    [ - Answer - Quote - Direct link - ]
    2003-12-08, 23:35 h

    Mad_Dog
    Posts: 1944
    User     		@Holger & Co:

    Ich finde es trotzdem nett, daß es neben uns alten, gebeutelten, x-mal verarschten und frustrierten Amiga-Hasen noch ein paar überschäumende Enthusiasten gibt ;)

    Soll er mal machen, dann können wir darüber urteilen.

    @mrbcc:

    Das Du kein x-beliebiges Programm, welches in C/C++ geschrieben ist und eine beliebige Api (z.B. Intuition) verwendet, durch Neucompilierung unter Verwendung Deiner Bibliothek portieren kannst, ohne den Code zu ändern, hast Du anscheinend immer noch nicht begriffen (oder wir reden an einander vorbei).
    Für sowas müsstest Du schon den ultimativen super-parser zum umwursteln des Codes bzw. sowas wie Wine entwickeln...

    Aber: mach mal. :)
    Wenn Du ein Ergebnis hast, können wir uns weiter darüber unterhalten.
    --

    http://www.norman-interactive.com

    [ - Answer - Quote - Direct link - ]
    2003-12-09, 20:22 h

    mrbbc
    Posts: 101
    User
    Zitat:
    Das Du kein x-beliebiges Programm, welches in C/C++ geschrieben ist und eine beliebige Api (z.B. Intuition) verwendet, durch Neucompilierung unter Verwendung Deiner Bibliothek portieren kannst, ohne den Code zu ändern, hast Du anscheinend immer noch nicht begriffen (oder wir reden an einander vorbei).

    Letzteres, UniverC ist eine plattformübergreifende Bibliothek; sie kommt dabei ohne nervige Präprozessordirektiven aus a la "#ifdef _PLATF_WINDOWS" - man schreibt sein Programm und fertig.

    Vorhandene Quelltexte schreibt es natürlich nicht um; es würde aber auch mehr Sinn machen von einem vorhandenen Quelltext auf eine plattformübergreifende API zu portieren, weil damit das Programm gleichzeitig für mehrere Plattformen verfügbar wird.

    @Mad_Holger:

    Wo sind die 3D-Grafiken, Sound, USB-Kommunikation ?

    Ich weiss, dass wxWindows sehr viel kann, ein paar seiner Grenzen kenn' ich aber auch.

    [ - Answer - Quote - Direct link - ]
    2003-12-10, 14:01 h

    Holger
    Posts: 8116
    User
    Zitat:
    Original von mrbbc:
    Wo sind die 3D-Grafiken, Sound, USB-Kommunikation ?

    Ich weiss, dass wxWindows sehr viel kann, ein paar seiner Grenzen kenn' ich aber auch.
    Und die CD/DVD-Brenner-Schnittstelle, Scsi-direkt-Interface, Partitionstabellenverwaltung, Multiprozessingkonfiguration, der builtin-Compiler, Industrieroboteransteuerung, automatische Sprach-Übersetzung des User-Interface, ISDN-API, Monitor-Farbkalibrierung, E-Mail API, Smartcards, p2p networks, Kryptographie, TV&Videocapturing und und und.

    Du willst es offenbar nicht begreifen. Es wird nie ein API für alles geben und das erste, was beim Beginn eines Projektes gemacht werden muß, ist das Abstecken der Grenzen. Du solltest Dich nicht mit den Grenzen der anderen, sondern mal mit Deinen eigenen Grenzen beschäftigen.

    mfg
    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ - Answer - Quote - Direct link - ]

    -1- [ - Post reply - ]


    amiga-news.de Forum > Programmierung > UniverC [ - Search - New posts - Register - Login - ]


    .
    Masthead | Privacy policy | Netiquette | Advertising | Contact
    Copyright © 1998-2024 by amiga-news.de - all rights reserved.
    .