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


Groups > comp.lang.c++ > #84045 > unrolled thread

Implementing a two-way Turing Machine tape as an improvement to std::deque

Started byolcott <NoOne@NoWhere.com>
First post2022-05-12 17:51 -0500
Last post2022-05-13 12:05 -0500
Articles 10 on this page of 30 — 8 participants

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


Contents

  Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-12 17:51 -0500
    Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-12 23:56 +0100
      Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-12 18:09 -0500
        Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 00:22 +0100
          Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-12 18:38 -0500
            Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 00:40 +0100
              Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-12 18:49 -0500
                Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 00:53 +0100
                  Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-12 19:12 -0500
                    Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 01:58 +0100
                      Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-12 20:34 -0500
                        Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Öö Tiib <ootiib@hot.ee> - 2022-05-12 21:05 -0700
                        Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 08:02 +0100
                          Re: Implementing a two-way Turing Machine tape as an improvement to std::deque tth <tth@none.invalid> - 2022-05-13 09:10 +0200
                            Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-13 10:47 -0500
                              Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Ben <ben.usenet@bsb.me.uk> - 2022-05-13 17:22 +0100
                              Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-13 19:31 +0300
                          Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-13 10:58 -0500
                            Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 17:02 +0100
                              Re: Implementing a two-way Turing Machine tape as an improvement to std::deque "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-05-13 12:44 -0700
    Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Richard Damon <Richard@Damon-Family.org> - 2022-05-12 19:23 -0400
      Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-12 18:32 -0500
    Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Ben <ben.usenet@bsb.me.uk> - 2022-05-13 01:06 +0100
      Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-12 19:55 -0500
        Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 02:01 +0100
          Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-12 20:36 -0500
            Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 08:04 +0100
              Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-13 11:00 -0500
                Re: Implementing a two-way Turing Machine tape as an improvement to std::deque Mr Flibble <flibble@reddwarf.jmc> - 2022-05-13 17:04 +0100
                  Re: Implementing a two-way Turing Machine tape as an improvement to std::deque olcott <NoOne@NoWhere.com> - 2022-05-13 12:05 -0500

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


#84049

FromRichard Damon <Richard@Damon-Family.org>
Date2022-05-12 19:23 -0400
Message-ID<5GgfK.2451$R6W6.1148@fx45.iad>
In reply to#84045
On 5/12/22 6:51 PM, olcott wrote:
> C/C++ people please critique this as the basis for an improvement to 
> std::deque. It seems to have the key functionality of std::deque and
> does it much more simply while saving time and space.
> https://www.cplusplus.com/reference/deque/deque/
> 
> #define tape_element unsigned char
> 
> class Tape_Type
> {
> private:
>    int Tape_Head = 0;               // Can be negative
>    std::vector<tape_element> Left;  // Stores left expansion
>    std::vector<tape_element> Right; // Stores right expansion
>    tape_element & operator[](int index);
> 
> public:
>    void move_left();      // Tape_Head--; Left.push_back(0); as needed
>    void move_right();     // Tape_Head++; Left.push_back(0); as needed
>    void Write(tape_element Y){ this->operator[](Tape_Head) = Y; };
>    tape_element Read()       { return this->operator[](Tape_Head); };
>    Tape_Type(){ Right.push_back('_'); } // constructor
>    void Output();
> };
> 
> tape_element& Tape_Type::operator[](int index)
> {
>    if (index > 0)
>      return Right[index];
>    int Left_Index = ((index * -1) -1);
>    return Left[Left_Index];
> }
> 
> void Tape_Type::Output()
> {
>    printf("Tape_Type::Output()\n");
> 
>    if (Left.size())
>    {
>      int Last_One = Left.size() - 1;
>      for (int N = Last_One; N >= 0; N--)
>      {
>        int TH = (N + 1) * -1; // determine Tape_Head from N
>        printf("[%04d]:%c   Left[%02d]\n", TH, Left[N], N);
>      }
>    }
>    if (Right.size())
>      for (int N = 0; N < Right.size(); N++)
>        printf("[%04d]:%c  Right[%02d]\n", N, Right[N], N);
> }
> 
> void Tape_Type::move_left()
> {
>    Tape_Head--;
>    int Left_Index = ((Tape_Head * -1) -1);
>    if (Left_Index == Left.size())
>      Left.push_back('_');
> }
> 
> void Tape_Type::move_right()
> {
>    Tape_Head++;
>    if (Tape_Head == Right.size())
>      Right.push_back('_');
> }
> 
> 
> 

Looks at what indexing with an index value of 0 does.

Operator [] want to test index >= 0, not > 0

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


#84050

Fromolcott <NoOne@NoWhere.com>
Date2022-05-12 18:32 -0500
Message-ID<Up-dnYjT5e-2BOD_nZ2dnUU7_8zNnZ2d@giganews.com>
In reply to#84049
On 5/12/2022 6:23 PM, Richard Damon wrote:
> On 5/12/22 6:51 PM, olcott wrote:
>> C/C++ people please critique this as the basis for an improvement to 
>> std::deque. It seems to have the key functionality of std::deque and
>> does it much more simply while saving time and space.
>> https://www.cplusplus.com/reference/deque/deque/
>>
>> #define tape_element unsigned char
>>
>> class Tape_Type
>> {
>> private:
>>    int Tape_Head = 0;               // Can be negative
>>    std::vector<tape_element> Left;  // Stores left expansion
>>    std::vector<tape_element> Right; // Stores right expansion
>>    tape_element & operator[](int index);
>>
>> public:
>>    void move_left();      // Tape_Head--; Left.push_back(0); as needed
>>    void move_right();     // Tape_Head++; Left.push_back(0); as needed
>>    void Write(tape_element Y){ this->operator[](Tape_Head) = Y; };
>>    tape_element Read()       { return this->operator[](Tape_Head); };
>>    Tape_Type(){ Right.push_back('_'); } // constructor
>>    void Output();
>> };
>>
>> tape_element& Tape_Type::operator[](int index)
>> {
>>    if (index > 0)
>>      return Right[index];
>>    int Left_Index = ((index * -1) -1);
>>    return Left[Left_Index];
>> }
>>
>> void Tape_Type::Output()
>> {
>>    printf("Tape_Type::Output()\n");
>>
>>    if (Left.size())
>>    {
>>      int Last_One = Left.size() - 1;
>>      for (int N = Last_One; N >= 0; N--)
>>      {
>>        int TH = (N + 1) * -1; // determine Tape_Head from N
>>        printf("[%04d]:%c   Left[%02d]\n", TH, Left[N], N);
>>      }
>>    }
>>    if (Right.size())
>>      for (int N = 0; N < Right.size(); N++)
>>        printf("[%04d]:%c  Right[%02d]\n", N, Right[N], N);
>> }
>>
>> void Tape_Type::move_left()
>> {
>>    Tape_Head--;
>>    int Left_Index = ((Tape_Head * -1) -1);
>>    if (Left_Index == Left.size())
>>      Left.push_back('_');
>> }
>>
>> void Tape_Type::move_right()
>> {
>>    Tape_Head++;
>>    if (Tape_Head == Right.size())
>>      Right.push_back('_');
>> }
>>
>>
>>
> 
> Looks at what indexing with an index value of 0 does.
> 
> Operator [] want to test index >= 0, not > 0

Good catch. I just wrote that function as a simplification.

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

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


#84055

FromBen <ben.usenet@bsb.me.uk>
Date2022-05-13 01:06 +0100
Message-ID<87wneq1ejm.fsf@bsb.me.uk>
In reply to#84045
olcott <NoOne@NoWhere.com> writes:

I've removed the philosophy group and comp.lang.c as this is C++.

> C/C++ people please critique this as the basis for an improvement to
> std::deque.

You will get critiques of the code on whatever basis people feel
inclined to comment!  You can't limit the comments to some particular
context.

> It seems to have the key functionality of std::deque and
> does it much more simply while saving time and space.

It does not have any of the functionality of std::deque.  There is a
commonly used (though not particularly efficient) way to implement a
deque using two arrays, but this is not it.

> #define tape_element unsigned char

Use a typedef or using declaration.  Also, I'd put the typedef in the
class as the type belongs to the class (as least that appears to be the
case from the name you've chosen).

> class Tape_Type
> {
> private:
>   int Tape_Head = 0;               // Can be negative
>   std::vector<tape_element> Left;  // Stores left expansion
>   std::vector<tape_element> Right; // Stores right expansion
>   tape_element & operator[](int index);
>
> public:
>   void move_left();      // Tape_Head--; Left.push_back(0); as needed
>   void move_right();     // Tape_Head++; Left.push_back(0); as needed

The comments are wrong since you push_back('_').

>   void Write(tape_element Y){ this->operator[](Tape_Head) = Y; };
>   tape_element Read()       { return this->operator[](Tape_Head); };

I'd write (*this)[Tape_Head] but I suppose that's just a matter of style.

>   Tape_Type(){ Right.push_back('_'); } // constructor

The constructor leaves a Tape_Type object in an unusable state, but
that's due to a bug in operator[].  Did you test?

>   void Output();
> };
>
> tape_element& Tape_Type::operator[](int index)
> {
>   if (index > 0)
>     return Right[index];

Bug.  You meant index >= 0 I think.

>   int Left_Index = ((index * -1) -1);

Why not -index - 1?

>   return Left[Left_Index];

Do you think introducing a new variable really make the code clearer
that simply writing

  return Left[-index - 1];

?  Personally, I'd write the whole thing as

  return index >= 0 ? Right[index] : Left[-index - 1];

> }
>
> void Tape_Type::Output()
> {
>   printf("Tape_Type::Output()\n");
>
>   if (Left.size())
>   {
>     int Last_One = Left.size() - 1;
>     for (int N = Last_One; N >= 0; N--)
>     {
>       int TH = (N + 1) * -1; // determine Tape_Head from N
>       printf("[%04d]:%c   Left[%02d]\n", TH, Left[N], N);
>     }
>   }
>   if (Right.size())
>     for (int N = 0; N < Right.size(); N++)
>       printf("[%04d]:%c  Right[%02d]\n", N, Right[N], N);
> }
>
> void Tape_Type::move_left()
> {
>   Tape_Head--;
>   int Left_Index = ((Tape_Head * -1) -1);
>   if (Left_Index == Left.size())
>     Left.push_back('_');
> }
>
> void Tape_Type::move_right()
> {
>   Tape_Head++;
>   if (Tape_Head == Right.size())
>     Right.push_back('_');
> }

I find the capitalisation odd and unhelpful as there does not seem to be
any consistency about it.

-- 
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

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


#84057

Fromolcott <NoOne@NoWhere.com>
Date2022-05-12 19:55 -0500
Message-ID<MeOdncpeZacPMeD_nZ2dnUU7_8zNnZ2d@giganews.com>
In reply to#84055
On 5/12/2022 7:06 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
> I've removed the philosophy group and comp.lang.c as this is C++.
> 
>> C/C++ people please critique this as the basis for an improvement to
>> std::deque.
> 
> You will get critiques of the code on whatever basis people feel
> inclined to comment!  You can't limit the comments to some particular
> context.
> 
>> It seems to have the key functionality of std::deque and
>> does it much more simply while saving time and space.
> 
> It does not have any of the functionality of std::deque.  

That is a ridiculously stupid thing to say. It has the key most 
important functionality of a std:deque

Double ended queue
deque (usually pronounced like "deck") is an irregular acronym of 
double-ended queue. Double-ended queues are sequence containers with 
dynamic sizes that can be expanded or contracted on both ends (either 
its front or its back).

All of the rest of the functionality of std::deque can be added as needed.

> There is a
> commonly used (though not particularly efficient) way to implement a
> deque using two arrays, but this is not it.
> 
>> #define tape_element unsigned char
> 
> Use a typedef or using declaration.  Also, I'd put the typedef in the
> class as the type belongs to the class (as least that appears to be the
> case from the name you've chosen).
> 
>> class Tape_Type
>> {
>> private:
>>    int Tape_Head = 0;               // Can be negative
>>    std::vector<tape_element> Left;  // Stores left expansion
>>    std::vector<tape_element> Right; // Stores right expansion
>>    tape_element & operator[](int index);
>>
>> public:
>>    void move_left();      // Tape_Head--; Left.push_back(0); as needed
>>    void move_right();     // Tape_Head++; Left.push_back(0); as needed
> 
> The comments are wrong since you push_back('_').
> 
>>    void Write(tape_element Y){ this->operator[](Tape_Head) = Y; };
>>    tape_element Read()       { return this->operator[](Tape_Head); };
> 
> I'd write (*this)[Tape_Head] but I suppose that's just a matter of style.
> 
>>    Tape_Type(){ Right.push_back('_'); } // constructor
> 
> The constructor leaves a Tape_Type object in an unusable state, but
> that's due to a bug in operator[].  Did you test?
> 

Yes I tested so I don't see what you mean.

>>    void Output();
>> };
>>
>> tape_element& Tape_Type::operator[](int index)
>> {
>>    if (index > 0)
>>      return Right[index];
> 
> Bug.  You meant index >= 0 I think.

Yes Richard caught that. That was a new refactoring.

> 
>>    int Left_Index = ((index * -1) -1);
> 
> Why not -index - 1?
> 
>>    return Left[Left_Index];
> 
> Do you think introducing a new variable really make the code clearer
> that simply writing
> 
>    return Left[-index - 1];
> 
> ?  Personally, I'd write the whole thing as
> 
>    return index >= 0 ? Right[index] : Left[-index - 1];
> 
>> }
>>
>> void Tape_Type::Output()
>> {
>>    printf("Tape_Type::Output()\n");
>>
>>    if (Left.size())
>>    {
>>      int Last_One = Left.size() - 1;
>>      for (int N = Last_One; N >= 0; N--)
>>      {
>>        int TH = (N + 1) * -1; // determine Tape_Head from N
>>        printf("[%04d]:%c   Left[%02d]\n", TH, Left[N], N);
>>      }
>>    }
>>    if (Right.size())
>>      for (int N = 0; N < Right.size(); N++)
>>        printf("[%04d]:%c  Right[%02d]\n", N, Right[N], N);
>> }
>>
>> void Tape_Type::move_left()
>> {
>>    Tape_Head--;
>>    int Left_Index = ((Tape_Head * -1) -1);
>>    if (Left_Index == Left.size())
>>      Left.push_back('_');
>> }
>>
>> void Tape_Type::move_right()
>> {
>>    Tape_Head++;
>>    if (Tape_Head == Right.size())
>>      Right.push_back('_');
>> }
> 
> I find the capitalisation odd and unhelpful as there does not seem to be
> any consistency about it.
> 

I found all of your suggestions very helpful.
I don't see the bug in the constructor.
I like mixed case because it is easier to read, mine not be consistent.

Here they are implemented.

//
// Tape_Type implements a two-way Turing machine tape.
// Right contains Tape_Head >= 0 values (right expansion)
// Left  contains Tape_Head  < 0 values (left  expansion)
//
// Tape_Type has functionality very similar to std::deque
// yet implements this functionality much more simply.
// This saves time and space.
//
class Tape_Type
{
typedef unsigned char tape_element;
private:
   int Tape_Head = 0;               // Can be negative
   std::vector<tape_element> Left;  // Stores left expansion
   std::vector<tape_element> Right; // Stores right expansion

   tape_element& operator[](int index)
   {
     return index >= 0 ? Right[index] : Left[-index - 1];
   }

public:
   Tape_Type(){ Right.push_back('_'); } // constructor
   void Write(tape_element Y){ (*this)[Tape_Head] = Y; };
   tape_element Read()       { return (*this)[Tape_Head]; };

   void move_left()
   {
     Tape_Head--;
     int Left_Index = ((Tape_Head * -1) -1);
     if (Left_Index == Left.size())
       Left.push_back('_');
   }

   void move_right()
   {
     Tape_Head++;
     if (Tape_Head == Right.size())
       Right.push_back('_');
   }

   void Output()
   {
     printf("Tape_Type::Output()\n");
     if (Left.size())
     {
       int Last_One = Left.size() - 1;
       for (int N = Last_One; N >= 0; N--)
       {
         int TH = (N + 1) * -1; // determine Tape_Head from N
         printf("[%04d]:%c   Left[%02d]\n", TH, Left[N], N);
       }
     }
     if (Right.size())
       for (int N = 0; N < Right.size(); N++)
         printf("[%04d]:%c  Right[%02d]\n", N, Right[N], N);
   }
};




-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

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


#84059

FromMr Flibble <flibble@reddwarf.jmc>
Date2022-05-13 02:01 +0100
Message-ID<20220513020134.00003f42@reddwarf.jmc>
In reply to#84057
On Thu, 12 May 2022 19:55:44 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/12/2022 7:06 PM, Ben wrote:
> > olcott <NoOne@NoWhere.com> writes:
> > 
> > I've removed the philosophy group and comp.lang.c as this is C++.
> > 
> >> C/C++ people please critique this as the basis for an improvement
> >> to std::deque.
> > 
> > You will get critiques of the code on whatever basis people feel
> > inclined to comment!  You can't limit the comments to some
> > particular context.
> > 
> >> It seems to have the key functionality of std::deque and
> >> does it much more simply while saving time and space.
> > 
> > It does not have any of the functionality of std::deque.  
> 
> That is a ridiculously stupid thing to say. It has the key most 
> important functionality of a std:deque
> 
> Double ended queue
> deque (usually pronounced like "deck") is an irregular acronym of 
> double-ended queue. Double-ended queues are sequence containers with 
> dynamic sizes that can be expanded or contracted on both ends (either 
> its front or its back).
> 
> All of the rest of the functionality of std::deque can be added as
> needed.

Not with your chosen data structure of two std::vectors it can't as it
wouldn't meet the complexity and referential integrity
requirements offered by std::deque. I have told you this three times
now.

/Flibble

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


#84061

Fromolcott <NoOne@NoWhere.com>
Date2022-05-12 20:36 -0500
Message-ID<D7WdnSvo4syeK-D_nZ2dnUU7_81g4p2d@giganews.com>
In reply to#84059
On 5/12/2022 8:01 PM, Mr Flibble wrote:
> On Thu, 12 May 2022 19:55:44 -0500
> olcott <NoOne@NoWhere.com> wrote:
> 
>> On 5/12/2022 7:06 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>> I've removed the philosophy group and comp.lang.c as this is C++.
>>>
>>>> C/C++ people please critique this as the basis for an improvement
>>>> to std::deque.
>>>
>>> You will get critiques of the code on whatever basis people feel
>>> inclined to comment!  You can't limit the comments to some
>>> particular context.
>>>
>>>> It seems to have the key functionality of std::deque and
>>>> does it much more simply while saving time and space.
>>>
>>> It does not have any of the functionality of std::deque.
>>
>> That is a ridiculously stupid thing to say. It has the key most
>> important functionality of a std:deque
>>
>> Double ended queue
>> deque (usually pronounced like "deck") is an irregular acronym of
>> double-ended queue. Double-ended queues are sequence containers with
>> dynamic sizes that can be expanded or contracted on both ends (either
>> its front or its back).
>>
>> All of the rest of the functionality of std::deque can be added as
>> needed.
> 
> Not with your chosen data structure of two std::vectors it can't as it
> wouldn't meet the complexity 

It already has the same complexity.

> and referential integrity

and better referential integrity.

> requirements offered by std::deque. I have told you this three times
> now.
> 
> /Flibble
> 


-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

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


#84067

FromMr Flibble <flibble@reddwarf.jmc>
Date2022-05-13 08:04 +0100
Message-ID<20220513080435.00002bdc@reddwarf.jmc>
In reply to#84061
On Thu, 12 May 2022 20:36:02 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/12/2022 8:01 PM, Mr Flibble wrote:
> > On Thu, 12 May 2022 19:55:44 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >   
> >> On 5/12/2022 7:06 PM, Ben wrote:  
> >>> olcott <NoOne@NoWhere.com> writes:
> >>>
> >>> I've removed the philosophy group and comp.lang.c as this is C++.
> >>>  
> >>>> C/C++ people please critique this as the basis for an improvement
> >>>> to std::deque.  
> >>>
> >>> You will get critiques of the code on whatever basis people feel
> >>> inclined to comment!  You can't limit the comments to some
> >>> particular context.
> >>>  
> >>>> It seems to have the key functionality of std::deque and
> >>>> does it much more simply while saving time and space.  
> >>>
> >>> It does not have any of the functionality of std::deque.  
> >>
> >> That is a ridiculously stupid thing to say. It has the key most
> >> important functionality of a std:deque
> >>
> >> Double ended queue
> >> deque (usually pronounced like "deck") is an irregular acronym of
> >> double-ended queue. Double-ended queues are sequence containers
> >> with dynamic sizes that can be expanded or contracted on both ends
> >> (either its front or its back).
> >>
> >> All of the rest of the functionality of std::deque can be added as
> >> needed.  
> > 
> > Not with your chosen data structure of two std::vectors it can't as
> > it wouldn't meet the complexity   
> 
> It already has the same complexity.
> 
> > and referential integrity  
> 
> and better referential integrity.

You are a fucking obtuse idiot, mate.

/Flibble

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


#84080

Fromolcott <NoOne@NoWhere.com>
Date2022-05-13 11:00 -0500
Message-ID<zdmdnVntirsfHeP_nZ2dnUU7_8zNnZ2d@giganews.com>
In reply to#84067
On 5/13/2022 2:04 AM, Mr Flibble wrote:
> On Thu, 12 May 2022 20:36:02 -0500
> olcott <NoOne@NoWhere.com> wrote:
> 
>> On 5/12/2022 8:01 PM, Mr Flibble wrote:
>>> On Thu, 12 May 2022 19:55:44 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>    
>>>> On 5/12/2022 7:06 PM, Ben wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>> I've removed the philosophy group and comp.lang.c as this is C++.
>>>>>   
>>>>>> C/C++ people please critique this as the basis for an improvement
>>>>>> to std::deque.
>>>>>
>>>>> You will get critiques of the code on whatever basis people feel
>>>>> inclined to comment!  You can't limit the comments to some
>>>>> particular context.
>>>>>   
>>>>>> It seems to have the key functionality of std::deque and
>>>>>> does it much more simply while saving time and space.
>>>>>
>>>>> It does not have any of the functionality of std::deque.
>>>>
>>>> That is a ridiculously stupid thing to say. It has the key most
>>>> important functionality of a std:deque
>>>>
>>>> Double ended queue
>>>> deque (usually pronounced like "deck") is an irregular acronym of
>>>> double-ended queue. Double-ended queues are sequence containers
>>>> with dynamic sizes that can be expanded or contracted on both ends
>>>> (either its front or its back).
>>>>
>>>> All of the rest of the functionality of std::deque can be added as
>>>> needed.
>>>
>>> Not with your chosen data structure of two std::vectors it can't as
>>> it wouldn't meet the complexity
>>
>> It already has the same complexity.
>>
>>> and referential integrity
>>
>> and better referential integrity.
> 
> You are a fucking obtuse idiot, mate.
> 
> /Flibble
> 

Prove that it doesn't.

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

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


#84082

FromMr Flibble <flibble@reddwarf.jmc>
Date2022-05-13 17:04 +0100
Message-ID<20220513170449.0000502d@reddwarf.jmc>
In reply to#84080
On Fri, 13 May 2022 11:00:01 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/13/2022 2:04 AM, Mr Flibble wrote:
> > On Thu, 12 May 2022 20:36:02 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >   
> >> On 5/12/2022 8:01 PM, Mr Flibble wrote:  
> >>> On Thu, 12 May 2022 19:55:44 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>      
> >>>> On 5/12/2022 7:06 PM, Ben wrote:  
> >>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>
> >>>>> I've removed the philosophy group and comp.lang.c as this is
> >>>>> C++. 
> >>>>>> C/C++ people please critique this as the basis for an
> >>>>>> improvement to std::deque.  
> >>>>>
> >>>>> You will get critiques of the code on whatever basis people feel
> >>>>> inclined to comment!  You can't limit the comments to some
> >>>>> particular context.
> >>>>>     
> >>>>>> It seems to have the key functionality of std::deque and
> >>>>>> does it much more simply while saving time and space.  
> >>>>>
> >>>>> It does not have any of the functionality of std::deque.  
> >>>>
> >>>> That is a ridiculously stupid thing to say. It has the key most
> >>>> important functionality of a std:deque
> >>>>
> >>>> Double ended queue
> >>>> deque (usually pronounced like "deck") is an irregular acronym of
> >>>> double-ended queue. Double-ended queues are sequence containers
> >>>> with dynamic sizes that can be expanded or contracted on both
> >>>> ends (either its front or its back).
> >>>>
> >>>> All of the rest of the functionality of std::deque can be added
> >>>> as needed.  
> >>>
> >>> Not with your chosen data structure of two std::vectors it can't
> >>> as it wouldn't meet the complexity  
> >>
> >> It already has the same complexity.
> >>  
> >>> and referential integrity  
> >>
> >> and better referential integrity.  
> > 
> > You are a fucking obtuse idiot, mate.
> > 
> > /Flibble
> >   
> 
> Prove that it doesn't.
 
Prove to me that you are not an idiot by explaining what happens if
vector Left is empty, vector Right is non-empty and you call pop_front?
Hint: as your design currently stands it will crash.

/Flibble

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


#84086

Fromolcott <NoOne@NoWhere.com>
Date2022-05-13 12:05 -0500
Message-ID<44CdnU0P0pZTEuP_nZ2dnUU7_81g4p2d@giganews.com>
In reply to#84082
On 5/13/2022 11:04 AM, Mr Flibble wrote:
> On Fri, 13 May 2022 11:00:01 -0500
> olcott <NoOne@NoWhere.com> wrote:
> 
>> On 5/13/2022 2:04 AM, Mr Flibble wrote:
>>> On Thu, 12 May 2022 20:36:02 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>    
>>>> On 5/12/2022 8:01 PM, Mr Flibble wrote:
>>>>> On Thu, 12 May 2022 19:55:44 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>       
>>>>>> On 5/12/2022 7:06 PM, Ben wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>> I've removed the philosophy group and comp.lang.c as this is
>>>>>>> C++.
>>>>>>>> C/C++ people please critique this as the basis for an
>>>>>>>> improvement to std::deque.
>>>>>>>
>>>>>>> You will get critiques of the code on whatever basis people feel
>>>>>>> inclined to comment!  You can't limit the comments to some
>>>>>>> particular context.
>>>>>>>      
>>>>>>>> It seems to have the key functionality of std::deque and
>>>>>>>> does it much more simply while saving time and space.
>>>>>>>
>>>>>>> It does not have any of the functionality of std::deque.
>>>>>>
>>>>>> That is a ridiculously stupid thing to say. It has the key most
>>>>>> important functionality of a std:deque
>>>>>>
>>>>>> Double ended queue
>>>>>> deque (usually pronounced like "deck") is an irregular acronym of
>>>>>> double-ended queue. Double-ended queues are sequence containers
>>>>>> with dynamic sizes that can be expanded or contracted on both
>>>>>> ends (either its front or its back).
>>>>>>
>>>>>> All of the rest of the functionality of std::deque can be added
>>>>>> as needed.
>>>>>
>>>>> Not with your chosen data structure of two std::vectors it can't
>>>>> as it wouldn't meet the complexity
>>>>
>>>> It already has the same complexity.
>>>>   
>>>>> and referential integrity
>>>>
>>>> and better referential integrity.
>>>
>>> You are a fucking obtuse idiot, mate.
>>>
>>> /Flibble
>>>    
>>
>> Prove that it doesn't.
>   
> Prove to me that you are not an idiot by explaining what happens if
> vector Left is empty, vector Right is non-empty and you call pop_front?
> Hint: as your design currently stands it will crash.
> 
> /Flibble
> 

Simply extend the definition of the member function.
Maybe std::deque performs better at this?

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

[toc] | [prev] | [standalone]


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

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


csiph-web