Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » dynamisches Array-problem
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ]
020
12.11.2003, 22:29 Uhr
ao

(Operator)



Zitat:
RHBaum postete
....
Das Construct heisst dann SAFEARRAY, und kann per Windows API ueber C Schnittstellen gehandelt werden .
Nur ist das halt mega umstaendlich, auch wenn das safearray doch paar glitzekliene Vorteile besitzt, die aber niemand braucht. Am ende steckst viel arbeit rein, eigentlich nur um dein code langsam zu machen
....

Jein. Du zählst die Nachteile von SAFEARRAYs auf, ohne die Vorteile zu nennen. Ich tu das mal für dich.

1. Für C++ gibts viele Array-APIs, meist Template-Klassen, aber in C sind sie selten. Hier gibts mal ne Möglichkeit für C-Programmierer, ohne Zeigerarithmetik Arrays zu behandeln, und zwar mit beliebigem Elementtyp, beliebiger Dimensionszahl und beliebigen Indexgrenzen (nein, die Indizierung muss nicht mehr bei 0 beginnen). Die Arrays können zur Laufzeit angelegt, vergrößert, verkleinert und zerstört werden. Es gibt ein Range-Checking; Überschreiten einer Indexgrenze richtet keinen Schaden mehr an, sondern kann am Rückgabewert der API-Funktion erkannt werden.

Dass das alles nicht zum Nulltarif zu haben ist und mit Performance-Einbußen bezahlt werden muss, liegt wohl auf der Hand. Für zeitkritische Teile kann man sich auch einen Pointer auf den Datenbereich des Safearrays geben lassen und die Zugriffe mit Zeigerarithmetik programmieren. Das geht dann so schnell wie auf jedem anderen C-Array, man ist aber auch genauso nackt.

Die API-Funktionen sind sperrig und unhandlich, da gebe ich dir recht. Aber was hindert dich daran, einen Satz von handlichen Wrappern drumrum zu packen, die nicht so allzwecktauglich sind, aber sich besser bedienen lassen?

2. (und das ist viel wichtiger): Safearrays sind wichtig für die COM-Programmierung. COM ist eine Technologie, über die Programme miteinander kommunizieren können, unabhängig von der Sprache, in der sie geschrieben sind. Man kann also nicht nur C++-, Java-, Delphi- und Basic-Programme, sondern auch HTML-Seiten mit Javascript oder ActiveX-Controls usw. über standardisierte COM-Schnittstellen miteinander reden lassen. Das ist ein großer Vorteil.

Du kannst in C++ hochperformante Server schreiben, die irgendwelche Berechnungen anstellen, und die Ergebnisse mit Javascript über eine COM-Schnittstelle abholen und im Webbrowser darstellen.

Oder einen MP3-Decoder und Wave-Player in C++ kodieren (freie Sourcen dazu gibts massig im Internet) und mit Visual Basic in 10 Minuten eine Bedienoberfläche drüberstülpen - fertig ist der eigene MP3-Player.

Was hat das mit Safearrays zu tun? Nun, immer wenn Arrays durch COM-Schnittstellen transportiert werden, handelt es sich in Wahrheit um Safearrays. Nur - C (und C++) sind die einzigen Sprachen, in denen man das wirklich merkt, die anderen haben die Safearrays quasi nahtlos integriert.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
021
13.11.2003, 00:12 Uhr
0xdeadbeef
Gott
(Operator)


Naja, wobei du an der Stelle auch sehen musst, dass es eine ganze Menge Disziplin braucht, die Vorteile von safe arrays in C zu nutzen. Bei jedem Zugriff musst du wieder eine Funktion benutzen, oder wahlweise statt Zeigerarithmetik eine imho noch unübersichtlichere (gerade bei mehrdimensionalen Arrays) Indexarithmetik benutzen. In der MS-Implementierung findet, wenn mich grad nicht alles täuscht, auch kein Range-Checking statt (im C++-vector übrigens auch nicht, aus Gründen der Performance). Das vergrößern, verkleinern und zerstören kriegt man mit malloc, realloc und free hin. Was das Microsoft-API angeht, so erschließt sich mir der Sinn einer Prozedur, die ein Safearray, einen int für die Dimension und einen Pointer auf einen int für den Rückgabewert entgegennimmt, aber selbst void ist, nicht.

Was COM angeht, so ist das eine zweischneidige Sache. Von der Grundidee her ist COM so ne Art dreckig umgesetztes Schmalspur-CORBA, also für IPC gedacht. COM aus Javascript und HTML anzusprechen, ist daher zumindest nicht sinnvoll, dass es möglich ist, wäre mir neu, bei PHP und ASP sehe ich es noch ein, weil da die Berechnung serverseitig stattfindet. Sonderlich performant ist COM allerdings prinzipbedingt nicht. Die großen Vorteile von CORBA - Typsicherheit und Übersichtlichkeit - sind bei COM allerdings auch nicht geboten, deswegen stehe ich dieser Technologie eher skeptisch gegenüber. Was Safearrays und CORBA angeht, Safearrays sind lediglich in Visual Basic nahtlos integriert, in allen anderen Sprachen werden Arrays anders gehandhabt.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
022
13.11.2003, 08:58 Uhr
ao

(Operator)


@deadbeef:

Man braucht immer Disziplin, um von C irgendwelche Vorteile zu haben ;-)

Ich habe bereits oben geschrieben, dass das Safearray-API unhandlich ist, eben weil es so universell ist (N Dimensionen, beliebige Indexgrenzen). Man kann sich aber mit wenig Aufwand ein API drumherum bauen, das genau die eigenen Anforderungen erfüllt.

Von welcher void-Prozedur sprichst du?

CORBA kenne ich nicht, ob COM mit Javascript sinnvoll ist oder nicht, überlasse ich den Anwendern, und über die Performance kann ich mich bisher nicht beklagen.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
023
13.11.2003, 09:11 Uhr
HRI-Dummy



 Also die Sache mit den Safearrays klingt gut, aber wenn ich Euch richtig verstehe geht das nur unter Windows.
Leider bin ich durch die Firma und deren Coding Conventions in meinen Moeglichkeiten sehr beschraenkt.
Zum einen muss ich unter Linux programmieren, ausserdem darf ich wie gesagt nur C nutzen.
Was die Speicherverwaltung angeht, das ist eine ganz bloede Sache. Wir haben hier eine eigene library dafuer, und deshalb duerfen wir malloc und co nicht benutzen. Was noch schlimmer ist, wir haben eine vorgeschriebene Projektstruktur, und Speicherverwaltung darf nur in zwei Prozeduren am Anfang des Programms und zwei am Ende des Programms betrieben werden. Wenn man wie ich mitten im Programm Speicher neu zuweisen will, hat man ein Problem...
Durch die Programme die die Firma entwickelt ist das allerdings auch sinnvoll, weil alles was hier programmiert wird, spaeter in ein 'intelligentes' Betriebssystem integriert wird und da muessen alles Teile auf eine bestimmte Art und Weise zusammenarbeiten. Das ist der Nachteil an der sonst so interessanten Forschung.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
024
13.11.2003, 10:17 Uhr
ao

(Operator)



Zitat:
HRI-Dummy postete
Was noch schlimmer ist, wir haben eine vorgeschriebene Projektstruktur, und Speicherverwaltung darf nur in zwei Prozeduren am Anfang des Programms und zwei am Ende des Programms betrieben werden. Wenn man wie ich mitten im Programm Speicher neu zuweisen will, hat man ein Problem...

In der Tat, das hat man, denn alle Vorschläge, die hier gemacht wurden, beruhen darauf, dass man sich zur Laufzeit bei Bedarf neuen Speicher holen kann.

Wenn du nur zur Startzeit sagen darfst, wieviel Speicher du jemals brauchen wirst, gibts drei Möglichkeiten:

a) Deck dich mehr als überreichlich mit Speicher ein und erklär dem Projektleiter, dass du fürs Erste so 4 bis 6 Gigabytes brauchst. Dazu fällt mir das Zitat ein: "640 K should be enough for anybody". War das von Bill Gates?

b) Bau das Programm so, dass die Speichermenge vorhersagbar bleibt und erklär dem Projektleiter, dass er damit leben muss, wenn die Datenbank-Records nur einzeln und nicht alle auf einmal abgeholt werden.

c) Erklär dem Projektleiter, dass die Anforderungen mit der gegebenen Projektstruktur nicht erfüllt werden können und dass die Projektstruktur angepasst werden muss.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
025
13.11.2003, 11:17 Uhr
virtual
Sexiest Bit alive
(Operator)


Wenn ich es richtig verstanden habe, geht es um Resultsets von Datenbank Queries. Möglicherweise solltest Du einfach einen Cursor verwenden und nicht gleich das ganze Resultset in den Speicher laden.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
026
13.11.2003, 14:11 Uhr
RHBaum



 zum safearray
Es ist per C schwer zu haendeln, zu aufgeblaeht, etc. Und viel schlimmer, es bringt dir da allein keine Vorteile. Fehler von der API, Bereichsueberschreitung etc, musst eh selber abfangen .
Nen Wrapper um das SafeArray schreiben wird sich unter C recht schwer gestalten :p Naja, muesstest eigentlich nur alle Windows SafaArray API funktionen umbenennen, viel mehr kannst eigentlich gar ned machen.

In C++ sieht die sache soweiso ganz anders aus, da kannst dir wirklich einmal wrapper fuer schreiben, und gut ist. ausserdem gibts da fertige.

Und ja, der hauptexistenzgrund fuern safearray ist der datenaustausch unter COM Modulen ... und windowsspezifische Sprachunabhaengigkeit. (also Arrays in c++ befuellen, und mit VB weiterverarbeiten ... )


Zitat:

Von der Grundidee her ist COM so ne Art dreckig umgesetztes Schmalspur-CORBA, also für IPC gedacht.

Auch ne sichtweise ... naja gleiche Anforderungen fuehren manchmal zu gleichen loesungen ... wobei die anfaenge von COM / DCOM schon in 16 bit windows (also 3.11) zu suchen sind ... gabs da corba schon ?

Dreckig umgestezt ist relativ ... laeuft halt auch nur in ner dreckigen Umgebung Von daher hat M$ genau das gemacht, was sie am besten koennen.


Zitat:

Die großen Vorteile von CORBA - Typsicherheit und Übersichtlichkeit - sind bei COM allerdings auch nicht geboten, deswegen stehe ich dieser Technologie eher skeptisch gegenüber.

Naja, alles hat seinen Preis, Corba auch ...
M$ hat etwas geschafft, was andere nicht geschafft haben. Es hat seine universal IPC technologie als Hauptbestandteil ins BS integriert, und es laeuft, mehr oder weniger zufreidenstellend.
Corba in Linux hat es nicht geschafft. Siehe KDE und Corba. sie haben fuer KDE extra eine aehnliche Technologie wie corba / Com entwickeln muessen, weil corba zu langsam war ...

Wo ich auch einen Wesentlichen Vorteil von COM/DCOM sehe. Benutzerdefiniertes Marshalling. Wenn ich komponenten Inprocess einbinde, tauschen sich die Methoden eben nicht uber Marshaller /streams aus, sondern benutzen zeiger auf gemeinsam zugaenglichen Speicherbereiche.
Kann das Corba auch ?
Und es ist nen QuasiStandard ... Lieber Schmutz auf den ich mich verlassen kann, als qualitativ hochwertige Loesungen ... wo ich erst sicherstellen muss, das die auch gibt ....
Gibts ne freie, nutzbare corba Impl unter windows ?
Unter Unix gibt es Mico ...

Ciao ...
Dieser Post wurde am 13.11.2003 um 14:16 Uhr von RHBaum editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
027
13.11.2003, 15:44 Uhr
ao

(Operator)



Zitat:
RHBaum postete
Nen Wrapper um das SafeArray schreiben wird sich unter C recht schwer gestalten :p Naja, muesstest eigentlich nur alle Windows SafaArray API funktionen umbenennen, viel mehr kannst eigentlich gar ned machen.


Na und ob!

C++:
/* 2d-Safearray erzeugen */
SAFEARRAY * SA2D_Create (VARTYPE vt, long nFirstIndexX, long nNbrOfElementsX, long nFirstIndexY, long nNbrOfElementsY)
{
    SAFEARRAYBOUND sab[2];
    sab[0].cElements = nNbrOfElementsX;
    sab[0].nLbound = nFirstIndexX;
    sab[1].cElements = nNbrOfElementsY;
    sab[1].nLbound = nFirstIndexY;
    return SafeArrayCreate (vt, 2, &sab);
}

Das Herumhantieren mit den SAFEARRAYBOUND-Strukturen kannst du kapseln.

Bei PutElement und GetElement kannst du den Zusammenbau der Indexvektoren kapseln. Du kannst Spezialisierungen für häufig benutzte Elementtypen schreiben, das erspart dir auch die Verwendung der void-Pointer.

In C++ ist das freilich feiner, da kann man den Elementtyp als Template-Parameter einführen, da kann man Element-Operatoren überladen ...

Aber auch in C muss man nicht bis zu den Hüften im Dreck waten.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
028
13.11.2003, 17:35 Uhr
0xdeadbeef
Gott
(Operator)


Der ursprüngliche Entwurf für CORBA wurde 1991 von der OMG rausgegeben. ORBs gibt es inzwischen für so ziemlich jede Plattform, und sie werden auch benutzt. Gnome und Fresco benutzen zum Beispiel CORBA. Dass COM in Windows 3.1 existiert haben soll, halte ich für ein Gerücht; DOS war ja noch nicht mal zu präemptivem Multitasking fähig. Von der Performance her nehmen sich COM und CORBA nicht viel, für genaue Benchmarks müsstest du aber google befragen.

Der große Vorteil von CORBA gegenüber COM ist aber, dass ein CORBA-Standard existiert. Das bedeutet, dass CORBA auch in heterogenen Netzwerken (wie es die meisten heutzutage sind) läuft. Es ist dem Client egal, auf welchem Betriebssystem der Server läuft und in welcher Sprache er geschrieben ist. Umgekehrt gilt dasselbe. Oh, und CORBA wird auch benutzt. Gnome benutzt CORBA, Fresco auch, und ne ganze Reihe anderer Projekte. Seit der Erfindung von COM ist das Wissen um CORBA in der Windows-Welt ein bisschen zurückgegangen, aber dass Microsoft seine Marktmacht nutzt, um die eigenen - nicht immer leistungsfähigeren - Produkte durchzudrücken ist ja nichts neues.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
029
14.11.2003, 08:23 Uhr
ao

(Operator)



Zitat:
0xdeadbeef postete
Dass COM in Windows 3.1 existiert haben soll, halte ich für ein Gerücht; DOS war ja noch nicht mal zu präemptivem Multitasking fähig.

Willst du andeuten, dass Preemption eine Voraussetzung für COM ist? Den Zusammenhang sehe ich nicht.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] [ 2 ] > 3 < [ 4 ]     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: