How to Actually Execute Your To-do List

本文探讨了在执行待办事项清单时遇到的常见问题,并提供了一系列实用建议帮助读者克服这些障碍,包括如何开始工作、集中注意力及保持动力。

Have you gotten good at organizing your tasks in a to-do list, but have trouble actually executing them? You’re not alone.

Getting things on your to-do list actually done is difficult because it’s really a collection of habits that most people don’t think about. Today, we’ll look at addressing those issues that stop you from doing things, and the habits needed to overcome those issues.

This post was prompted when reader BJ Thunderstone recently asked a great question:

A lot of productivity systems such as Getting Things Done by David Allen or Do It Tomorrow by Mark Forster concern themselves with writing lists of things to do. This skill is easy to learn.But what if the problem isn’t making lists, but executing your plan? What if you write “Get X, Y and Z done” and then you can’t make yourself do any of these things?

I think that many people have a problem not with making to-do lists - but with executing what is written on these lists.

B.J. went on to list some of the reasons he and others have a problem getting things done. Let’s address them one by one.

“I feel resistance when starting work on something.”
First of all, it’s good to analyze your resistance, which is something we don’t do often. Why don’t you want to start on something? Identifying the problem can help lead to the solution.

Having said that, there are a couple of suggestions that could help:

  • Tiny chunk . Tell yourself you only have to do 5 minutes of work on it. That small amount of work is less intimidating.
  • Just start . Once you get going, it’s much easier to keep going. So tell yourself that all you have to do is start. I like to compare this to my philosophy of running: instead of worrying about having to do the whole run, I tell myself that I just have to lace up my shoes and get out the door. After that, it’s really easy. Do the same thing with any task — just fire up your program, and do the first few actions (i.e. start typing). It gets easier after that point.
  • Reward yourself . Don’t let yourself check email (or whatever reward works for you — something that you need to do every day) until you do at least 10 minutes (or 15 or 20, it doesn’t matter) on the task. Set a timer. Once your 10 minutes is up, set another timer for 5 minutes and do email. Then repeat.
  • Get excited about it . This is actually a tip that helps with any of these points. If you are excited about doing something, you will not hesitate to do it. For example, I loved this topic suggestion, and I was excited about writing it. As soon as I had the chance, I sat down to write it and only took one break. But how do you get excited about a task? Try to find something exciting about it. Will it bring you revenue? What can you do with that revenue? Will it bring you new clients, new opportunities, new recognition? If you can’t find anything exciting about a task, consider whether it’s really important or not — and if not, find a way to not do it. Sometimes eliminating (or delegating or delaying) the task is the best option.

“I am terrified of certain tasks, or of working on certain projects.”
There are usually a few reasons those tasks or projects terrify you:

  1. They are too intimidating in size or scope . To combat this, break it down into tinier chunks — actually, just the first tiny chunk (as David Allen tells us to do in GTD). It’s intimidating to do a task like “Create report on X” or “Make a yearly plan for Z”. But if you just need to do the first physical action, which might be, “Call Frank for figures on X” or “Make a list of 10 things we should accomplish this year”, it’s much easier to tackle and less intimidating.
  2. You don’t really know how to do it . If you haven’t done something a million times before, it is unfamiliar and unknown to you. And we are all terrified of that. The solution? First, get more information — learn as much as you can about it. That might require some research on the Internet, or talking to someone who’s done it before, or reading a book, or taking a class. Whatever you need to do, make the unknown become the known. Second, practice it as much as possible. Once you’ve learned how to do something, you need to practice it to become good at it. Don’t practice the whole thing — practice individual skills required to do a task or project, one at a time, until you’re good at those skills. Once you’ve mastered them, it will no longer be terrifying.
  3. You are focusing on negative aspects . You might be focusing on how hard something is, or on all the obstacles. Try looking at the positive aspects instead. Focus on what a great opportunity this project represents … an opportunity to learn, to get better at something, to make more money, to work on a relationship, to gain some long-term recognition, to improve your advancement opportunities. This is similar to the “get excited about it” item in the previous section. If you look at the opportunities, not the problems, you will be less terrified and more likely to want to do it.

“I start, but I get distracted and never finish.”
If you start, you’ve already made a big step towards finishing. Now you just need to work on the distractions. My suggestions won’t be popular, but they work:

  • Small tasks . I mentioned this above, but it’s really important to repeat here. If you are getting distracted, it may be because you are working too long on a single task or project. To remain focused, do only a small task — you are more likely to stay on task. If the task takes a long time, focus on only doing 15-20 minutes of it.
  • Single-task . Don’t allow yourself to do multiple tasks at the same time. Just do the one task before you. If you tend to do email, IM, surf the web, read your RSS feeds, talk on the phone and all of that while doing a task, you will inevitably be distracted from a task. Do one task at a time. If you feel yourself being pulled from the task, stop yourself. And bring yourself back.
  • Unplug . The biggest distractions come from connectivity. Email, feeds, IM, Twitter, phones. Unplug from these connections while you’re working on your single task. This is always an unpopular suggestion, but before you reject it, give it a try. Turn everything off, and try to focus on one task. You’ll get a lot more done, I guarantee you. Right now, I’m writing this post while disconnected from the Internet. It’s much easier to concentrate.
  • Clear your desk . Distractions can come from visual clutter. It can be worth it to clear everything off your desk (see 3 Steps to a Permanently Clear Desk). Also clear your walls and your computer desktop, and only work on one program at a time if possible.
  • Focus . Once your desk is clear and you unplug, and you’re working on that single task, really put all of your concentration on it. Pour your energies into that task, and see if you can get it done quickly. You might even get lost in it, and achieve that highly touted (deservedly so) state of mind known as “flow”.
  • Take breaks . It can help you to focus for a short amount of time on a single task, and use a time to help you focus, and then to take a break. This allows you to reboot your brain. Then, get back to work and focus on the next task.

“I often don’t feel like doing any work at all. The idea of work seems horrible and I never start doing anything.”
I know this feeling well. It plagues us all, and there’s no one good answer. However, here are some suggestions:

  • Groom yourself . If you work from home, take a shower. Often the act of grooming ourselves can make us feel much better.
  • Take a walk . I find that a little walk can get my blood pumping, refresh my mind, and allow me to think about what I really want to do today. It might not be what you need, but it’s worth a shot.
  • Exercise . Similarly, exercise can make you feel great. A jog in the park, a short strength workout, some pilates, or meditation … these things get your mood up and get you feeling productive and happy. Try it out — you might feel more like doing stuff when you’re done.
  • Again, think of opportunities . Think about tomorrow — not tomorrow as in the distant future, but tomorrow as in the day after today. Imagine yourself looking back on today from tomorrow. Will you be glad you laid around? Or would you be happier if you did something, and took advantage of the opportunities in front of you today? It’s useful to think in terms of your future self — because what we do today will open up opportunities and new roads for tomorrow’s us.
  • Baby steps . Don’t think in terms of having to tackle an entire work day, or an entire list of stuff to do. That’s overwhelming. Just think of doing one thing. That’s all you have to do — just that one thing. Make it something small and easy, and ideally something fun and rewarding. Focus on that easy task. Once you get started, you might be more willing to do another thing. Then another.
  • Find fun stuff to do . If you just have boring or unpleasant things to do, you won’t feel like doing them. Instead, change your path for today — see if you can find something that’s fun or exciting, but still moves you forward on a project or goal. That might be what you need to get you jump-started to do other stuff — or you might instead only spend the day doing only fun stuff (as long as it moves you forward — don’t just play solitaire or WoW).
  • Commit thyself . If motivation is your problem, commit yourself to making some progress with a goal or project today, or every day this week — tell all your family and friends, write it in your blog, or join the Zen Habits forum — it’s a great motivator. Then hold yourself accountable by reporting to others what you did today.
  • Rewards . Tell yourself that if you just do that first task, you’ll get a nice ice cream sundae. Or that you can buy a book, or DVD. Whatever your reward, use it to motivate yourself to just get started. Then let the rest flow from there.

“I make a list of things to do the next day.. and on that day, I wake up looking forward to a bad day, full of unpleasant tasks, I don’t feel like doing anything from the list.”
Two things to say here:

  1. Overload . The most probable reason is that you’re overloading yourself. People tend to pile too much on themselves for a single day, overestimating how much they can actually do. Get into the habit of choosing only three Most Important Tasks to do for the day, and do them early in the day (at least two of them before email). If you only have three things to do, it’s not overwhelming. You’ll probably have some smaller things to do later, but write those down under a “batch process” heading, and do those small things all at once near the end of the day.
  2. Fun . The second thing is that you’re loading yourself up with unpleasant tasks. Who wants to face a day of that? Instead, put down tasks that you’ll look forward to doing. Create an exciting to-do list for tomorrow. If you really have nothing important to do that’s enjoyable, it’s possible you’re in the wrong job. Look instead for a job that you’ll actually enjoy. Yes, every job has unpleasant and difficult tasks, but they lead to something rewarding. They support something you get excited about. If you don’t have anything like that in your job, you need to take a closer look at your job — revamp it somehow, or look for another.

Have your own methods of getting your to-do list done? Have other problems? Discuss it in the Zen Habits forums .

请查看以下的C++代码的编写要求,请根据代码要求开始编写代码 PURPOSE: This file is a proforma for the EEET2246 Laboratory Code Submission/Test 1. This file defines the assessment task which is worth 10% of course in total - there is no other documentation. At the BASIC FUNCTIONAL REQUIREMENTS level, your goal is to write a program that takes two numbers from the command line and perform and arithmetic operations with them. Additionally your program must be able to take three command line arguments where if the last argument is 'a' an addition is performed, and if 's' then subtraction is performed with the first two arguments. At the FUNCTIONAL REQUIREMENTS level you will be required to extend on the functionality so that the third argument can also be 'm' for multiplication,'d' for division and 'p' for exponential operations, using the first two arguments as the operands. Additionally, at this level basic error detection and handling will be required. The functionality of this lab is relatively simple: + - / * and "raised to the power of" The emphasis in this lab is to achieve the BASIC FUNCTIONALITY REQUIREMENTS first. Once you a basic program functioning then you should attempt the FUNCTIONALITY REQUIREMENTS and develop your code so that it can handle a full range of error detection and handling. ___________________________________________________________________________________________ ___ GENERAL SPECIFICATIONS (mostly common to all three EEET2246 Laboratory Code Submissions): G1. You must rename your file to lab1_1234567.cpp, where 1234567 is your student number. Your filename MUST NEVER EVER contain any spaces. _under_score_is_Fine. You do not need to include the 's' in front of your student number. Canvas will rename your submission by adding a -1, -2 etc. if you resubmit your solution file - This is acceptable. G2. Edit the name/email address string in the main() function to your student number, student email and student name. The format of the student ID line is CSV (Comma Separated Variables) with NO SPACES- student_id,student_email,student_name When the program is run without any operands i.e. simply the name of the executable such as: lab1_1234567.exe the program MUST print student ID string in Comma Separated Values (CSV) format with no spaces. For example the following text should be outputted to the console updated with your student details: "1234567,s1234567@student.rmit.edu.au,FirstName_LastName" G3. All outputs are a single error character or a numerical number, as specified by the FUNCTIONAL REQURMENTS, followed by a linefeed ( endl or \n). G4. DO NOT add more than what is specified to the expected console output. Do NOT add additional information, text or comments to the output console that are not defined within the SPECIFICATIONS/FUNCTIONAL REQURMENTS. G5. DO NOT use 'cin', system("pause"), getchar(), gets(), etc. type functions. Do NOT ask for user input from the keyboard. All input MUST be specified on the command line separated by blank spaces (i.e. use the argv and argc input parameters). G6. DO NOT use the characters: * / \ : ^ ? in your command line arguments as your user input. These are special character and may not be processed as expected, potentially resulting in undefined behaviour of your program. G7. All input MUST be specified on the command line separated by blank spaces (i.e. use the argc and argv[] input parameters). All input and output is case sensitive unless specified. G8. You should use the Integrated Debugging Environment (IDE) to change input arguments during the development process. G9. When your code exits the 'main()' function using the 'return' command, you MUST use zero as the return value. This requirement is for exiting the 'main()' function ONLY. A return value other than zero will indicate that something went wrong to the Autotester and no marks will be awarded. G10. User-defined functions and/or class declarations must be written before the 'main()' function. This is a requirement of the Autotester and failure to do so will result in your code scoring 0% as it will not be compiled correctly by the Autotester. Do NOT put any functions/class definitions after the 'main()' function or modify the comments and blank lines at the end of this file. G11. You MUST run this file as part of a Project - No other *.cpp or *.h files should be added to your solution. G12. You are not permitted to add any other #includes statements to your solution. The only libraries permitted to be used are the ones predefined in this file. G13. Under no circumstances is your code solution to contain any go_to labels - Please note that the '_' has been added to this description so that this file does not flag the Autotester. Code that contains go_to label like syntax will score 0% and will be treated as code that does not compile. G14. Under no circumstances is your code solution to contain any exit_(0) type functions. Please note that the '_' has been added to this description so that this file does not flag the Autotester. Your solution must always exit with a return 0; in main(). Code that contains exit_(0); label like syntax will score 0% and will be treated as code that does not compile. G15. Under no circumstances is your code solution to contain an infinite loop constructs within it. For example usage of while(1), for(int i; ; i++) or anything similar is not permitted. Code that contains an infinite loop will result in a score of 0% for your assessment submission and will be treated as code that does not compile. G16. Under no circumstances is your code solution to contain any S_l_e_e_p() or D_e_l_a_y() like statements - Please note that the '_' has been added to this description so that this file does not flag the Autotester. You can use such statements during your development, however you must remove delays or sleeps from your code prior to submission. This is important, as the Autotester will only give your solution a limited number of seconds to complete (i.e. return 0 in main()). Failure for your code to complete the required operation/s within the allotted execution window will result in the Autotester scoring your code 0 marks for that test. To test if your code will execute in the allotted execution window, check that it completes within a similar time frame as the provided sample binary. G17. Under no circumstances is your code solution to contain any characters from the extended ASCII character set or International typeset characters. Although such characters may compile under a normal system, they will result in your code potentially not compiling under the Autotester environment. Therefore, please ensure that you only use characters: a ... z, A ... Z, 0 ... 9 as your variable and function names or within any literal strings defined within your code. Literal strings can contain '.', '_', '-', and other basic symbols. G18. All output to console should be directed to the standard console (stdout) via cout. Do not use cerr or clog to print to the console. G19. The file you submit must compile without issues as a self contained *.cpp file. Code that does not compile will be graded as a non-negotiable zero mark. G20. All binary numbers within this document have the prefix 0b. This notation is not C++ compliant (depending on the C++ version), however is used to avoid confusion between decimal, hexadecimal and binary number formats within the description and specification provided in this document. For example the number 10 in decimal could be written as 0xA in hexadecimal or 0b1010 in binary. It can equally be written with leading zeroes such as: 0x0A or 0b00001010. For output to the console screen you should only ever display the numerical characters only and omit the 0x or 0b prefixes (unless it is specifically requested). ___________________________________________________________________________________________ ___ BASIC FUNCTIONAL REQUIREMENTS (doing these alone will only get you to approximately 40%): M1. For situation where NO command line arguments are passed to your program: M1.1 Your program must display your correct student details in the format: "3939723,s3939723@student.rmit.edu.au,Yang_Yang" M2. For situation where TWO command line arguments are passed to your program: M2.1 Your program must perform an addition operation, taking the first two arguments as the operands and display only the result to the console with a new line character. Example1: lab1_1234567.exe 10 2 which should calculate 10 + 2 = 12, i.e. the last (and only) line on the console will be: 12 M3. For situations where THREE command line arguments are passed to your program: M3.1 If the third argument is 'a', your program must perform an addition operation, taking the first two arguments as the operands and display only the result to the console with a new line character. M3.2 If the third argument is 's', your program must perform a subtraction operation, taking the first two arguments as the operands and display only the result to the console with a new line character. The second input argument should be subtracted from the first input argument. M4. For situations where less than TWO or more than THREE command line arguments are passed to your program, your program must display the character 'P' to the console with a new line character. M5. For specifications M1 to M4 inclusive: M5.1 Program must return 0 under all situations at exit. M5.2 Program must be able to handle integer arguments. M5.3 Program must be able to handle floating point arguments. M5.4 Program must be able to handle one integer and one floating point argument in any order. Example2: lab1_1234567.exe 10 2 s which should calculate 10 - 2 = 8, i.e. the last (and only) line on the console will be: 8 Example3: lab1_1234567.exe 10 2 which should calculate 10 + 2 = 12, i.e. the last (and only) line on the console will be: 12 Example4: lab1_1234567.exe 10 4 a which should calculate 10 + 4 = 14, i.e. the last (and only) line on the console will be: 14 ___________________________________________________________________________________________ ___ FUNCTIONAL REQUIREMENTS (to get over approximately 50%): E1. For situations where THREE command line arguments (other than 'a' or 's') are passed to your program: E1.1 If the third argument is 'm', your program must perform a multiplication operation, taking the first two arguments as the operands and display only the result to the console with a new line character. E1.2 If the third argument is 'd', your program must perform a division operation, taking the first two arguments as the operands and display only the result to the console with a new line character. E1.3 If the third argument is 'p', your program must perform an exponential operation, taking the first argument as the base operand and the second as the exponent operand. The result must be display to the console with a new line character. Hint: Consider using the pow() function, which has the definition: double pow(double base, double exponent); Example5: lab1_1234567.exe 10 2 d which should calculate 10 / 2 = 5, i.e. the last (and only) line on the console will be: 5 Example6: lab1_1234567.exe 10 2 p which should calculate 10 to power of 2 = 100, i.e. the last (and only) line on the console will be: 100 NOTE1: DO NOT use the character ^ in your command line arguments as your user input. Question: Why don't we use characters such as + - * / ^ ? to determine the operation? Answer: Arguments passed via the command line are processed by the operating system before being passed to your program. During this process, special characters such as + - * / ^ ? are stripped from the input argument stream. Therefore, the input characters: + - * / ^ ? will not be tested for by the autotester. See sections G6 and E7. NOTE2: the pow() and powl() function/s only work correctly for given arguments. Hence, your code should output and error if there is a domain error or undefined subset of values. For example, if the result does not produce a real number you code should handle this as an error. This means that if the base is negative you can't accept and exponent between (but not including) -1 and 1. If you get this then, output a MURPHY's LAW error: "Y" and return 0; NOTE3: zero to the power of zero is also undefined, and should also be treated MURPHY's LAW error. So return "Y" and return 0; In Visual Studio, the 0 to the power of 0 will return 1, so you will need to catch this situation manually, else your code will likely calculate the value as 1. ___ REQUIRED ERROR HANDLING (to get over approximately 70%): The following text lists errors you must detect and a priority of testing. NB: order of testing is important as each test is slight more difficult than the previous test. All outputs should either be numerical or upper-case single characters (followed by a new line). Note that case is important: In C, 'V' is not the same as 'v'. (No quotes are required on the output). E2. Valid operator input: If the third input argument is not a valid operation selection, the output shall be 'V'. Valid operators are ONLY (case sensitive): a addition s subtraction m multiplication d division p exponentiation i.e. to the power of: 2 to the power of 3 = 8 (base exponent p) E3. Basic invalid number detection (Required): Valid numbers are all numbers that the "average Engineering graduate" in Australia would consider valid. Therefore if the first two arguments are not valid decimal numbers, the output shall be 'X'. For example: -130 is valid +100 is valid 1.3 is valid 3 is valid 0.3 is valid .3 is valid ABC123 is not valid 1.3.4 is not valid 123abc is not valid ___ ERROR HANDLING (not marked by the autotester): E4. Intermediate invalid number detection (NOT TESTED BY AUTOTESTER - for your consideration only): If the first two arguments are not valid decimal numbers, the output shall be 'X'. Using comma punctuated numbers and scientific formatted numbers are considered valid. For example: 0000.111 is valid 3,000 is valid - NB: atof() will read this as '3' not as 3000 1,000.9 is valid - NB: atof() will read this as '1' not as 1000.9 1.23e2 is valid 2E2 is valid -3e-0.5 is not valid (an integer must follow after the e or E for floating point number to be valid) 2E2.1 is not valid e-1 is not valid .e3 is not valid E5. Advanced invalid number detection (NOT TESTED BY AUTOTESTER - for your consideration only): If the first two arguments are not valid decimal numbers, the output shall be 'X'. 1.3e-1 is valid 1,00.0 is valid - NB: if the comma is not removed atof() will read this as '1' not as 100 +212+21-2 is not valid - NB: mathematical operation on a number of numbers, not ONE number 5/2 is not valid - NB: mathematical operation on a number of numbers, not ONE number HINT: consider the function atof(), which has the definition: double atof (const char* str); Checking the user input for multiple operators (i.e. + or -) is quite a difficult task. One method may involve writing a 'for' loop which steps through the input argv[] counting the number of operators. This process could also be used to count for decimal points and the like. The multiple operator check should be considered an advanced task and developed once the rest of the code is operational. E6. Input number range checking: All input numbers must be between (and including) +2^16 (65536) or -2^16 (-65536). If the operand is out of range i.e. too small or too big, the output shall be 'R'. LARGE NUMBERS: is 1.2e+999 acceptable input ? what happens if you enter such a number ? try and see. Hint: #INF error - where and when does it come up ? SMALL NUMBERS: is 1.2e-999 acceptable input ? what happens if you enter such a number ? try and see. Test it by writing your own test program. E7. ERROR checks which will NOT be performed are: E7.1 Input characters such as: *.* or / or \ or : or any of these characters: * / ^ ? will not be tested for. E7.2 Range check: some computer systems accept numbers of size 9999e999999 while others flag and infinity error. An infinity error becomes an invalid input Therefore: input for valid numbers will only be tested to the maximum 9.9e99 (Note: 9.9e99 is out of range and your program should output 'R') E8. Division by zero should produce output 'M' E9. Error precedence: If multiple errors occur during a program execution event, your program should only display one error code followed by a newline character and then exit (using a return 0; statement). In general, the precedence of the error reported to the console should be displayed in the order that they appear within this proforma. However to clarify the exact order or precedence for the error characters, the precedence of the displayed error code should occur in this order: 'P' - Incorrect number of input command line arguments (see M4) 'X' - Invalid numerical command line argument 'V' - Invalid third input argument 'R' - operand (command line argument) value out of range 'M' - Division by zero 'Y' - MURPHY'S LAW (undefined error) Therefore if an invalid numerical command line argument and an invalid operation argument are passed to the program, the first error code should be displayed to the console, which in this case would be 'X'. Displaying 'V' or 'Y' would be result in a loss of marks. E10. ANYTHING ELSE THAT CAN GO WRONG (MURPHY'S LAW TEST): If there are any other kinds of errors not covered here, the output shall be 'Y'. Rhetorical question: What for example are the error codes that the Power function returns ? If this happens then the output shall be 'Y'. See section E1.3, NOTE2. ___________________________________________________________________________________________ ___ HINTS: - Use debug mode and a breakpoint at the return statement prior to program finish in main. - What string conversion routines, do you know how to convert strings to number? Look carefully as they will be needed to convert a command line parameter to a number and also check for errors. - ERROR CHECKING: The basic programming rules are simple (as covered in lectures): 1) check that the input is valid. 2) check that the output is valid. 3) if any library function returns an error code USE IT !!! CHECK FOR IT !!! - Most conversion routines do have inbuilt error checking - USE IT !!! That means: test for the error condition and take some action if the error is true. If that means more than 50% of your code is error checking, then that's the way it has to be. ____________________________________________________________________________________________ */ // These are the libraries you are allowed to use to write your solution. Do not add any // additional libraries as the auto-tester will be locked down to the following: #include <iostream> #include <cstdlib> #include <time.h> #include <math.h> #include <errno.h> // leave this one in please, it is required by the Autotester! // Do NOT Add or remove any #include statements to this project!! // All library functions required should be covered by the above // include list. Do not add a *.h file for this project as all your // code should be included in this file. using namespace std; const double MAXRANGE = pow(2.0, 16.0); // 65536 const double MINRANGE = -pow(2.0, 16.0); // All functions to be defined below and above main() - NO exceptions !!! Do NOT // define function below main() as your code will fail to compile in the auto-tester. // WRITE ANY USER DEFINED FUNCTIONS HERE (optional) // all function definitions and prototypes to be defined above this line - NO exceptions !!! int main(int argc, char *argv[]) { // ALL CODE (excluding variable declarations) MUST come after the following 'if' statement if (argc == 1) { // When run with just the program name (no parameters) your code MUST print // student ID string in CSV format. i.e. // "studentNumber,student_email,student_name" // eg: "3939723,s3939723@student.rmit.edu.au,Yang_Yang" // No parameters on command line just the program name // Edit string below: eg: "studentNumber,student_email,student_name" cout << "3939723,s3939723@student.rmit.edu.au,Yang_Yang" << endl; // Failure of your program to do this cout statement correctly will result in a // flat 10% marks penalty! Check this outputs correctly when no arguments are // passed to your program before you submit your file! Do it as your last test! // The convention is to return Zero to signal NO ERRORS (please do not change it). return 0; } //--- START YOUR CODE HERE. // The convention is to return Zero to signal NO ERRORS (please do not change it). // If you change it the AutoTester will assume you have made some major error. return 0; } // No code to be placed below this line - all functions to be defined above main() function. // End of file.
08-16
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值