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

Related Resources相關資源

Acknowledgements鳴謝

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.處理逾期的任務:

沒完成的話,再延長一個或者半個整段的時間,如果連續兩個小時還沒有搞定,則選擇暫停,換個腦子去做別的事情.

---

Share

qt修改完ui文件起不到作用

總結

以上是生活随笔為你收集整理的《左耳听风》-ARTS-打卡记录-第七周的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。