473,418 Members | 1,767 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,418 software developers and data experts.

Whether the following program implement the factory Design

Does this following program implement the factory design.if not what
are things that i have to change in order to make this following
program to be designed to factory design pattern.

#include<iostream>
using namespace std;

class Quad
{
public:
void Area();
void Desc();
};

class Square : public Quad
{
public:
Square() {};

void Area(int x)
{
cout<<"Area of square is = "<<x*x<<endl;
}

void Desc()
{
cout<<"This Derived class Square from Base Class Quad"<<endl;
}
};

class Rectangle : public Quad
{
public:
Rectangle() {};

void Area(int x, int y)
{
cout<<"Area of Rectangle is = "<<x*y<<endl;
}

void Desc()
{
cout<<"This Derived class Rectangle from Base Class Quad"<<endl;
}

};

class Creator
{
public:
Quad* Creator::Create(int id)
{
if (id==2)
return new Square;
else
return new Rectangle;
}
};

int main(int argc, char* argv[])
{
Creator mcreator;
if (argc<=2)
{
Square *square = reinterpret_cast<Square*>(mcreator.Create(2));
square->Area(3);
square->Desc();
}
else
{
Rectangle *rectangle =
reinterpret_cast<Rectangle*>(mcreator.Create(1));
rectangle->Area(3,4);
rectangle->Desc();
}

return 0;
}
Dec 7 '06 #1
10 2317
sunny a écrit :
Does this following program implement the factory design.if not what
are things that i have to change in order to make this following
program to be designed to factory design pattern.

#include<iostream>
>using namespace std;

class Quad
{
public:
void Area();
void Desc();
};

class Square : public Quad
{
public:
Square() {};

void Area(int x)
{
cout<<"Area of square is = "<<x*x<<endl;
}

void Desc()
{
cout<<"This Derived class Square from Base Class Quad"<<endl;
}
};

class Rectangle : public Quad
{
public:
Rectangle() {};

void Area(int x, int y)
{
cout<<"Area of Rectangle is = "<<x*y<<endl;
}

void Desc()
{
cout<<"This Derived class Rectangle from Base Class Quad"<<endl;
}

};

class Creator
{
public:
Quad* Creator::Create(int id)
{
if (id==2)
return new Square;
else
return new Rectangle;
}
};

int main(int argc, char* argv[])
{
Creator mcreator;
if (argc<=2)
{
Square *square = reinterpret_cast<Square*>(mcreator.Create(2));
square->Area(3);
square->Desc();
}
else
{
Rectangle *rectangle =
reinterpret_cast<Rectangle*>(mcreator.Create(1) );
rectangle->Area(3,4);
rectangle->Desc();
}

return 0;
}


Are you thinking of
- "Abstract" Factory design
http://en.wikipedia.org/wiki/Abstract_factory_pattern
or
- Factory "method" design
http://en.wikipedia.org/wiki/Factory_method_pattern
Which seems more likely from your code
1. Make Quad::Area and Quad::Desc virutal
2. If you want to prevent creation of Square and Retangle
outside the factory, make their constructor protected and declare
Creator as a friend class
3. Consider using enum as parameter of Creator::Create and
perhaps make it static

Michael
Dec 7 '06 #2

Michael DOUBEZ wrote:
sunny a écrit :
Does this following program implement the factory design.if not what
are things that i have to change in order to make this following
program to be designed to factory design pattern.

#include<iostream>
using namespace std;

class Quad
{
public:
void Area();
void Desc();
};

class Square : public Quad
{
public:
Square() {};

void Area(int x)
{
cout<<"Area of square is = "<<x*x<<endl;
}

void Desc()
{
cout<<"This Derived class Square from Base Class Quad"<<endl;
}
};

class Rectangle : public Quad
{
public:
Rectangle() {};

void Area(int x, int y)
{
cout<<"Area of Rectangle is = "<<x*y<<endl;
}

void Desc()
{
cout<<"This Derived class Rectangle from Base Class Quad"<<endl;
}

};

class Creator
{
public:
Quad* Creator::Create(int id)
{
if (id==2)
return new Square;
else
return new Rectangle;
}
};

int main(int argc, char* argv[])
{
Creator mcreator;
if (argc<=2)
{
Square *square = reinterpret_cast<Square*>(mcreator.Create(2));
square->Area(3);
square->Desc();
}
else
{
Rectangle *rectangle =
reinterpret_cast<Rectangle*>(mcreator.Create(1));
rectangle->Area(3,4);
rectangle->Desc();
}

return 0;
}

Are you thinking of
- "Abstract" Factory design
http://en.wikipedia.org/wiki/Abstract_factory_pattern
or
- Factory "method" design
http://en.wikipedia.org/wiki/Factory_method_pattern
Which seems more likely from your code
1. Make Quad::Area and Quad::Desc virutal
once you make this virtual you can remvoe reintrepret cast . then this
desing will be factory pattern and your factory method is Creator .
2. If you want to prevent creation of Square and Retangle
outside the factory, make their constructor protected and declare
Creator as a friend class
3. Consider using enum as parameter of Creator::Create and
perhaps make it static

Michael
Dec 7 '06 #3

sunny wrote:
Does this following program implement the factory design.if not what
are things that i have to change in order to make this following
program to be designed to factory design pattern.

#include<iostream>
using namespace std;

class Quad
{
public:
void Area();
void Desc();
};

class Square : public Quad
{
public:
Square() {};

void Area(int x)
{
cout<<"Area of square is = "<<x*x<<endl;
}

void Desc()
{
cout<<"This Derived class Square from Base Class Quad"<<endl;
}
};

class Rectangle : public Quad
{
public:
Rectangle() {};

void Area(int x, int y)
{
cout<<"Area of Rectangle is = "<<x*y<<endl;
}

void Desc()
{
cout<<"This Derived class Rectangle from Base Class Quad"<<endl;
}

};

class Creator
{
public:
Quad* Creator::Create(int id)
{
if (id==2)
return new Square;
else
return new Rectangle;
}
};

int main(int argc, char* argv[])
{
Creator mcreator;
if (argc<=2)
{
Square *square = reinterpret_cast<Square*>(mcreator.Create(2));
Don't use reinterpret_cast in cases like this. Use dynamic_cast or
static_cast if you are conserned about speed. Possibly better use
boost::polymorphic_downcast.

I don't know for certain if your use of reinterpret_cast in this
particular case creates undefined behavior but minor changes to the
objects in questions (introducing MI for instance) definately will.
The whole point of a factory is to hide this kind of detail.
square->Area(3);
square->Desc();
}
else
{
Rectangle *rectangle =
reinterpret_cast<Rectangle*>(mcreator.Create(1));
rectangle->Area(3,4);
rectangle->Desc();
}
Objects created by a factory shouldn't need to be cast like this. If
you are casting down from creation of the object then the factory is
pointless. Yes, creator is a factory but the objects it is creating
are not polymorphic so it makes no sense. That is the reasoning behind
the other answers you got.

Dec 7 '06 #4
sunny wrote:
Does this following program implement the factory design.if not what
are things that i have to change in order to make this following
program to be designed to factory design pattern.

#include<iostream>
using namespace std;

class Quad
{
public:
void Area();
void Desc();
};

class Square : public Quad
{
public:
Square() {};

void Area(int x)
{
cout<<"Area of square is = "<<x*x<<endl;
}

void Desc()
{
cout<<"This Derived class Square from Base Class Quad"<<endl;
}
};

class Rectangle : public Quad
{
public:
Rectangle() {};

void Area(int x, int y)
{
cout<<"Area of Rectangle is = "<<x*y<<endl;
}

void Desc()
{
cout<<"This Derived class Rectangle from Base Class Quad"<<endl;
}

};

class Creator
{
public:
Quad* Creator::Create(int id)
{
if (id==2)
return new Square;
else
return new Rectangle;
}
};

int main(int argc, char* argv[])
{
Creator mcreator;
if (argc<=2)
{
Square *square = reinterpret_cast<Square*>(mcreator.Create(2));
square->Area(3);
square->Desc();
}
else
{
Rectangle *rectangle =
reinterpret_cast<Rectangle*>(mcreator.Create(1));
rectangle->Area(3,4);
rectangle->Desc();
}

return 0;
}
Factory design patterns can be a pain to work with, specially when
their allocations are leaked / ignored. I have no respect for any code
that uses reinterpret_cast flagrantly (and in many cases - the same
goes for dynamic_cast).

Here is one based on boost::shared_ptr with Shape having protected
ctors, disabled copy-ctors and a factory friend. Note: STL container is
*not* copying Shapes here.
A Square is_a Rectangle
Factory has a create() that produces the shape required via specified
template parameter.

#include <iostream>
#include <ostream>
#include <vector>
#include <boost/shared_ptr.hpp>

struct Shape
{
Shape() { }
Shape(const Shape& copy); // disabled
virtual ~Shape() = 0;
virtual double area() const = 0;
virtual void description() const = 0;
};

Shape::~Shape() { std::cout << "~Shape()\n"; }

class Rectangle : public Shape
{
double width, height;
friend class ShapeFactory;
protected:
Rectangle(double w, double h)
: width(w), height(h)
{
std::cout << "Rectangle()\n";
}
public:
~Rectangle()
{
std::cout << "~Rectangle()\n";
}
double area() const { return width * height; }
void description() const
{
std::cout << "Rectangle with area = ";
std::cout << area() << std::endl;
}
};

class Square : public Rectangle
{
friend class ShapeFactory;
protected:
Square(double w, double dummy)
: Rectangle(w, w)
{
std::cout << "Square()\n";
}
public:
~Square()
{
std::cout << "~Square()\n";
}
double area() const { return Rectangle::area(); }
void description() const
{
std::cout << "Square with area = ";
std::cout << area() << std::endl;
}
};

class Triangle : public Shape
{
double width, height;
friend class ShapeFactory;
protected:
Triangle(double w, double h)
: width(w), height(h)
{
std::cout << "Triangle()\n";
}
public:
~Triangle()
{
std::cout << "~Triangle()\n";
}
double area() const { return 0.5 * width * height; }
void description() const
{
std::cout << "Triangle with area = ";
std::cout << area() << std::endl;
}
};

class ShapeFactory
{
public:
template< typename ShapeType >
boost::shared_ptr< ShapeType >
create(const double w = 0.0, const double h = 0.0) const
{
return boost::shared_ptr< ShapeType >(new ShapeType(w, h));
}
};

int main()
{
ShapeFactory factory;

typedef boost::shared_ptr< Shape SP_Shapes;
std::vector< SP_Shapes vshapes;
vshapes.push_back( factory.create< Triangle >(10.1, 10.2) );
vshapes.push_back( factory.create< Rectangle >(4.2, 25.1) );
vshapes.push_back( factory.create< Square >(9.3) );

typedef std::vector< SP_Shapes >::iterator VIter;
for( VIter viter = vshapes.begin();
viter != vshapes.end();
++viter )
{
(*viter)->description();
}

// std::vector< SP_Shapes vshapes2(vshapes); // ok
}

/*
Triangle()
Rectangle()
Rectangle() // <- Square
Square()
Triangle with area = 51.51
Rectangle with area = 105.42
Square with area = 86.49
~Triangle()
~Shape()
~Rectangle()
~Shape()
~Square()
~Rectangle()
~Shape()
*/

Dec 7 '06 #5
Salt_Peter a écrit :
sunny wrote:
>Does this following program implement the factory design.if not what
are things that i have to change in order to make this following
program to be designed to factory design pattern.
A Square is_a Rectangle
From the C++ point of view, saying that "A Square is_a Rectangle" leads
do design problems.

You might even think that a Circle is_an Ellipse ? :)
See http://www.parashift.com/c++-faq-lit...heritance.html
Chapter [21.6] and further chapters on Ellipse/Circle Dilemna.
Dec 7 '06 #6

Michael DOUBEZ wrote:
Salt_Peter a écrit :
sunny wrote:
Does this following program implement the factory design.if not what
are things that i have to change in order to make this following
program to be designed to factory design pattern.
A Square is_a Rectangle

From the C++ point of view, saying that "A Square is_a Rectangle" leads
do design problems.

You might even think that a Circle is_an Ellipse ? :)
See http://www.parashift.com/c++-faq-lit...heritance.html
Chapter [21.6] and further chapters on Ellipse/Circle Dilemna.
We've been through that x times.
A square is a special type of rectangle. Period. Whether that satisfies
the hierarchy depends on the requirements. In this case - its perfectly
valid.
A circle can never be an ellipse because of the mathematical
description involved to explain the two distinct Shapes. An Ellipse
might be described starting from 2 circles (has_a relationship). etc.

The 2 relationships are completely unrelated in any way.

Dec 8 '06 #7

Salt_Peter wrote:
Michael DOUBEZ wrote:
Salt_Peter a écrit :
sunny wrote:
>Does this following program implement the factory design.if not what
>are things that i have to change in order to make this following
>program to be designed to factory design pattern.
A Square is_a Rectangle
From the C++ point of view, saying that "A Square is_a Rectangle" leads
do design problems.

You might even think that a Circle is_an Ellipse ? :)
See http://www.parashift.com/c++-faq-lit...heritance.html
Chapter [21.6] and further chapters on Ellipse/Circle Dilemna.

We've been through that x times.
A square is a special type of rectangle. Period. Whether that satisfies
the hierarchy depends on the requirements. In this case - its perfectly
valid.
Actually, what you have done is shown that is_a means two different
things when talking about real life and when talking about code. Yes,
mathematically a square is defined as a rectangle with all sides equal.
However, a square as a subclass of rectangle is inappropriate for the
simple reason that a square cannot respond to a rectangle's interface
and retain the properties inherent to a square.

Now, you can retain the mathematical purity by having one class,
rectangle, for which a rectangle that happens to have all sides equal
can occur and such rectangles would be squares. What you can't have,
without running afoul of major problems caused by poor design, is an
object that "is a rectangle" but enforces the constraints of a square.

To illustrate:

Rectangle * r = new Square(5);
....
r->SetWidth(3);
r->SetHeight(10);
assert(r->Width() == 3 && r->Height() == 10);
Having a square be a rectangle violates the LSP in that it doesn't
adhere to the post conditions of rectangle operations. It may be ok to
do in initial designs where you say, "But I'll never use a square
interchangeably with a rectangle in that manner," but eventually you
almost always do.

Dec 8 '06 #8

Noah Roberts wrote:
Salt_Peter wrote:
Michael DOUBEZ wrote:
Salt_Peter a écrit :
sunny wrote:
Does this following program implement the factory design.if not what
are things that i have to change in order to make this following
program to be designed to factory design pattern.
A Square is_a Rectangle
>
From the C++ point of view, saying that "A Square is_a Rectangle" leads
do design problems.
>
You might even think that a Circle is_an Ellipse ? :)
See http://www.parashift.com/c++-faq-lit...heritance.html
Chapter [21.6] and further chapters on Ellipse/Circle Dilemna.
We've been through that x times.
A square is a special type of rectangle. Period. Whether that satisfies
the hierarchy depends on the requirements. In this case - its perfectly
valid.

Actually, what you have done is shown that is_a means two different
things when talking about real life and when talking about code. Yes,
mathematically a square is defined as a rectangle with all sides equal.
However, a square as a subclass of rectangle is inappropriate for the
simple reason that a square cannot respond to a rectangle's interface
and retain the properties inherent to a square.

Now, you can retain the mathematical purity by having one class,
rectangle, for which a rectangle that happens to have all sides equal
can occur and such rectangles would be squares. What you can't have,
without running afoul of major problems caused by poor design, is an
object that "is a rectangle" but enforces the constraints of a square.

To illustrate:

Rectangle * r = new Square(5);
...
r->SetWidth(3);
r->SetHeight(10);
assert(r->Width() == 3 && r->Height() == 10);
Says who? Where is it written that i can't overide those 2 setters?
Whats preventing me from specializing the needs of this particular type
of rectangle without having to reconstruct the class from scratch?
So, just for the sake of discussion - let me add a requirement - since
none have been put forth and since that is what this is presumably all
about:

I need to include Squares to store anything that remotely looks or
behaves like a Rectangle, excluding other shapes?
std::vector< Rectangle vrect;

So: how do i do that?
>

Having a square be a rectangle violates the LSP in that it doesn't
adhere to the post conditions of rectangle operations. It may be ok to
do in initial designs where you say, "But I'll never use a square
interchangeably with a rectangle in that manner," but eventually you
almost always do.
Yes, the interface violates design by object in its pure sense. That
however, that was not given as a requirement here.

Dec 8 '06 #9

Salt_Peter wrote:
Noah Roberts wrote:
To illustrate:

Rectangle * r = new Square(5);
...
r->SetWidth(3);
r->SetHeight(10);
assert(r->Width() == 3 && r->Height() == 10);

Says who?
Says Rectangle. If I call SetWidth on a rectangle then the width I get
from that rectangle must certainly be the width I set and not some
other value....same as with height. These are perfectly logical
assumptions to make. If I can't make these assumptions then the
Rectangle interface is useless.
Where is it written that i can't overide those 2 setters?
You can. And you can do so in a way that breaks the rectangle
interface. As such, your subclass is no longer an "is_a" but an
"almost_a". Public inheritence should /always/ be "is a".
Whats preventing me from specializing the needs of this particular type
of rectangle without having to reconstruct the class from scratch?
"Is a" is another way of wording the LSP, which states that a function
that operates on type T must be able to work with any subclass of type
T interchangeably through the T interface (it's actually worded very
differently but that is the essense). A square being a subclass of
rectangle breaks this because a square does not meet the post
conditions of the interface of a rectangle and functions that operate
on a rectangle and expect rectangle behavior might be broken when
called with a square as a parameter.
So, just for the sake of discussion - let me add a requirement - since
none have been put forth and since that is what this is presumably all
about:

I need to include Squares to store anything that remotely looks or
behaves like a Rectangle, excluding other shapes?
std::vector< Rectangle vrect;
You can't. First of all because all the elements of your vector are
Rectangles. However, even if you created your vector with pointers
instead (allowing the inclusion of base class instances in their
entirety) you still have the problem that functions that work with that
vector can't depend on the objects in it obeying the interface of
rectangle. This is why it simply doesn't work. For your highly
constrained example you would need to add a level of indirection by
creating a wrapper class that would only expose an interface that makes
sense for both rectangle and square but could contain either.
Depending on the situation the pre/post conditions of operations would
be loosened or tightened in order that both objects could be
interchanged and meet the requirements of clients.
>
So: how do i do that?
Through a third interface and composition.
>


Having a square be a rectangle violates the LSP in that it doesn't
adhere to the post conditions of rectangle operations. It may be ok to
do in initial designs where you say, "But I'll never use a square
interchangeably with a rectangle in that manner," but eventually you
almost always do.

Yes, the interface violates design by object in its pure sense. That
however, that was not given as a requirement here.
Since when is attempting to use sound principles and practices NOT
given as a requirement?? IMHO it always is unless otherwise stated.
If you desire to write rigid and fragile code then yes, there is no
need to worry about such mundain details.

The square/rectangle inheritance problem is a simple example of a much
larger and commonly seen design problem. It may seem meaningless or
petty to harp on square and rectangle but the inheritance problems it
illustrates are seen quite often in code and the fragility they
introduce can make life very difficult and the product nearly
impossible to maintain.

Dec 8 '06 #10
Salt_Peter a écrit :
Noah Roberts wrote:
>Salt_Peter wrote:
>>Michael DOUBEZ wrote:
Salt_Peter a écrit :
sunny wrote:
>Does this following program implement the factory design.if not what
>are things that i have to change in order to make this following
>program to be designed to factory design pattern.
A Square is_a Rectangle
From the C++ point of view, saying that "A Square is_a Rectangle" leads
do design problems.

You might even think that a Circle is_an Ellipse ? :)
See http://www.parashift.com/c++-faq-lit...heritance.html
Chapter [21.6] and further chapters on Ellipse/Circle Dilemna.
We've been through that x times.
A square is a special type of rectangle. Period. Whether that satisfies
the hierarchy depends on the requirements. In this case - its perfectly
valid.
Nobody try to tell you how to code your program: if you want to
specialize the class Rectangle into Square, that's fine for me. But it
can lead to design problem nonetheless and not take this inheritance as
a rule without further understanding.

In this particular example, it doesn't violate object design but the
inheritance also doesn't serve any purpose. Unless there was a point I
didn't see to make SQuare inherit from Rectangle ?

>Actually, what you have done is shown that is_a means two different
things when talking about real life and when talking about code. Yes,
mathematically a square is defined as a rectangle with all sides equal.
However, a square as a subclass of rectangle is inappropriate for the
simple reason that a square cannot respond to a rectangle's interface
and retain the properties inherent to a square.

Now, you can retain the mathematical purity by having one class,
rectangle, for which a rectangle that happens to have all sides equal
can occur and such rectangles would be squares. What you can't have,
without running afoul of major problems caused by poor design, is an
object that "is a rectangle" but enforces the constraints of a square.

To illustrate:

Rectangle * r = new Square(5);
...
r->SetWidth(3);
r->SetHeight(10);
assert(r->Width() == 3 && r->Height() == 10);

Says who? Where is it written that i can't overide those 2 setters?
Whats preventing me from specializing the needs of this particular type
of rectangle without having to reconstruct the class from scratch?
You can do anything you want with your code within what C++ allow but it
is a personnal decision and other readers should be aware of the pros
and cons.
So, just for the sake of discussion - let me add a requirement - since
none have been put forth and since that is what this is presumably all
about:

I need to include Squares to store anything that remotely looks or
behaves like a Rectangle, excluding other shapes?
std::vector< Rectangle vrect;

So: how do i do that?
You put what you need to do generically in a virtual class
(BehaveLikeRectangle) inherited by Square and Rectangle.
>>
Having a square be a rectangle violates the LSP in that it doesn't
adhere to the post conditions of rectangle operations. It may be ok to
do in initial designs where you say, "But I'll never use a square
interchangeably with a rectangle in that manner," but eventually you
almost always do.

Yes, the interface violates design by object in its pure sense. That
however, that was not given as a requirement here.
The inheritance between Square and Rectangle was neither required in the
original post.
Dec 8 '06 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

14
by: lawrence | last post by:
To call I would do something like: $headline = McSelectJustOneField::callDatastore("cbHeadline"); Is this the correct use of the static keyword, to implement a Singleton design?
14
by: Medi Montaseri | last post by:
Hi, I think my problem is indeed "how to implement something like java's final in C++" The long version.... I have an abstract base class which is inherited by several concrete classes. I...
4
by: max | last post by:
Hello, I analyze this design pattern for a long time but I do not understand how this pattern work and what the purpose is? (I looked a this site...
11
by: FluffyCat | last post by:
In Febraury - April of 2002 I put together in Java examples of all 23 of the classic "Gang Of Four" design patterns for my website. Partly I wanted to get a better understanding of those patterns....
8
by: deko | last post by:
Which layer should a Factory class go in? DA - Data Access BL - Business Logic UI - User Interface ??
0
by: ma740988 | last post by:
I'm going through modern C++ design looking for tips and while hi-tech I suspect one solution to my issue would involve the factory design pattern. // algorithms.h class Algorithms {...
1
by: orel | last post by:
Please, As i tried hundreds different implementation to make it work and actually didn't succeed, can someone here help me to understand and use the implementation of the Object Factory design...
0
by: sunny | last post by:
Does this following program implement the factory design.if not what are things that i have to change in order to make this following program to be designed to factory design pattern. ...
4
by: Pallav singh | last post by:
Hi , when should i select Factory Method / Prototype Design Pattern during my design phase ?? as both look similar to me Thanks in Advance Thanks Pallav
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.