Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

what are type fields [closed]

Tags:

c++

I have learned that
type fields is an error-prone technique somewhere

I have Google it much but no satisfactory results .Although I know the meaning of type and fields individually . I am thinking that type field means field of a particular type like

class marks;
class test {
marks number;
bool pass;
}

Here according to me type field is number and pass . If this is right how is composition different from it? Also what is type field technique?? How it is error prone??

Please give it true meaning. Also give an example to show its evil nature and what are its substitutes ??

like image 788
T.J. Avatar asked Feb 05 '12 05:02

T.J.


People also ask

What does it mean for a field to be closed?

The field has no proper finite extension The field F is algebraically closed if and only if it has no proper finite extension because if, within the previous proof, the term "algebraic extension" is replaced by the term "finite extension", then the proof is still valid.

What does field mean in C++?

You're almost certainly referring to type fields as discussed in the book The C++ Programming Language by Bjarne Stroustrup. A type field in this context would simply be a variable of some kind in a base class that indicates the actual type of its subclasses.

What is a field in a class?

A field is a variable of any type that is declared directly in a class or struct. Fields are members of their containing type. A class or struct may have instance fields, static fields, or both.

Are there finite algebraically closed fields?

As others have said, there cannot be any finite algebraically closed fields (and if there were, algebraic geometry would be a rather different subject than it is;-). In fact there cannot even be any finite field K over which all quadratic polynomials have roots, by the following simple counting argument.


1 Answers

You're almost certainly referring to type fields as discussed in the book The C++ Programming Language by Bjarne Stroustrup. A type field in this context would simply be a variable of some kind in a base class that indicates the actual type of its subclasses. Here's an example:

class Pet
{
public:
    enum PetType { Dog, Cat, Bird, Fish };

    void ToString()
    {
        switch(type)
        {
        case Pet::Dog: std::cout << "Dog" << std::endl; break;
        case Pet::Cat: std::cout << "Cat" << std::endl; break;
        case Pet::Bird: std::cout << "Bird" << std::endl; break;
        case Pet::Fish: std::cout << "Fish" << std::endl; break;
        }
    }

private:
    PetType type; // A type field.
};

class Dog : public Pet
{
public:
    Dog() { type = Dog; }
};

// And so on...

void Test(const Pet& p) { p.ToString(); }
int main()
{
    Dog d;
    Test(d);
    return 0;
}

This is an extraordinarily brittle way to implement a ToString() method. Every time you need to add a derived class of Pet, you would need to update the PetType enumeration and the ToString() method. For example, if I need a Turtle subclass, I would need to make these changes:

// ...
enum PetType { Dog, Cat, Bird, Fish, Tutle /* Added */};
void ToString(const Pet& p)
{
    switch(p.type)
    {
    case Pet::Dog: std::cout << "Dog" << std::endl; break;
    case Pet::Cat: std::cout << "Cat" << std::endl; break;
    case Pet::Bird: std::cout << "Bird" << std::endl; break;
    case Pet::Fish: std::cout << "Fish" << std::endl; break;
    case Pet::Turtle: std::cout << "Turtle" << std::endl; break; // Added
    }
}
// ...
class Turtle : public Pet
{
public:
    Turtle() { type = Turtle; } // Added
};

Imagine if the Pet class had more functions than just ToString(); maintenence becomes a nightmare. It's lot of code one needs to change, but the important thing is that in order to have a Turtle class, I need to modify the Pet class. That means more testing, code review, etc. is needed. It's a clear violation of the open/closed principle. That's why type fields are extremely error-prone.

A significantly superior way would be to use virtual functions:

class Pet
{
public:
    virtual void ToString() = 0;
};

class Dog : public Pet
{
public:
    virtual void ToString() { std::cout << "Dog" << std::endl; }
};

class Turtle : public Pet
{
public:
    virtual void ToString() { std::cout << "Turtle" << std::endl; }
};

// And so on...

void Test(const Pet& p) { p.ToString(); }
int main()
{
    Turtle t
    // Will call Turtle::ToString(), even though
    // Test() was only given a const Pet&
    Test(t); 
    return 0;
}

Note that the above code requires no extra enums or switch statements. Calling Pet::ToString() will call the correct implementation of ToString() for Dogs, Cats, etc. automatically, with much less code. I don't even need to change the Pet class; I can just drop in a Turtle class if needed, provided that Pet has been defined.


For a possibly legitimate use of type fields, see this Stack Overflow question and the answers to that question.

like image 153
In silico Avatar answered Sep 22 '22 11:09

In silico