《左耳听风》-ARTS-打卡记录-第七周
Algorithm
反转字符串中的元音字符
题目:
编写一个函数，以字符串作为输入，反转该字符串中的元音字母。 示例 1: 输入: "hello" 输出: "holle" 示例 2: 输入: "leetcode" 输出: "leotcede" 说明: 元音字母不包含字母"y"。 来源：力扣（LeetCode） 链接：https://leetcode-cn.com/problems/reverse-vowels-of-a-string 著作权归领扣网络所有。商业转载请联系官方授权，非商业转载请注明出处。
思路:先复制一个字符串str2,然后使用两个下标i和j: 从左到右判断s, j从右到左判断str2,当两者都为元音时,将str2的赋值给s,然后一个自增,一个自减.否则根据情况让i自增或者让j自减.
1 class Solution { 2 public: 3 string reverseVowels(string s) { 4 string str2 = s; 5 int i = 0; 6 int j = s.size()-1; 7 while(i<s.size()) 8 { 9 if((s[i]=='a') || (s[i]=='e') || (s[i]=='i') || (s[i]=='o') || (s[i]=='u') || (s[i]=='A') || (s[i]=='E') || (s[i]=='I') || (s[i]=='O') || (s[i]=='U')) 10 { 11 if((str2[j]=='a') || (str2[j]=='e') || (str2[j]=='i') || (str2[j]=='o') || (str2[j]=='u') || (str2[j]=='A') || (str2[j]=='E') || (str2[j]=='I') || (str2[j]=='O') || (str2[j]=='U')) 12 { 13 s[i] = str2[j]; 14 i++; 15 j--; 16 } 17 else 18 { 19 j--; 20 } 21 } 22 else 23 { 24 i++; 25 } 26 27 } 28 return s; 29 } 30 };
执行效率不高,这里有一个string赋值给另一个string的操作,并且时间复杂度为o(n2),待下一期优化.
Review
How To Ask Questions The Smart Way(1/8)
如何聪明地去提问
Table of Contents
Translations 翻译
Disclaimer 免责声明
Introduction 介绍
Before You Ask 当你提问前
When You Ask 当你提问时
Choose your forum carefully 小心地选择你的论坛
Stack Overflow Stack Overflow
Web and IRC forums 网络和IRC论坛.
As a second step, use project mailing lists第二步,使用项目邮件列表
Use meaningful, specific subject headers使用有意义,明确的主题标题
Make it easy to reply 让它容易去回复
Write in clear, grammatical, correctly-spelled language 用清晰,合乎语法的,正确拼写的语言来写作
Send questions in accessible, standard formats用可使用的,标准的格式来发送问题
Be precise and informative about your problem 让你的问题准确且提供有用的信息
Volume is not precision体量不是准确度(话不在多而在精)
Don't rush to claim that you have found a bug不要急于声称你发现了一个bug
Grovelling is not a substitute for doing your homework可以低声下气,但还是要先做功课
Describe the problem's symptoms, not your guesses表述问题的特征,而非你的猜测
Describe your problem's symptoms in chronological order按照时间顺序来描述你的问题的特征
Describe the goal, not the step描述目标,而非步骤
Don't ask people to reply by private e-mail不要要求人们去使用他们的私人邮箱来回复
Be explicit about your question对你自己的问题要明确
When asking about code当问关于代码的问题时
Don't post homework questions不要把家庭作业的问题贴上来
Prune pointless queries精简掉无意义的问题
Don't flag your question as “Urgent”, even if it is for you不要把你的问题标记为"紧急的",即使对你是这样的
Courtesy never hurts, and sometimes helps礼貌不会有伤害,有些使用很有帮助
Follow up with a brief note on the solution问题解决后,加个简短的补充说明
How To Interpret Answers如何解读答案
RTFM and STFW: How To Tell You've Seriously Screwed Up RTFM和STFW:如何知道你已经完全搞砸了
If you don't understand...如果还是搞不懂
Dealing with rudeness处理无礼的回应
On Not Reacting Like A Loser如何避免扮演失败者
Questions Not To Ask不该问的问题
Good and Bad Questions好问题和蠢问题
If You Can't Get An Answer如果得不到回答
How To Answer Questions in a Helpful Way
Translations
Translations: Brazilo-Portuguese Chinese (Traditional) Czech Dutch Estonian French Georgian German Greek Hindi Hungarian Indonesion Japanese Lithuanian Polish Portuguese Russian Spanish Ukrainian Uzbek If you want to copy, mirror, translate, or excerpt this document, please see my copying policy.
Disclaimer
Many project websites link to this document in their sections on how to get help. That's fine, it's the use we intended — but if you are a webmaster creating such a link for your project page, please display prominently near the link notice that we are not a help desk for your project!
We have learned the hard way that without such a notice, we will repeatedly be pestered by idiots who think having published this document makes it our job to solve all the world's technical problems.
If you're reading this document because you need help, and you walk away with the impression you can get it directly from the authors of this document, you are one of the idiots we are talking about. Don't ask us questions. We'll just ignore you. We are here to show you how to get help from people who actually know about the software or hardware you're dealing with, but 99.9% of the time that will not be us. Unless you know for certain that one of the authors is an expert on what you're dealing with, leave us alone and everybody will be happier.
声明
许多项目在他们的使用协助/说明网页中链接了本指南，这么做很好，我们也鼓励大家都这么做。但如果你是负责管理这个项目网页的人，请在超链接附近的显着位置上注明：
本指南不提供此项目的实际支持服务！
我们已经深刻领教到少了上述声明所带来的痛苦。因为少了这点声明，我们不停地被一些白痴纠缠。这些白痴认为既然我们发布了这本指南，那么我们就有责任解决世上所有的技术问题。
如果你是因为需要某些协助而正在阅读这本指南，并且最后离开是因为发现从本指南作者们身上得不到直接的协助，那么你就是我们所说的那些白痴之一。别问我们问题，我们只会忽略你。我们在这本指南中是教你如何从那些真正懂得你所遇到软件或硬件问题的人取得协助，而99%的情况下那不会是我们。除非你确定本指南的作者之一刚好是你所遇到的问题领域的专家，否则请不要打扰我们，这样大家都会开心一点。
Introduction
In the world of hackers, the kind of answers you get to your technical questions depends as much on the way you ask the questions as on the difficulty of developing the answer. This guide will teach you how to ask questions in a way more likely to get you a satisfactory answer.
Now that use of open source has become widespread, you can often get as good answers from other, more experienced users as from hackers. This is a Good Thing; users tend to be just a little bit more tolerant of the kind of failures newbies often have. Still, treating experienced users like hackers in the ways we recommend here will generally be the most effective way to get useful answers out of them, too.
The first thing to understand is that hackers actually like hard problems and good, thought-provoking questions about them. If we didn't, we wouldn't be here. If you give us an interesting question to chew on we'll be grateful to you; good questions are a stimulus and a gift. Good questions help us develop our understanding, and often reveal problems we might not have noticed or thought about otherwise. Among hackers, “Good question!” is a strong and sincere compliment.
Despite this, hackers have a reputation for meeting simple questions with what looks like hostility or arrogance. It sometimes looks like we're reflexively rude to newbies and the ignorant. But this isn't really true.
What we are, unapologetically, is hostile to people who seem to be unwilling to think or to do their own homework before asking questions. People like that are time sinks — they take without giving back, and they waste time we could have spent on another question more interesting and another person more worthy of an answer. We call people like this “losers” (and for historical reasons we sometimes spell it “lusers”).
We realize that there are many people who just want to use the software we write, and who have no interest in learning technical details. For most people, a computer is merely a tool, a means to an end; they have more important things to do and lives to live. We acknowledge that, and don't expect everyone to take an interest in the technical matters that fascinate us. Nevertheless, our style of answering questions is tuned for people who do take such an interest and are willing to be active participants in problem-solving. That's not going to change. Nor should it; if it did, we would become less effective at the things we do best.
We're (largely) volunteers. We take time out of busy lives to answer questions, and at times we're overwhelmed with them. So we filter ruthlessly. In particular, we throw away questions from people who appear to be losers in order to spend our question-answering time more efficiently, on winners.
If you find this attitude obnoxious, condescending, or arrogant, check your assumptions. We're not asking you to genuflect to us — in fact, most of us would love nothing more than to deal with you as an equal and welcome you into our culture, if you put in the effort required to make that possible. But it's simply not efficient for us to try to help people who are not willing to help themselves. It's OK to be ignorant; it's not OK to play stupid.
So, while it isn't necessary to already be technically competent to get attention from us, it is necessary to demonstrate the kind of attitude that leads to competence — alert, thoughtful, observant, willing to be an active partner in developing a solution. If you can't live with this sort of discrimination, we suggest you pay somebody for a commercial support contract instead of asking hackers to personally donate help to you.
If you decide to come to us for help, you don't want to be one of the losers. You don't want to seem like one, either. The best way to get a rapid and responsive answer is to ask it like a person with smarts, confidence, and clues who just happens to need help on one particular problem.
(Improvements to this guide are welcome. You can mail suggestions to esr@thyrsus.com or respond-auto@linuxmafia.com. Note however that this document is not intended to be a general guide to netiquette, and we will generally reject suggestions that are not specifically related to eliciting useful answers in a technical forum.)
简介
在黑客的世界里，当你拋出一个技术问题时，最终是否能得到有用的回答，往往取决于你所提问和追问的方式。本指南将教你如何正确的提问以获得你满意的答案。
不只是黑客，现在开放源代码（Open Source）软件已经相当盛行，你常常也可以由其他有经验的使用者身上得到好答案，这是件**好事**；使用者比起黑客来，往往对那些新手常遇到的问题更宽容一些。然而，将有经验的使用者视为黑客，并采用本指南所提的方法与他们沟通，同样也是能从他们身上得到满意回答的最有效方式。
首先你应该明白，黑客们喜爱有挑战性的问题，或者能激发我们思维的好问题。如果我们并非如此，那我们也不会成为你想询问的对象。如果你给了我们一个值得反复咀嚼玩味的好问题，我们自会对你感激不尽。好问题是激励，是厚礼。好问题可以提高我们的理解力，而且通常会暴露我们以前从没意识到或者思考过的问题。对黑客而言，"好问题！"是诚挚的大力称赞。
尽管如此，黑客们有着蔑视或傲慢面对简单问题的坏名声，这有时让我们看起来对新手、无知者似乎较有敌意，但其实不是那样的。
我们不讳言我们对那些不愿思考、或者在发问前不做他们该做的事的人的蔑视。那些人是时间杀手 -– 他们只想索取，从不付出，消耗我们可用在更有趣的问题或更值得回答的人身上的时间。我们称这样的人为 失败者（撸瑟） （由于历史原因，我们有时把它拼作 lusers）。
我们意识到许多人只是想使用我们写的软件，他们对学习技术细节没有兴趣。对大多数人而言，电脑只是种工具，是种达到目的的手段而已。他们有自己的生活并且有更要紧的事要做。我们了解这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣。尽管如此，我们回答问题的风格是指向那些真正对此有兴趣并愿意主动参与解决问题的人，这一点不会变，也不该变。如果连这都变了，我们就是在降低做自己最擅长的事情上的效率。
我们（在很大程度上）是自愿的，从繁忙的生活中抽出时间来解答疑惑，而且时常被提问淹没。所以我们无情的滤掉一些话题，特别是拋弃那些看起来像失败者的家伙，以便更高效的利用时间来回答赢家（winner）的问题。
如果你厌恶我们的态度，高高在上，或过于傲慢，不妨也设身处地想想。我们并没有要求你向我们屈服 -- 事实上，我们大多数人非常乐意与你平等地交流，只要你付出小小努力来满足基本要求，我们就会欢迎你加入我们的文化。但让我们帮助那些不愿意帮助自己的人是没有效率的。无知没有关系，但装白痴就是不行。
所以，你不必在技术上很在行才能吸引我们的注意，但你必须表现出能引导你变得在行的特质 -- 机敏、有想法、善于观察、乐于主动参与解决问题。如果你做不到这些使你与众不同的事情，我们建议你花点钱找家商业公司签个技术支持服务合同，而不是要求黑客个人无偿地帮助你。
如果你决定向我们求助，当然你也不希望被视为失败者，更不愿成为失败者中的一员。能立刻得到快速并有效答案的最好方法，就是像赢家那样提问 -- 聪明、自信、有解决问题的思路，只是偶尔在特定的问题上需要获得一点帮助。
（欢迎对本指南提出改进意见。你可以 email 你的建议至 esr@thyrsus.com 或 respond-auto@linuxmafia.com。然而请注意，本文并非网络礼节的通用指南，而我们通常会拒绝无助于在技术论坛得到有用答案的建议。）
Tips
1.处理逾期的任务:
没完成的话,再延长一个或者半个整段的时间,如果连续两个小时还没有搞定,则选择暂停,换个脑子去做别的事情.
