This is my c++
#include<iostream>
using namespace std;
int c = 0,cost = 999;
int graph[4][4] = { {0, 10, 15, 20},
{10, 0, 35, 25},
{15, 35, 0, 30},
{20, 25, 30, 0}
};
void swap (int *x, int *y)
{
int temp;
temp = *x;
*x = *y;
*y = temp;
}
void copy_array(int *a, int n)
{
int i, sum = 0;
for(i = 0; i <= n; i++)
{
sum += graph[a[i % 4]][a[(i + 1) % 4]];
}
if (cost > sum)
{
cost = sum;
}
}
void permute(int *a, int i, int n)
{
int j, k;
if (i == n)
{
copy_array(a, n);
}
else
{
for (j = i; j <= n; j++)
{
swap((a + i), (a + j));
permute(a, i + 1, n);
swap((a + i), (a + j));
}
}
}
int main()
{
int i, j;
int a[] = {0, 1, 2, 3};
permute(a, 0, 3);
cout<<"minimum cost:"<<cost<<endl;
getch();
}
What I have tried:
I tried to convert it by creating sub classes within my main class but I just am learning C so bringing it to Java is really troubling me
this is the original question
Assignment 4 - Email, Shwitter and Inheritance
Select one option from below. All (both) options are worth the same number of points. The more advanced option(s) are provided for students who find the basic one too easy and want more of a challenge. Make sure you have read and understood
● both modules A and B this week, and
● module 2R - Lab Homework Requirements
before submitting this assignment.
OPTION A (Basic). Message, EMail and Shweet Understand the Classes and Problem Every message contains some content ("The British are coming. The British are coming!" and a creator, or author ("Paul Revere"). We could enhance these by adding other traits (date and/or time of creation), but let's keep things simple and say that these are the only two aspects of a basic message.
Some messages, however, have further components that define them. For example, an email consists of a normal message, plus at least two other items. a from email address and a to email address. An email is a message, but a special kind of message. So we can smell inheritance in the neighborhood. A message seems like it will make a good base class, and an email, having an is a relationship with message, is a good candidate for a derived class or extension of the base class message.
Meanwhile, a tweet consists of a normal message, plus at least one other item. a from user id. An tweet is a message, too. It has a different kind of specialization than an email has, so it is a different extension of the base class. (We are not considering a direct tweet, which would also require a to user id.)
Not only will both emails and tweets contain extra data than the base class, message, but in at least one instance we will see the same member (the content) have a different kind of restriction in the derived class than in the base class (can you guess what I'm suggesting before you read on?). Thus, even though we store the tweet content in the base class member, without the need for a new content area for the tweet, we will still have a different validation of the length of that message content. Warning. Because it makes sense to do so, we are going to name the message content message and the message class Message . So what I called content in the above paragraph will be known as (lower-case) message in what comes next. The class, itself, will be (upper-case) Message. You'll see. Just keep reading.
File Structure. I prefer one file for the entire program, so you can put all classes together with main() in one file.
The Base Class: Message Your base class is named Message . Public or Protected (your choice) Static Class Constants Define a full set of limits
and defaults
, like MAX_MSG_LENGTH and DEFAULT_AUTHOR, for both min, max lengths and default data of every member. Set the maximum message length to a large number (at least a million) and the maximum author length to a reasonable value like 40 or 65, not 5 or 200.
Private Member Data ● string message; ● string author; Public Methods ● Default and 2-parameter constructors.
● Mutator and Accessor for each member.
● a toString() method that provides a nicely formatted return String for potential screen I/O.
Private Methods ● private static validation helpers to filter client parameters. These will support your public methods.
Recommended test o. Class Message Instantiate two or more Message objects, some using the default constructor and some using the parameter-taking constructor. Mutate one or more of the members, and after that use the toString() to assist a screen output so we can see what all of your objects contain. Next, test one or more accessors. Finally, test two or more mutators, providing both legal and illegal arguments and testing the return values (thus demonstrating that the mutators do the right thing). Here is a sample run from my test (but you will have to imagine/deduce the source I used and create your own source for your testing, which will produce a different output).
Example Test Run of Message Class /* --------------------------------------------------------
Base Class Testing ***********************************
Author: Kinnard Message ---------------------
Some messages just aren't worth sending.
Author: loceff Message ---------------------
hello world
testing Message accessors:
Kinnard
hello world
testing Message mutators:
too long (as expected)
Author: Kinnard Message ---------------------
Some messages just aren't worth sending.
acceptable length (shoul. be)
Author: Kinnard Message ---------------------
LONG STRING abcde abcde abcde abcd. abcde abcde abcd. abcd. abcd. abcd. abc
d. abcde abcd. abcde abcde abcde
--------------------------------------------------------- */
The Derived Class: EMail Your first derived class is named Email. Email uses the two members already present in the base class. the Email's message is the message of the base class, and the author of the base class is the Emails's author's actual name (not the from email address which I will introduce next). Do not try to store an Email's message body or author as a new member of the derived class or you will get -20 points -- not desirable by you or me. Duplicating base class data in derived class means you do not understand what inheritance is, thus the significance of this kind of mistake.
Public Static Class Constants To the existing base class statics, add at least two with names and meanings similar or identical to MAX_EMAIL_ADDRESS_LENGTH and DEFAULT_EMAIL_ADDRESS. Look up the maximum length of an email address, and make yours no larger than that (but you can make is smaller for easier testing).
Additional Private Member Data . string fromAddress;. string toAddress; Public Methods ● Default and 4-parameter constructors. Use constructor chaining.
● Mutator and Accessor for the new members.
● Override those methods of the base class for which it makes sense to do so. Think about this and come to your own conclusions.
Private Methods ● private static validation helper to filter a bad email address. You should do the minimum, but you don't have to be more complete than that. This is just to show that you can perform basic filtering. The minimum is a method isValidEAddr() (or similarly named) which tests for both length and the existence of at least one '@' and one '.' character. Further is up to you, but don't overdo it or be too restrictive.
Recommended test o. Class Email
Similar to the Message class.
Example Test Run of Email Class (done in same run as overall program run) EMail Derived Class Testing ***********************************
From: lili999@g mail.com
To: hloe123@g mail.com.com
Author: lili koi Message ---------------------
Arf, arf, arf, arf ........ arf
From: chloe123@g mail.com
To: lili999@g mail.com
Author: chloe Message ---------------------
bark bark
testing EMail accessors:
lili999@g mail.com
lili999@g mail.com
testing Email mutators:
too long (as expected)
From: lili999@g mail.com
To: hloe123@g mail.com.com
Author: lili koi Message ---------------------
Arf, arf, arf, arf ........ arf
missing @ char (as expected)
From: lili999@g mail.com
To: hloe123@g mail.com.com
Author: lili koi Message ---------------------
Arf, arf, arf, arf ........ arf
missing DOT char (as expected)
From: lili999@g mail.com
To: hloe123@g mail.com.com
Author: lili koi Message ---------------------
Arf, arf, arf, arf ........ arf
--------------------------------------------------------- */
The Derived Class: Shweet Your second derived class is named Shweet.
(It is like a Twitter Tweet, but since I can't be certain that the details of a Tweet are exactly what I state here, we will disengage this from Twitter, and make the constraints that I impose accurate for a Shweet by decree.)
Shweet uses the two members already present in the base class. The Shweet's message is the message of the base class, and the author of the base class is the Shweet's author's actual name (not the Shwitter ID which I will introduce next). Do not try to store a Shweet's message body or author as new members or you will get -20 points, as mentioned above.
Public Static Class Constants To the existing base class statics, add three with a names and meaning similar or identical to MAX_SHWITTER_ID_LENGTH (15), MAX_SHWEET_LENGTH (140) and DEFAULT_USER_ID. Look up and use the actual maximum lengths of the first two constants.
While the MAX_SHWEET_LENGTH is going to be smaller than the base class's MAX_MSG_LENGTH, do not assume this fact in your implementation. A valid message length for a Shweet has to be smaller than both of these values. If it's not a valid base class message, it isn't a valid Shweet message, and this should be true if we later change the MAX_SHWEET_LENGTH length to be 50 million.
Additional Private Member Data string fromID; Public Methods ● Default and 3-parameter constructors. When it is possible and meaningful, use constructor chaining. Think about which constructor to chain to.
● Mutator and Accessor for the new member.
● Override those methods of the base class for which it makes sense to do so. Think about this and come to your own conclusions. You have to somehow enforce the length limits of both the base class and the derived class for the same message member.
Private Methods ● private static validation helpers (plural) to filter out bad tweets and shwitter IDs. Create a. isValidShweet() for the message. Also, create an isValidShwitterID() for the Shwitter ID. But also, make a third, even lower-level, helper that would make isValidShwitterID() clear and short. This helper-helper should be named something like stringHasOnlyAlphaOrNumOrUnderscore() and that name tells you the kind of thing it should do: it should make sure the shwitter ID contains only some combination of letters, numbers or an underscore ('_'). The name of this method is fine - don't try to apply boolean logic to it as there is no way to do so. The definition is what you care about. Also, I don't care whether you decide that the Shwitter ID be case sensitive. If you don't know the built-in C+. string or char methods that can help you here, look them up online. They are very easy to find.
Recommended test o. Class Shweet Similar to the Message class.
Example Test Run of Shweet Class (done in same run as overall program run) Shweet Derived Class Testing ***********************************
Shweet: Kim Kardashian @kimkardashian
Oh Deer https://www.keek.com/!PYjCdab
Shweet: Katy Perry @katyperry
It's a verb and an adjective.
testing Shweet accessors:
kimkardashian
testing Shweet mutators:
bad shwitter ID (as expected)
Shweet: Kim Kardashian @kimkardashian
Oh Deer https://www.keek.com/!PYjCdab
acceptable shwitter ID (as expected)
Shweet: Kim Kardashian @a_good_user99
Oh Deer https://www.keek.com/!PYjCdab
--------------------------------------------------------- */
OPTION B1 - A Stack of Messages Complete, for submission, OPTION A. Add StackNode and Stack classes, exactly as presented in the Modules. Next, derive MessageNode and MessageStack classes in the same manner as we derived FloatNode and FloatStack in the modules, but making adjustments, as needed, to have the MessageStack work with Messages. Change most methods named showXYZ() by converting them to toString() so that the client, not the methods, does the output. The new methods merely format the strings in preparation for output.
In your client, after you have done the things from OPTION A, add code to create a MessageStack. Then push() all the various Messages onto the stack. This means that some messages will be base class objects and some will be derived class objects. But the code to push (and pop) them in the client is the same. Nothing special need be done in order t. push one kind of Message vs. another kind. That is, if you are doing this right, you just push(someMsg) regardless of what flavor of Message someMsg happens to be, and likewise with the popping.
Finally, in a loop, pop() everything off the MessageStack and print it out as you pop(). Go beyond the end of the Stack so you can confirm that your code does not break when you pop() things off an empty Stack.
If working correctly, this option will print only the base class data, because the toString() method is not virtual. That's how it should be. Furthermore, making toString() virtual is not going to help this, so don't be disappointed if you still do not see derived data when you display the pop()ped objects as they come off the stack.
Submit an article or tip