HDTenEightyP/NetNews huggingface dataset:
From: flebbe@wega.tat.physik.uni-tuebingen.de (Olaf Flebbe)
Subject: Re: Ausf"uhrungszeit bei der Pointerarithmetik?
Organization: TAT (Theoretical Astrophysics Tuebingen), U. of Tuebingen, FRG
Date: Sun, 23 Aug 1992 09:36:27 GMT

urlichs@smurf.sub.org (Matthias Urlichs) writes:

>In de.comp.lang.c, article <173296INNja0@fbi-news.Informatik.Uni-Dortmund.DE>,
>  maennig@siggi.informatik.uni-dortmund.de writes:
>> 
>> [ Optimierungsproblem bei verketteten Zeigern ]
>> 
>Im Zweifelsfall ist die Methode, sich den Zeiger extra irgendwo zu merken,
>vorzugsweise in einem "register"-Pointer (fuer die Compiler, die sowas nicht
>selber raffen), schneller. 

>Bessere Idee: Greif dir jemanden, der den Maschinencode auseinanderpfluecken
>kann, und frage den bzw. die Compiler, was sie fuer Code generieren.

>Noch bessere Idee: Schalte den Optimierer an, schreib den Code so, dass du
>ihn selber am besten lesen kannst, und vergiss das Problem. Solange du nicht
>direkt auf der Hardware reitest und mit jedem Zyklus geizen musst (und dann
>empfehle ich andere Datenstrukturen), ist der Performanceunterschied im
>Zweifelsfall eh minimal.

.Oberlehrer ON

Ich schlie"se mich dem Vorredner uneingesch"ankt an, und erg"anze
noch: Am wichtigsten ist doch die Richtigkeit des Codes.
Performancefragen sind beim *schreiben* eines Programms eher
untergeordnet, wenn man mal von der Wahl der Datenstrukturen absieht,
was hier ja nicht der Fall ist.

Wenn man dann schlie"slich entsetzt bemerkt, da"s das Programm
unakzeptable Laufzeiten, aber wahrscheinlich korrekte Resultate
produziert, dann kann man mal ein Profiling machen und kritische
Funktionen lokalisieren (meist bleibt die Leistung dort, wo man es
nicht vermutet). Dann sollte man sich Gedanken "uber den *Algorithmus*
machen, und erst wenn man dort nicht mehr weiter wei"s, f"angt man mit
"Uberlegungen, ob Pointerarithmetik ja oder nein und so weiter an.
Damit hat man den Vorteil, da"s man stets "uberpr"ufen kann, ob das
Programm noch richtig arbeitet.

.Oberlehrer OFF



--
  Olaf Flebbe,  Theoretische Astrophysik Tuebingen
  Internet:     flebbe@tat.physik.uni-tuebingen.de
From: maennig@hugo.informatik.uni-dortmund.de (Olaf Maennig)
Newsgroups: de.comp.lang.c
Subject: Ausf"uhrungszeit bei der Pointerarithmetik?
Date: 21 Aug 1992 15:31:50 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
Reply-To: maennig@siggi.informatik.uni-dortmund.de
NNTP-Posting-Host: hugo

Hallo, allerseits!

Selbst auf die Gefahr hin wieder unangenehm aufzufallen, habe ich eine neue
Frage:

In einem Prg, das ich gerade schreibe, habe ich tief verschachtelte
Strukturen gegeben (im Bsp. der Einfachheit halber nur 2fach verschachtelt).
Ist es bei der Programmausf"uhrung nun schneller, wenn ich die tief
verschachtelten Variablen direkt anspreche (main1), oder wenn ich zuvor eine
lokale Variable erstelle, weil dann nicht jedesmal von Struktur zu Struktur
'gehangelt' werden muss (main2)?

"Ubersichtlicher ist auf jeden Fall main2, aber ich m"ochte in diesem Fall
eher eine schnelle als "ubersichtliche Funktion.

Intuitiv w"urde ich sagen, dass main2 auch schneller ist, andererseits
k"onnte es doch auch sein, dass der Compiler beim "Ubersetzen die lange
Verweiskette gleich durch eine Adresse ersetzt, und dann verliere ich ja
Zeit bei der Zuweisung der lokalen Variablen.

Also: wer weiss Bescheid (nerv', nerv' :-))?


typedef struct {	typedef struct {	typedef struct {
  int i;		  S1 *p;		  S2 *q;
} S1;			} S2;			} S3;

main1()
{
    S3  *s, *t;
    int  var1, var2;

    s = makestruct(); /* reserviert Speicher, so dass s->q->p->i == 0 */
    t = makestruct();

    /***  es soll nun ausgiebig mit i in S1 gearbeitet werden  ***/

    var1 = s->q->p->i;
    var2 = s->q->p->i;
    ...
    s->q->p->i = t->q->p->i + 1;
    ...
}


main2()
{
    S3  *s, *t;
    S1  *u;
    int var1, var2;

    s = makestruct();
    t = makestruct();

    /***  es soll nun ausgiebig mit i in S1 gearbeitet werden  ***/

    u = s->q->p;

    var1 = u->i;
    var2 = u->i;
    ...
    u->i = t->p->q->i + 1;
    ...
}

"Ubrigens verwende ich den gcc (die Frage soll aber auch f"ur QuickC und
Turbo C gelten). Falls die Antwort in den jeweiligen Dokumentationen steht,
so m"oge man mir das verzeihen: ich habe die Sachen gerade nicht zur Hand.
Und damit erst gar keine falschen Vorstellungen aufkommen: ich selbst habe
keinen AT (und damit auch keine Raubkopien von QuickC/Turbo C), sondern
programmiere ihn in einem Institut (daher die momentane Unverf"ugbarkeit der
Handb"ucher).

Thanks for help.

 ---------------------------------------------------------------------------
     _                   Department of Computer Science IV
    / \     |\/|         University of Dortmund, Germany
    \_/laf  |  |aennig   e-mail: maennig@siggi.informatik.uni-dortmund.de
 ---------------------------------------------------------------------------
From: pmh@wasy.sub.org (Patrick M. Hausen)
Newsgroups: de.comp.lang.c
Distribution: world
Organization: Wacker Systemelektronik GmbH, Honsellstr. 1a, 7500 Karlsruhe 21
Subject: Re: Verhalten von struct-Pointers
Reply-To: pmh@wasy.sub.org
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992
Date: Mon, 17 Aug 1992 13:50:52 CEST

In <16blbiINNjd7@fbi-news.Informatik.Uni-Dortmund.DE>, Olaf Maennig writes:

>     structure = (TEST*) calloc(1, sizeof(TEST*));
                                               ^
Das ist ein '*' zuviel. Du moechtest doch wohl einen Speicherbereich
haben, der eine struct test aufnehmen kann und structure darauf zeigen 
lassen. So wie oben allozierst Du Platz fuer einen Zeiger auf ein
struct test.

>     change1(structure);
>     change2(structure);
>     freestruct(&structure);

Ansonsten stimmt doch alles.

> structure-Werte k"onnen durch Angabe eines Pointers auf structure ge"andert
> werden, warum aber wird structure auf NULL gesetzt, wenn freestruct() so
> aussieht:
> 
> void freestruct(TEST *s)
> {
>     free(s);
>     s = 0x0;
> }
>
> und der Aufruf freestruct(structure) lautet?
> Wird der Speicherplatz f"ur structure im zweiten Fall "uberhaupt freigegeben?
                         ^^^^^^^^^^^^^^

Siehe Dein Fehlerchen oben: der Speicherplatz fuer structure wir erst bei
Verlassen von main() freigegeben, denn er wird belegt allein durch die
Definition TEST *structure.
Was, wenn ueberhaupt, freigegeben wird, ist der Speicherplatz fuer
das Objekt (ein TEST), auf das structure zeigt.

Was (theoretisch) passiert ist folgendes: 

- es wird eine lokale Kopie von structure angelegt, eben s. Dieser Pointer
  zeigt auf denselben Speicherbereich wie structure.  
- Der Aufruf von free() gibt diesen Speicherbereich frei.
- der Kopie s wird der Wert 0 zugewiesen
- die Kopie wird wieder zerstoert

structure sollte also noch den gleichen Wert haben wie vor dem Aufruf.

Was nun Dein Compiler daraus wurstelt .... hm .... keine Ahnung.


Grusz, Paddy
-- 
Patrick M. Hausen * Support Unix und Netzwerke * Wacker Systemelektronik GmbH
 Honsellstr. 1a * D-W7500 Karlsruhe 21 * Phone: +49-721-955600 * Fax: 9556050
   Email (office): pmh@wasy.sub.org * Email (private): pmh@cutie.ka.sub.org
From: wd@pcsbst.pcs.com (wd)
Newsgroups: de.comp.lang.c
Subject: Re: Verhalten von struct-Pointers
Date: 14 Aug 92 05:42:57 GMT
Organization: PCS Computer Systeme GmbH

maennig@anton.informatik.uni-dortmund.de (Olaf Maennig) writes:

[..viel Zeugs geloescht..]
>    free(*s);
>    *s = 0x0;
[..viel Zeugs geloescht..]
>werden, warum aber wird structure auf NULL gesetzt, wenn freestruct() so
>aussieht:

>void freestruct(TEST *s)
>{
>    free(s);
>    s = 0x0;
>}

Wenn man "free (object)" macht und danach versucht, diesem Objekt 
(das ja nun keinen gueltigen Speicherplatz mehr hat!) einen  Wert
zuzuweisen,  darf man nicht mehr  "warum passiert dies oder das?"
fragen - danach kann alles passieren. 

Das ist ein BUG!

Wolfgang

==================================================================
Name    : Wolfgang Denk                         (+49)-89-68004-288
Company : PCS GmbH, Pfaelzer-Wald-Str. 36,  8000 Munich,  Germany.
UUCP    : ..[pyramid ;uunet!unido]!pcsbst!wd  (PYRAMID PREFERRED!!)
DOMAIN  : wd@pcsbst.pcs.[ COM From rest of world; DE From Europe ]
###################################################################
#  "UNIX was not designed to stop you from doing stupid things,   #
#   because that would  also stop you from doing clever things."  #
#   -- Doug Gwyn                                                  #
###################################################################
From: fs@oops.zigzag.hanse.de (Frank Seitz @ home)
Newsgroups: de.comp.lang.c
Subject: Re: Verhalten von struct-Pointers
Date: 14 Aug 92 14:09:00 GMT
Organization: OOPS (Netzwerke/Datenbanksysteme/Sprachverarbeitung)

maennig@anton.informatik.uni-dortmund.de (Olaf Maennig) writes:

(...)
()warum aber wird structure auf NULL gesetzt, wenn freestruct() so
()aussieht:

()void freestruct(TEST *s)
(){
()    free(s);
()    s = 0x0;
()}

()und der Aufruf freestruct(structure) lautet?
()Wird der Speicherplatz f"ur structure im zweiten Fall "uberhaupt freigegeben?

Ja, er wird freigegeben. Aber es aendert sich der Wert des
Pointers  n u r  in freestruct(),  n i c h t  beim Aufrufer. Was Du
oben geschrieben hast (dass der Pointer beim Aufrufer auf NULL
gesetzt wird) ist falsch.

Grund:
	* Der Speicher, den Du mit calloc() alloziert hast, ist ein
	  Heap-Objekt, das solange existiert, wie das Programm laeuft.
	  Es sei denn, Du zerstoerst es vorzeitig mit free(). Und
	  genau dies tust Du in freestruct(). Wichtig dabei: der
	  allozierte Speicher existiert unabhaengig von
	  den Zeigern, die auf ihn zeigen!
	* Der Pointer "s" in freestruct() ist eine  l o k a l e
	  Variable, also ein Stack-Objekt, das nur so lange
	  existiert, bis die Funktion verlassen wird. Da in C
	  Parameter grundsaetzlich "by value" uebergeben
	  werden, musst Du Dir "s" also als eine  K o p i e  von
	  "structure" (des aktuellen Parameters beim Aufrufer)
	  vorstellen. Wertaenderungen an dieser Kopie schlagen natuerlich
	  nicht auf das "Original" durch!
Ergo:
	* Beim Betreten von freestruct() haben die Pointer "structure"
	  und "s" denselben Wert. Sie zeigen beide gemeinsam auf
	  den Anfang des allozierten Speicherbereichs, sind aber
	  ansonsten unabhaengig voneinander.
	* Wenn freestruct() verlassen wird, gibt es a) den allozierten
	  Speicherbereich, und b) die lokale Variable "s"
	  nicht mehr. Mit "s" ist auch der Wert, den "s" zuletzt
	  hatte (naemlich NULL), untergegangen.
	* Der Pointer "structure" beim Aufrufer existiert weiter.
	  Er hat noch denselben Wert wie vor dem Aufruf von freestruct().
	  Dieser Wert ist wegen des zwischenzeitlichen Aufrufs
	  von free() ungueltig geworden. Folglich zeigt der Pointer
	  nun in den Wald.
	* Deine erste Loesung ist goldrichtig. Dort wird der
	  Wert von "structure" richtig auf NULL gesetzt. Das funktioniert,
	  weil der Wert von "s" dort nichts anderes als die Adresse von
	  "structure" ist. Mit der Zuweisung *s = NULL aenderst
	  Du dann direkt den Wert von "structure". In C ist das die
	  uebliche Methode, um Referenzparameter zu simulieren,
	  d.h. ein "call by reference" zu machen. C++ kennt auch
	  die weniger verwirrenden, echten Referenzparameter.

Phhhu, eigentlich wollte ich nur zwei, drei Saetze zu der Sache
schreiben. Jetzt sind's ein paar mehr geworden. Aus den beabsichtigten
paar Minuten wurde eine gute Stunde. Hoffe, ich habe
wenigstens etwas mehr entwirrt als verwirrt, Olaf...
-- 
Frank Seitz, Hamburg, 040/7927569, {fs,root,postmaster}@oops.zigzag.hanse.de
From: ft1wf@ft1sparc.ft1.tu-harburg.de (Werner Fleck)
Newsgroups: de.comp.lang.c
Subject: Re: Verhalten von struct-Pointers
Date: 14 Aug 92 12:57:30 GMT
Reply-To: fleck@tu-harburg.dbp.de
Organization: Technische Universitaet Hamburg-Harburg

In article <wd.713770977@tukan>, wd@pcsbst.pcs.com (wd) writes:
|> maennig@anton.informatik.uni-dortmund.de (Olaf Maennig) writes:
|> 
|> [..viel Zeugs geloescht..]
|> > [..nochmehr Zeugs geloescht..]
|> 
|> Wenn man "free (object)" macht und danach versucht, diesem Objekt 
|> (das ja nun keinen gueltigen Speicherplatz mehr hat!) einen  Wert
|> zuzuweisen,  darf man nicht mehr  "warum passiert dies oder das?"
|> fragen - danach kann alles passieren. 
|> 
|> Das ist ein BUG!
|> 
|> Wolfgang
|> 
|> ==================================================================
|> Name    : Wolfgang Denk                         (+49)-89-68004-288
|> Company : PCS GmbH, Pfaelzer-Wald-Str. 36,  8000 Munich,  Germany.
|> UUCP    : ..[pyramid ;uunet!unido]!pcsbst!wd  (PYRAMID PREFERRED!!)
|> DOMAIN  : wd@pcsbst.pcs.[ COM From rest of world; DE From Europe ]

Beeinflussen solche Erkenntnisse bei Euch die Programmentwicklung? Dann
wundert mich naehmlich garnichts mehr.

Natuerlich kann man nach einem "free (object)" diesem einen Wert zuweisen,
z.B. durch ein "object = malloc (irgendwas)".

Werner

-- 
* Werner Fleck                            * email: fleck@tu-harburg.dbp.de *
* Arbeitsbereich Fertigungstechnik I      *                                *
* Technische Universitaet Hamburg-Harburg *                                *
* Denickestrasse 17                       * Tel.: +49 40 7718-3286         *
* D-2100 Hamburg 90                       * Fax:  +49 40 7718-2500         *
From: lingnau@math.uni-frankfurt.de (Anselm Lingnau)
Newsgroups: de.comp.lang.c
Subject: n["0123456789"] illegal? (war Re: Dumme Frage)
Date: 18 Aug 92 09:08:28 GMT
Distribution: world
Organization: University of Frankfurt/Main, Dept. of Mathematics

Im Artikel <1992Aug3.210510.22038@mcshh.Hanse.DE> schreibt
buster@mcshh.Hanse.DE (Andreas Burmester):
[ es geht um n["0123456789"] ]
> Nein, nein! Jeder vernuenftige (ANSI- sowieso) Compiler wird das 
> "verwirrendere" Konstrukt zurueckweisen - n ist nun mal kein Pointer,
> sondern ein int. Und ein int kann nicht implizit auf Pointer (Pointer
> auf was eigentlich??) gecasted werden.

Ahem. n ist zwar kein Pointer, aber "012..." ist einer. Und
Arrayindizierung ist gem"ass a[e] == *((a)+(e)) == e[a] kommutativ, so
unwahrscheinlich es auch scheinen mag --- aber das ist die Definition.
Die einzigen Bedingungen sind, dass `e' ein beliebiger Ausdruck und `a'
ein `prim"arer Ausdruck' ist, und dass einer davon ein Pointerausdruck
und einer ein ganzzahliger Ausdruck ist. Es ist egal, welcher.

>   (char *)n["0123456789"]
> 
> koennte eher durchgehen - ein strikter Compiler wird allerdings etwas
> wie "int expected" (der einzig erlaubte Typ fuer Array Indices) zum
> String sagen.

Das ist, leider, komplett daneben. Die Indizierung bindet st"arker als
der Cast, dadurch wird das *Zeichen*, das bei der Indizierung
herauskommt, zu einem (char *) gecastet. Im "ubrigen kann man Felder
mit jedem ganzzahligen Typ indizieren, nicht bloss mit `int'.

>   (char *)n[(int)"0123456789"]
> 
> endlich ist ok.

Da bin ich aber anderer Ansicht. Eine konstante Zeichenkette entspricht
ja einem (const char *). Der Cast zu (int) bezieht sich also auf den
Zeiger auf das erste Zeichen der Zeichenkette und nicht etwa auf das
Zeichen, auf das dieser Zeiger zeigt.

Der Abschnitt 2 der Frequently Asked Questions in comp.lang.c
besch"aftigt sich im wesentlichen mit Feldern und Zeigern. Insbesondere
diskutiert Frage 2.7 Ausdr"ucke der Form `5["abcdef"]'. Sehr lesenswert.

Anselm
--
Anselm Lingnau, Buchenweg 1, 6239 Eppstein| You see things, and you say `Why?'
lingnau@math.uni-frankfurt.de      Germany| But I dream things that never were,
University of Frankfurt, CompSci and Maths| and say `Why not?'  --- G. B. Shaw
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: de.comp.lang.c
Subject: Re: Ausf"uhrungszeit bei der Pointerarithmetik?
Date: 22 Aug 1992 23:58:48 +0200
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: 127.0.0.1

In de.comp.lang.c, article <173296INNja0@fbi-news.Informatik.Uni-Dortmund.DE>,
  maennig@siggi.informatik.uni-dortmund.de writes:
> 
> [ Optimierungsproblem bei verketteten Zeigern ]
> 
Im Zweifelsfall ist die Methode, sich den Zeiger extra irgendwo zu merken,
vorzugsweise in einem "register"-Pointer (fuer die Compiler, die sowas nicht
selber raffen), schneller. 

Bessere Idee: Greif dir jemanden, der den Maschinencode auseinanderpfluecken
kann, und frage den bzw. die Compiler, was sie fuer Code generieren.

Noch bessere Idee: Schalte den Optimierer an, schreib den Code so, dass du
ihn selber am besten lesen kannst, und vergiss das Problem. Solange du nicht
direkt auf der Hardware reitest und mit jedem Zyklus geizen musst (und dann
empfehle ich andere Datenstrukturen), ist der Performanceunterschied im
Zweifelsfall eh minimal.

-- 
Turnaucka's Law:
        The attention span of a computer is only as long as its
        electrical cord.
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/
From: lingnau@math.uni-frankfurt.de (Anselm Lingnau)
Newsgroups: de.comp.lang.c
Subject: Re: Statuswechsel im switch
Date: 14 Aug 92 16:11:14 GMT
Distribution: world
Organization: University of Frankfurt/Main, Dept. of Mathematics

Im Artikel <1992Jul30.165324.6834@swabsib.stgt.sub.org> schreibt
tobi@swabsib.stgt.sub.org (Tobias Hennerich):

> if(foo==bar1)
>     laber();
> else {
>     if(foo==bar2)
> 	fasel();
> 
>     bla();
> }
> 
> Hat sogar noch den Vorteil, dass foo und bar floats sein duerfen...

Aber, aber. Wer wird denn floats auf Gleichheit testen?

Anselm
--
Anselm Lingnau, Buchenweg 1, 6239 Eppstein| You see things, and you say `Why?'
lingnau@math.uni-frankfurt.de      Germany| But I dream things that never were,
University of Frankfurt, CompSci and Maths| and say `Why not?'  --- G. B. Shaw
Newsgroups: de.comp.lang.c
From: zrawi01@indiaka.zdv.uni-tuebingen.de (J. Wiedmann)
Subject: Re: 'static' innerhalb einer Schleife??
Organization: Comp. Center (ZDV) U of Tuebingen, FRG
Date: Tue, 18 Aug 1992 08:18:20 GMT

In <H.4S1Lr7JKuFQ@wasy.sub.org> pmh@wasy.sub.org (Patrick M. Hausen) writes:

>Auch in K&R steht schon, dasz man am Anfang jedes Blocks Variablen
>definieren kann. Der Gueltigkeitsbereich dieser erstreckt sich bis zum
>Ende des Blocks.

Sehr nuetzlich ist das z.B. um innerhalb einer Funktion mehr Register-Variablen
zu verwenden als eigentlich moeglich sind. Manche C-Compiler (z.B. Aztec-C auf
dem Amiga) verwenden dann ein Register innerhalb der verschiedenen Bloecke
fuer verschiedene Variablen.

		Jochen
-- 
Jochen Wiedmann			E-Mail: wiedmann@mailserv.zdv.uni-tuebingen.de
Wolkensteinstr. 14
7403 Ammerbuch-Poltringen	Message of the day: Von naechster Woche an
Tel. 07073/4291			werden Passworte in Morsecode eingegeben.			
--
Jochen Wiedmann			E-Mail: wiedmann@mailserv.zdv.uni-tuebingen.de
Wolkensteinstr. 14
7403 Ammerbuch-Poltringen	Message of the day: Von naechster Woche an
Tel. 07073/4291			werden Passworte in Morsecode eingegeben.			
Newsgroups: de.comp.lang.misc
From: me@halfab.ka.sub.org  (Udo_Meyer)
Subject: Re: C ist keine Programmiersprache : -)
Reply-To: me@halfab.ka.sub.org (Udo_Meyer)
Organization: Udo Meyer, Postwiese 32, 7746 Hornberg, Germany, 49 7833 1425
Date: Sat, 15 Aug 1992 10:38:30 GMT

In article <HMkvr*hh0@forge.erh.sub.org> barnard@forge.erh.sub.org (Henning  
Schmiedehausen) writes:
> In article <bof.713281236@midget.saar.de>, Patrick Schaaf writes:
> 
> > pfeifer@gmd.de (Gregor Pfeifer) writes:
> > >In <H.YQ2p7x6gGXQ@wasy.sub.org> pmh@wasy.sub.org (Patrick M. Hausen)  
writes:
> > >>Eine Programmiersprache, die kein malloc()/new/ALLOCATE kennt, ist keine.
> > >Eine Programmiersprache, die ein malloc() und kein GC kennt, ist keine :-)
> > Eine Programmiersprache, die man nicht kennt, ist keine :-) :-)
> Eine Programmiersprache ist keine Programmiersprache. :) :) :)
Vor dem Programmiersprechen Gehirn einschalten. :) :)

Gruss, Udo.

-- 
Haeh?	Haeufige Nachfrage von Programmiersprachenuebersetzern.
Newsgroups: de.comp.lang.misc
From: backes@cadsun.uni-sb.de (Rainer Backes)
Newsgroups: de.comp.lang.pascal
Subject: Turbo Pascal API for NetWare
Keywords: API TURBO-PASCAL
Date: 18 Aug 92 11:04:49 GMT

Hi Netfolks !
(urspruengliche Newsgroup war comp.sys.novell ..)

Sorry for wasting some bandwidth, but Novell (and others)
are using this medium for their informations too.

Some times ago I posted some questions about the encrypted
password calls (do you remember ?).

Now the product is shipping: the 'bond' tools for Novell
NetWare and Turbo Pascal. 

The product includes nearly all API-functions available in
the Novell C-API for DOS. There are two disadvantages:
  - you can't write VAPs with it (Turbo Pascal isn`t able to
     produce VAPs)
  - the encrypted password calls are not supported yet, because
    Novell wasn't able (or willing) to support us with the
    necessary .obj files. ( the source is top secret)
But there are some advantages:
  - I builded an object-oriented layer on the IPX/SPX 
    communication functions. Doing IPX/SPX communication is
    now as easy as doing file or screen I/O.
    Did you ever try to establish a SPX connection without
    polling (using Event Service Routines) ?
    Now you don't have to worry about ESR, ECB, stacks and 
    so on, just call ObjectName.EstablishConnection.
  - For all german-speaking poeple there is one great advantage:
    we wrote a 870 page documentation in GERMAN.
    English speaking folks: sorry, but you can use the Docs
    of Novell (NetWare technical Reference, Doc of C-API)
    because the Names of the procedures and functions and
    the calling parameters are similar to the C-API.
    (exept the object oriented Comm. Layer).
  - the 'bond' tools support windows (3.0 and 3.1). A simple
    {$define}  lets the units compile for Turbo Pascal
    for Windows. The IPX/SPX functions are not yet supported
    for Windows, but we are working on it. We will ship this
    upgrade to all registered customers, when it is available.  
  - the 'bond' tools are shipped with full source code.

And now there is the great drawback: we want money for that stuff !

Yes, I am a student of Computer Sciences, but that's only the one
side. On the other side I am CNE/CNI and I have with 3 other poeple
a small company called 'bond' Software-Entwicklung GmbH. We spend
very much time in writing the software and very more time in writing
the documentation. Noone did pay us for that time yet. So we have 
to sell our product.

The price is 749,- DM plus Taxes and Shipping.

The order address is:
'bond' Software-Entwicklung GmbH
Illinger Str. 76
W-6682 Ottweiler
GERMANY

phone: +49 6824 2031
telefax: +49 6824 2034

Please don't order via E-Mail. If you have any questions, feel free
to contact us. (preferably via FAX. Email may take longer, because
my email-Address is at the university and I am not ervery day there)

I hope I didn't waste your time in giving you this information.


Rainer Backes
now for 'bond' Software-Entwicklung GmbH
From: root@ixgch.uucp (Superuser)
Newsgroups: de.comp.lang.pascal
Subject: suche *PD* pascal-compiler fuer (SCO) Unix!
Date: 13 Aug 92 16:43:41 GMT
Reply-To: root@ixgch.imp.com (Superuser)
Organization: XGP Switzerland
X-OS: XENIX System V Release 2.3.3

hallo!

ich suche fuer jemanden einen guten PUBLIC DOMAIN pascal-compiler
fuer (SCO) Unix. am allerliebsten gerade eine FTP-adresse.

danke & gruss:
-- 
Ch.Eckert, System Administrator, XGP Switzerland
Internet Mail: sysadm@ixgch.imp.com, SRI-NIC: CE13
Phone: +41-61 8115635 (voice/MET), +41-61 8115492 (ixgch)
@ Ixgate Switzerland (ixgch.imp.com) / XGP Switzerland
From: jan@nasobem.stgt.sub.org (Jan Schiefer)
Newsgroups: de.comp.lang.c++
Subject: Errata fuer Stroustrup, 2. Auflage?
Date: Wed, 12 Aug 92 10:09:18 GMT
Distribution: world

hello, world!

Nachdem ich gerade einen Hund in der deutschen Version von Bjaerne Stroustrups
"Die C++ Programmiersprache", 2. Auflage gefunden habe und mich auch an einige
andere Ungenauigkeiten erinnere, meine Frage:
Hat jemand eine Fehlerliste fuer dieses Buch? Fuer die englische Ausgabe habe
ich eine vom Meister selbst, aber die nennt nur Seitenzahlen fuer die englische
Version (die ich nicht habe).

Hat da jemand was?

Gruss,
        Jan

--
             Jan Schiefer, DL5UE, jan@nasobem.stgt.sub.org
                 "Oracle et laboracle!"   - Fritz Hohl