Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #388992 > unrolled thread

logically weird loop

Back to article view | Back to comp.lang.c

Contents

  logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 16:56 +0100
    Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 17:09 +0100
    Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-20 17:34 +0100
      Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 18:18 +0100
        Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 18:30 +0100
          Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-20 18:38 +0100
            Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-21 12:12 +0100
      Re: logically weird loop Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-20 23:53 +0000
        Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-21 07:06 +0100
          Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-21 11:41 +0100
            Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-21 12:01 +0100
              Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-21 13:26 +0100
                Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-21 14:05 +0100
                  Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-21 21:45 +0100
                    Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 18:19 +0100
          Re: logically weird loop Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-22 00:04 +0000
            Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-22 06:09 +0100
            Re: logically weird loop Michael S <already5chosen@yahoo.com> - 2024-11-22 16:05 +0200
              Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 18:23 +0100
                Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 18:27 +0100
              Re: logically weird loop Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 19:53 -0800
                Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 12:21 +0100
                  Re: logically weird loop David Brown <david.brown@hesbynett.no> - 2024-12-05 16:06 +0100
                    Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 17:14 +0100
          Re: logically weird loop Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 17:07 -0800
            Re: logically weird loop Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 12:41 +0100
              Re: logically weird loop Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-07 10:18 -0800
                Re: logically weird loop Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-07 13:53 -0800
                  Re: logically weird loop Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-08 03:52 +0000
                  Re: logically weird loop Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-18 18:43 -0800
        Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 18:48 +0100
          Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-22 19:14 +0100
            Re: logically weird loop fir <profesor.fir@gmail.com> - 2024-11-24 11:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#389391

Michael S <already5chosen@yahoo.com> writes:

> On Fri, 22 Nov 2024 00:04:32 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> Yes, Simula pioneered OO.  But the concept has gone in different
>> directions since then.  For example, multiple inheritance, metaclasses
>> and classes as objects -- all things that Python supports.
>
> What I read seems to suggest that Smalltalk had bigger influence on
> modern twists of OOP.  But then, may be Simula influenced Smalltalk?

There is no question that Simula had an influence on the development
of Smalltalk;  Alan Kay has said as much -

   https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

But the ideas of object-oriented programming came before Smalltalk
(and also before Simula).  It was the ideas underlying object-oriented
programming that influenced the Smalltalk language, not the other way
around.  (To be fair here I should add that other factors undoubtedly
influenced Smalltalk as well.)


> Anyway, I don't like OOP very much, esp. so the version of it that was
> pushed down our throats in late 80s and early 90s.

Almost everyone who took Simula and C++ as the archetype for OOP
never understood it.

[toc] | [prev] | [next] | [standalone]

#389398

On 05.12.2024 04:53, Tim Rentsch wrote:
> 
> Almost everyone who took Simula and C++ as the archetype for OOP
> never understood it.

LOL.

(Funny [dogmatic] statement, without any substance again.)

Janis

[toc] | [prev] | [next] | [standalone]

#389409

On 05/12/2024 12:21, Janis Papanagnou wrote:
> On 05.12.2024 04:53, Tim Rentsch wrote:
>>
>> Almost everyone who took Simula and C++ as the archetype for OOP
>> never understood it.
> 
> LOL.
> 
> (Funny [dogmatic] statement, without any substance again.)
> 

If you take the position that Alan Key, as the person who is credited 
with inventing the term "object oriented programming", gets to make the 
definition of what OOP is, then Tim's statement is accurate.  Originally 
OOP meant something very different from how it is interpreted in C++. 
(I don't know Simula except by reputation, so I can't comment on that.)

The original idea of OOP was to have self-contained "objects" that 
communicated only by passing messages.  If object A wanted object B to 
do "foo", it would not call "B.foo()" in its own context, as is done in 
C++.  Instead, it would pass a message "foo" to B.  What B does with it, 
and when, is up to B.  If a return value is expected, then B will send a 
message with the answer back to A.

This is, I think, akin to the modern "actor" programming paradigm, and 
it has connections back to Hoare's CSP (which has inspired many systems 
and languages, most recently Golang).  It gives you a robust, modular 
system with great scalability - objects can run on different cores or 
threads, or different computers connected by a network.  Data races and 
other concurrency issues are pretty much impossible.  Different parts of 
the program could be changed at run-time.

Of course, all this has significant overheads - it is not suitable for a 
low-level high efficiency language.  The rather different idea of OOP 
represented by languages like C++ can be very much more efficient, which 
is why it caught on.

Perhaps the language that is most true to the original idea is Erlang, 
with its "write once, run forever" motto.

[toc] | [prev] | [next] | [standalone]

#389416

On 05.12.2024 16:06, David Brown wrote:
>> On 05.12.2024 04:53, Tim Rentsch wrote:
>>>
>>> Almost everyone who took Simula and C++ as the archetype for OOP
>>> never understood it.
> 
> If you take the position that Alan Key, as the person who is credited
> with inventing the term "object oriented programming", gets to make the
> definition of what OOP is, then Tim's statement is accurate.  Originally
> OOP meant something very different from how it is interpreted in C++. (I
> don't know Simula except by reputation, so I can't comment on that.)

(For the topic discussed here I think it would be necessary, or at
least helpful, to know Simula, though.)

> 
> The original idea of OOP was to have self-contained "objects" that
> communicated only by passing messages.  If object A wanted object B to
> do "foo", it would not call "B.foo()" in its own context, as is done in
> C++.  Instead, it would pass a message "foo" to B.  What B does with it,
> and when, is up to B.  If a return value is expected, then B will send a
> message with the answer back to A.

(see below)

> This is, I think, akin to the modern "actor" programming paradigm, [...]
> 
> Of course, all this has significant overheads - it is not suitable for a
> low-level high efficiency language.  The rather different idea of OOP
> represented by languages like C++ can be very much more efficient, which
> is why it caught on.

Right.

> 
> Perhaps the language that is most true to the original idea is Erlang,
> with its "write once, run forever" motto.

To open the knot, concerning this statement and the paragraph above
where you formulate "original idea of OOP", is to make clear what
each of us thinks would be crucial for "OOP".

If the "OO properties" are what at the time the term "OO" was coined
and associated with - which was rather late, as I think - is meant
then it would be a very limited view, focused by the inventor of the
*term* "OO". But the "OO" concepts - AFAICT - existed before the term.

If I look up various Wikipedia entries I find the properties
 *  Inheritance
 *  Polymorphism
 *  Encapsulation
 *  Abstraction
All of which have (for example) been implemented (besides some other
features that support Object Oriented Programming) already by Simula.

We find statements about separate, collaborating, communicating,
objects, about objects having attributes and "methods" (functions).

We also find statements like:
 "Simula introduced important concepts that are today an essential
  part of object-oriented programming, such as class and object,
  inheritance, and dynamic binding."

Yet I haven't seen anyone who would dissent that Simula had been the
first implemented OO language (released 1967).

My (historic) experience with OO is that most people heard about OO
only in context of Smalltalk (1972) [Alan Kay]. Their specific (but
mostly unnecessarily introduced) terminology became common speech in
that context. And the long existing Simula wasn't even known widely.

As an anecdote: Decades ago there was an "OO expert" (B. Oestereich)
who gave (in the upcoming flourishing OO days of C++) speeches at IT
boards, he wrote books about the topic, gave interviews, and so on.
His first book started with on overview of the OO languages (with
Smalltalk as the root), and its descendants, and where it influenced
other languages. - I sent him a mail pointing to Simula (as being,
if not the root of all, at least the first OO language). Cautiously
he asked me about its features and conceded that his picture was
wrong. - The next edition of his book had that corrected.

And the whole discussion about OO had always mostly been done with
the worn blinkers. B. Stroustrup's mention of Simula in his books
somewhat contributed to get a more open minded view on OO, what it
is, and who has its most merits.

Janis

[toc] | [prev] | [next] | [standalone]

#389384

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 21.11.2024 00:53, Lawrence D'Oliveiro wrote:
>
>> On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:
>>
>>> [*] A friend of mine just recently implemented the code frame for a
>>> roguelike and followed the suggestion of an event based object-oriented
>>> implementation;  it worked well, he told me.
>>
>> The next step would be to use coroutines so the logic of a longer-running
>> task, which has to wait for other events at multiple points, can be
>> written in a single linear stream without having to be fragmented into
>> multiple callbacks.
>
> Yes, indeed.
>
> Actually, if you know Simula, coroutines are inherent part of that
> language, and they based their yet more advanced process-oriented
> model on these.  I find it amazing what Simula provided (in 1967!)
> to support such things.  Object orientation[*], coroutines, etc.,
> all fit together, powerful, and in a neat syntactical form. - But
> "no one" is using Simula, and my friend was using C++; don't know
> what C++ supports in that respect today.  I know that he implemented
> the "simulation" parts (queuing, time-model, etc.) in C++ himself.
>
>
> [*] It was the language who invented Object Orientation [...]

No, it wasn't.  First, programming in a language with classes and
objects does not imply object-oriented programming.  Second, the
underlying ideas of object-oriented programming pre-date Simula 67
by five years or more.  That history has been pointed out by
Alan Kay, who is the originator of the term and is responsible
for pioneering the concept.

[toc] | [prev] | [next] | [standalone]

#389399

On 05.12.2024 02:07, Tim Rentsch wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>> Actually, if you know Simula, coroutines are inherent part of that
>> language, and they based their yet more advanced process-oriented
>> model on these.  I find it amazing what Simula provided (in 1967!)
>> to support such things.  Object orientation[*], coroutines, etc.,
>> all fit together, powerful, and in a neat syntactical form. - But
>> "no one" is using Simula, and my friend was using C++; don't know
>> what C++ supports in that respect today.  I know that he implemented
>> the "simulation" parts (queuing, time-model, etc.) in C++ himself.
>>
>> [*] It was the language who invented Object Orientation [...]
> 
> No, it wasn't.  First, programming in a language with classes and
> objects does not imply object-oriented programming. 

It does not necessarily imply it. But if you'd know some more about
it you might understand that it's the natural way of thinking when
simulating systems' objects, and modeling object structures. Simula
in a natural way provided the platform to program object oriented.
(As said, without coining the term or speaking about "OO".)

> Second, the
> underlying ideas of object-oriented programming pre-date Simula 67
> by five years or more. 

Of course the ideas were there before Simula was released in 1967;
the inventors (also publicly) presented their ideas five years ago.

> That history has been pointed out by
> Alan Kay, who is the originator of the term and is responsible
> for pioneering the concept.

Yes, the Simula "OO" pioneers didn't invent the *term* "OO", but they
were (amongst) the first who spread the ideas and the first inventing
a language to model OO and work with the OO concepts that are still
used and implemented in many other OO languages nowadays.

(All the rest is [IMO] no more than dogmatic or marketing.)

If you have some substance on the topic I'm always interested to hear.

Janis

[toc] | [prev] | [next] | [standalone]

#389495

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 05.12.2024 02:07, Tim Rentsch wrote:
>
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>> Actually, if you know Simula, coroutines are inherent part of that
>>> language, and they based their yet more advanced process-oriented
>>> model on these.  I find it amazing what Simula provided (in 1967!)
>>> to support such things.  Object orientation[*], coroutines, etc.,
>>> all fit together, powerful, and in a neat syntactical form. - But
>>> "no one" is using Simula, and my friend was using C++; don't know
>>> what C++ supports in that respect today.  I know that he implemented
>>> the "simulation" parts (queuing, time-model, etc.) in C++ himself.
>>>
>>> [*] It was the language who invented Object Orientation [...]
>>
>> No, it wasn't.  First, programming in a language with classes and
>> objects does not imply object-oriented programming.
>
> It does not necessarily imply it.  But if you'd know some more about
> it you might understand that it's the natural way of thinking when
> simulating systems' objects, and modeling object structures.  Simula
> in a natural way provided the platform to program object oriented.
> (As said, without coining the term or speaking about "OO".)

I've been doing object-oriented programming, as explained by Alan
Kay, since the late 1970s.  I've written code in Simula 67, three
different versions of Smalltalk, and C++.  C++ is a pale shadow
of Simula, and Simula is a pale shadow of Alan Kay's vision of
object-oriented programming.  People who think programming in C++
or Simula encourages object-oriented programming don't understand
the term.

>> Second, the
>> underlying ideas of object-oriented programming pre-date Simula 67
>> by five years or more.
>
> Of course the ideas were there before Simula was released in 1967;
> the inventors (also publicly) presented their ideas five years ago.

The key ideas underlying object-oriented programming were not done
by the people who developed Simula.

>> That history has been pointed out by
>> Alan Kay, who is the originator of the term and is responsible
>> for pioneering the concept.
>
> Yes, the Simula "OO" pioneers didn't invent the *term* "OO", but they
> were (amongst) the first who spread the ideas and the first inventing
> a language to model OO and work with the OO concepts that are still
> used and implemented in many other OO languages nowadays.

You are confusing programming with classes and objects as being
the same as object-oriented programming.  It isn't.

> (All the rest is [IMO] no more than dogmatic or marketing.)
>
> If you have some substance on the topic I'm always interested to hear.

Let me offer some stories out of my own experiences.

In the mid 1970s, I listened to Alan Kay teach his class, over two
years, officially titled Philosophy of Computing but unofficially
titled The Alan Kay Mystery Hour.  A lot of times I was baffled by
why he was talking about what he was saying, but I understood what
he was saying.  At least that's what I thought at the time.  I might
add that there was no direct explanation of either the Smalltalk
language or object-oriented programming -- both were mentioned but
pretty much only in passing.  My reaction then was mostly that here
is another guy with a favorite language but programming languages
are all basically the same.  (I had already been exposed to Simula
before taking Alan's class.)

A year or so after finishing Alan's class, I took a class titled
(IIRC) "Object Oriented Programming", taught by three graduate
students who had worked in Smalltalk (which at the time must have
been Smalltalk 76).  The course was basically how to program in
Simula as though it were Smalltalk.  I was already proficient in
Simula before starting the class, and had no trouble following
what they were saying, programming-wise.  But in one class hour
something interesting happened.  Someone asked a question, and
the answer blew my mind.  It was an epiphany.  Suddenly lots of
the things that Alan had said fell into place;  my perspective
had changed.  For two years Alan had been talking over my head,
and in fact so far over that I hadn't even realized it.

Later, in the early-to-mid 1980s, I went to graduate school at
the University of North Carolina.  While there I had some
conversations with Fred Brooks about (among other things)
object-oriented programming.  I tried to give an example that
would let him understand the idea I was trying to explain.  I
could see by his reaction that it didn't help;  the idea hadn't
gotten across.  A year or two later one of the groups in Fred
Brooks's programming projects course (I don't remember the
official title) chose to do their project in Smalltalk.  During
the end-of-course review/demonstration, a question about was
asked about changing the behavior of one part of the program
(which had a visual representation so it could be seen as soon as
the change was done).  The person demonstrating said the change
could be made in two minutes.  When Brooks prompted with "Let's
see", the demonstrator made the change on the spot.  That made a
strong impression on Fred Brooks;  he looked over at me with an
expression that said "there really is something to what you've
been saying".

That demonstration was possible not because of classes and
objects but because Smalltalk embodies the principles of
object-oriented programming.

[toc] | [prev] | [next] | [standalone]

#389501

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
>                               People who think programming in C++
> or Simula encourages object-oriented programming don't understand
> the term.

Or they use the term differently than you do.  Language is not static.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#389513

On 2024-12-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>>                               People who think programming in C++
>> or Simula encourages object-oriented programming don't understand
>> the term.
>
> Or they use the term differently than you do.  Language is not static.

Obviously, the term they don't understand is "encourages", not
"object-oriented".

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#390075

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>
>>                               People who think programming in C++
>> or Simula encourages object-oriented programming don't understand
>> the term.
>
> Or they use the term differently than you do.  Language is not static.

There's a confusion here.  I didn't say they misunderstand the
term;  what I said is they don't understand the term.  That is
an essential difference.

[toc] | [prev] | [next] | [standalone]

#389033

Lawrence D'Oliveiro pisze:
> On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:
> 
>> [*] A friend of mine just recently implemented the code frame for a
>> roguelike and followed the suggestion of an event based object-oriented
>> implementation; it worked well, he told me.
> 
> The next step would be to use coroutines so the logic of a longer-running
> task, which has to wait for other events at multiple points, can be
> written in a single linear stream without having to be fragmented into
> multiple callbacks.
> 
i dont know to much on coroutines (what i knew i forgot as even my 
memory this year is terribly bad) or simule bot from some other
reasoning i know thet "call queue" is veru good thing

possibly it may be better or at least equal in thiat coroutines or
what was in simula

in basic call queue it gioes klike this afai

for(int i=0; i<all; i++)
    add_queue foo(i);

foo() are storred in queue so then can be run i pseudo parralel
mode at some point

add_queue stores function adress and argument on stack like queue

here in rogualike it would use this time variable also

  DoAction(int i)
  {
    if(character[i].action_end > current_time) return;
// do nothing until time comes

// time has come do something
   character[i],action_end += 300;
  add_queue DoAction(i); //put yourself on queue


}

StartUp()
{
for(int i=0; i<all; i++) add_queue DoAction(i);

}

// in some code
  run_queue // queue may add soem alelemnts but also executed things are 
taken out of queue

i guess it should be something like that

[toc] | [prev] | [next] | [standalone]

#389035

fir pisze:
> Lawrence D'Oliveiro pisze:
>> On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:
>>
>>> [*] A friend of mine just recently implemented the code frame for a
>>> roguelike and followed the suggestion of an event based object-oriented
>>> implementation; it worked well, he told me.
>>
>> The next step would be to use coroutines so the logic of a longer-running
>> task, which has to wait for other events at multiple points, can be
>> written in a single linear stream without having to be fragmented into
>> multiple callbacks.
>>
> i dont know to much on coroutines (what i knew i forgot as even my 
> memory this year is terribly bad) or simule bot from some other
> reasoning i know thet "call queue" is veru good thing
> 
> possibly it may be better or at least equal in thiat coroutines or
> what was in simula
> 
> in basic call queue it gioes klike this afai
> 
> for(int i=0; i<all; i++)
>     add_queue foo(i);
> 
> foo() are storred in queue so then can be run i pseudo parralel
> mode at some point
> 
> add_queue stores function adress and argument on stack like queue
> 
> here in rogualike it would use this time variable also
> 
>   DoAction(int i)
>   {
>     if(character[i].action_end > current_time) return;
> // do nothing until time comes
> 
> // time has come do something
>    character[i],action_end += 300;
>   add_queue DoAction(i); //put yourself on queue
> 
> 
> }
> 
> StartUp()
> {
> for(int i=0; i<all; i++) add_queue DoAction(i);
> 
> }
> 
> // in some code
>   run_queue // queue may add soem alelemnts but also executed things are 
> taken out of queue
> 
> i guess it should be something like that
> 
  i once said probably call queues should be a god way to do 
multithreading becouse say you got a routine that calculates and draw a 
vertical line of mandelbrot

for(int i=0; i<1000; i++)
  add_queue1 draw_mandelbrot(i);

run_queue1;

as thoise calculations are independant the run_queue may execute queue
(which is table of 1000 pointers and 1000 ints)
pararelly in 1000 threads and its very easy

when items may be dependant soem could add them to queue but also
store some tag (like group number) when eech group is independant versus 
other groups so each group could be run separatelly on threads with 
knowledge there is no conflict


int group ;
for(int i=0; i<1000; i++)
{
if(bot[i].x<300) group = 1;
else if(bot[i].x>700) group = 2;
else if(bot[i].x>400 && bot[i].x<600) group = 3;
else group = 4;

add_queue1[group] run_bot(i);


}

something like that but with better syntax.. it asumes bots act locally 
on map and if are distant 100 distance they will not interract..than 
those 4 groups can be run on 4 threads assumning nio collision is possible


something like that

[toc] | [prev] | [next] | [standalone]

#389047

fir pisze:
> fir pisze:
>> Lawrence D'Oliveiro pisze:
>>> On Wed, 20 Nov 2024 17:34:34 +0100, Janis Papanagnou wrote:
>>>
>>>> [*] A friend of mine just recently implemented the code frame for a
>>>> roguelike and followed the suggestion of an event based object-oriented
>>>> implementation; it worked well, he told me.
>>>
>>> The next step would be to use coroutines so the logic of a 
>>> longer-running
>>> task, which has to wait for other events at multiple points, can be
>>> written in a single linear stream without having to be fragmented into
>>> multiple callbacks.
>>>
>> i dont know to much on coroutines (what i knew i forgot as even my 
>> memory this year is terribly bad) or simule bot from some other
>> reasoning i know thet "call queue" is veru good thing
>>
>> possibly it may be better or at least equal in thiat coroutines or
>> what was in simula
>>
>> in basic call queue it gioes klike this afai
>>
>> for(int i=0; i<all; i++)
>>     add_queue foo(i);
>>
>> foo() are storred in queue so then can be run i pseudo parralel
>> mode at some point
>>
>> add_queue stores function adress and argument on stack like queue
>>
>> here in rogualike it would use this time variable also
>>
>>   DoAction(int i)
>>   {
>>     if(character[i].action_end > current_time) return;
>> // do nothing until time comes
>>
>> // time has come do something
>>    character[i],action_end += 300;
>>   add_queue DoAction(i); //put yourself on queue
>>
>>
>> }
>>
>> StartUp()
>> {
>> for(int i=0; i<all; i++) add_queue DoAction(i);
>>
>> }
>>
>> // in some code
>>   run_queue // queue may add soem alelemnts but also executed things 
>> are taken out of queue
>>
>> i guess it should be something like that
>>
>   i once said probably call queues should be a god way to do 
> multithreading becouse say you got a routine that calculates and draw a 
> vertical line of mandelbrot
> 
> for(int i=0; i<1000; i++)
>   add_queue1 draw_mandelbrot(i);
> 
> run_queue1;
> 
> as thoise calculations are independant the run_queue may execute queue
> (which is table of 1000 pointers and 1000 ints)
> pararelly in 1000 threads and its very easy
> 
> when items may be dependant soem could add them to queue but also
> store some tag (like group number) when eech group is independant versus 
> other groups so each group could be run separatelly on threads with 
> knowledge there is no conflict
> 
> 
> int group ;
> for(int i=0; i<1000; i++)
> {
> if(bot[i].x<300) group = 1;
> else if(bot[i].x>700) group = 2;
> else if(bot[i].x>400 && bot[i].x<600) group = 3;
> else group = 4;
> 
> add_queue1[group] run_bot(i);
> 
> 
> }

now its an error becouse when gorups 1 2 3 could run in parralel group 4 
can not (but someteimes when i post something i see an error but not 
bother to correct as its seen)

but becouse this is error it shows that eventually something more
could or shoudl be used than raw number of groups to encode a group
dependancy (like 4 can be executed after 1,2,3..but im not sure as for now

this queue hovever as i already said seem to me probably the most
conveniant way to d multithreading in c (some extended c) -
simply you feel queue and compiler or system simply runs it and it knows
the marked things are independant... so you get  easy and cklear on code 
side and easy and clear on hardware side
> 
> something like that but with better syntax.. it asumes bots act locally 
> on map and if are distant 100 distance they will not interract..than 
> those 4 groups can be run on 4 threads assumning nio collision is possible
> 
> 
> something like that

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web