คำถามติดแท็ก headers

8
จะดีกว่าการทำเอกสารฟังก์ชั่นในไฟล์ส่วนหัวหรือไฟล์ต้นฉบับ?
ในภาษาที่แยกความแตกต่างระหว่างไฟล์ "แหล่งที่มา" และ "ส่วนหัว" (ส่วนใหญ่ C และ C ++) จะดีกว่าฟังก์ชั่นเอกสารในไฟล์ส่วนหัวหรือไม่: (ขโมยจากCCAN ) /** * time_now - return the current time * * Example: * printf("Now is %lu seconds since epoch\n", (long)time_now().tv_sec); */ struct timeval time_now(void); หรือในไฟล์ต้นฉบับ? (ขโมยจาก PostgreSQL) /* * Convert a UTF-8 character to a Unicode code point. * …
86 c++  c  headers 

5
สิ่งที่ควรและสิ่งที่ไม่ควรอยู่ในไฟล์ส่วนหัว? [ปิด]
สิ่งที่ไม่ควรรวมอยู่ในไฟล์ส่วนหัวอย่างแน่นอน? ตัวอย่างเช่นถ้าฉันทำงานกับรูปแบบมาตรฐานอุตสาหกรรมที่มีค่าคงที่จำนวนมากเป็นวิธีปฏิบัติที่ดีที่จะกำหนดไว้ในไฟล์ส่วนหัว (ถ้าฉันเขียนโปรแกรมแยกวิเคราะห์สำหรับรูปแบบนั้น) ฟังก์ชั่นใดที่ควรเข้าไปในไฟล์ส่วนหัว? ฟังก์ชั่นอะไรไม่ควร?
71 c  headers 

3
ทำไมเราต้องใส่สมาชิกส่วนบุคคลไว้ในหัว?
ตัวแปรส่วนตัวเป็นวิธีการซ่อนความซับซ้อนและรายละเอียดการใช้งานให้กับผู้ใช้ของชั้นเรียน นี่เป็นฟีเจอร์ที่ค่อนข้างดี แต่ฉันไม่เข้าใจว่าทำไมใน c ++ เราต้องใส่ไว้ในส่วนหัวของชั้นเรียน ฉันเห็นข้อเสียที่น่ารำคาญสองประการนี้: มันตัดส่วนหัวจากผู้ใช้ มันบังคับให้รวบรวมไคลเอนต์ไลบรารีทั้งหมดใหม่ทุกครั้งที่มีการแก้ไข internals มีเหตุผลทางแนวคิดเบื้องหลังข้อกำหนดนี้หรือไม่ มันเป็นเพียงเพื่อความสะดวกในการทำงานออกคอมไพเลอร์?
62 c++  headers 

4
ทำไม #include <iostream.h> ไม่ดี
ฉันกำลังอ่านหัวข้ออื่นที่ชายคนหนึ่งถามเกี่ยวกับหนังสือ C ++ สำหรับผู้เริ่มต้นและหนึ่งในโปรแกรมเมอร์ที่ตอบรับเขียนสิ่งนี้: คำเตือนบางอย่าง: หลีกเลี่ยงหนังสือทุกเล่มที่มีคำว่า "สวัสดีโลก" ที่ระบุ #include &lt;iostream.h&gt; ฉันเปิดหนังสือ C ++ ของฉันและได้รวมส่วนหัว iostream อย่างที่แสดงไว้ด้านบน เหตุใดจึงไม่ดี คำแนะนำอื่น ๆ ที่ฉันควรทราบเมื่อเรียนรู้ C ++ คืออะไร พื้นหลัง: ฉันมีความเชี่ยวชาญใน C และฉันจะเริ่มเรียนรู้ C ++ ภาคการศึกษาถัดไปนี้

3
ข้อความสงวนลิขสิทธิ์ในซอร์สโค้ด [ปิด]
นับตั้งแต่ฉันเริ่มเขียนโปรแกรมฉันเห็นส่วนหัวที่ด้านบนสุดของไฟล์รหัสส่วนใหญ่ที่ระบุถึงลิขสิทธิ์บางประเภท: เช่น /* Copyright (c) 1998 Innotech */ หรือ /* Copyright (c) 1998-2008 Innotech */ แนวคิดที่ผมได้รับความคิด ... ขึ้นอยู่กับความต้องการของคุณ / ต้องการมันประมาณแปลที่ไหนสักแห่งระหว่าง: เฮ้ลองดูสิ! ฉันทำสิ่งนี้! ฉันยอดเยี่ยม! ไปยัง อย่าคัดลอก / แจกจ่ายต่อนี้! ทนายความของเราจะมาหาคุณถ้าคุณทำ! ในมือข้างหนึ่งฉันพบว่าทั้งเรื่องค่อนข้างตลกขบขันบ่อยครั้งที่นี่เป็นไฟล์ที่ไม่มีใครเห็นนอกนักพัฒนาใน บริษัท แต่ทว่าการสันนิษฐานว่าบรรทัดนี้อาจเป็นจริงในวันหนึ่ง "หมายถึงบางสิ่ง" ฉันอยากรู้เกี่ยวกับส่วนวันที่ . วันที่เดียวบ่งบอกว่าผู้เขียนอ้างสิทธิ์ในลิขสิทธิ์ของไฟล์ตั้งแต่วันดังกล่าวไปจนถึงชั่วนิรันดร์หรือไม่? หากมีการใช้ช่วงวันที่และไม่ได้รับการอัปเดตจนถึงปัจจุบันผู้พัฒนาได้ยกเลิกการใช้งานลิขสิทธิ์ของตนเองเกินช่วงวันที่หรือไม่ หากไม่มีการยื่นเรื่องกฎหมายเพิ่มเติมบางประเภท - ส่วนหัวลิขสิทธิ์ให้ความแข็งแกร่งทางกฎหมายใด ๆ หรือไม่? หรือเราทุกคนก็แค่หลอกตัวเอง

7
ฉันจะป้องกันไม่ให้ส่วนหัวนรกได้อย่างไร
เรากำลังเริ่มโครงการใหม่ตั้งแต่เริ่มต้น ประมาณแปดนักพัฒนาระบบย่อยโหลหรือมากกว่านั้นแต่ละคนมีไฟล์ต้นฉบับสี่หรือห้าไฟล์ เราจะทำอย่างไรเพื่อป้องกัน“ หัวนรก”, AKA“ หัวสปาเก็ตตี้”? หนึ่งส่วนหัวต่อไฟล์ต้นฉบับ? บวกหนึ่งต่อระบบย่อย? แยก typdefs, stucts &amp; enums จากฟังก์ชั่นต้นแบบหรือไม่? แยกระบบย่อยภายในออกจากสิ่งของภายนอกของระบบย่อยหรือไม่? ยืนยันว่าทุกไฟล์เดียวไม่ว่าจะเป็นส่วนหัวหรือแหล่งที่มาจะต้องรวบรวมแบบสแตนด์อโลน ฉันไม่ได้ขอวิธีที่ "ดีที่สุด" เพียงชี้ว่าควรระวังอะไรและอาจทำให้เกิดความเศร้าโศกเพื่อที่เราจะได้พยายามหลีกเลี่ยง นี่จะเป็นโครงการ C ++ แต่ข้อมูล C จะช่วยผู้อ่านในอนาคต
44 c++  headers  include 

8
เป็นการดีหรือไม่ที่จะต้องพึ่งพาส่วนหัวที่รวมอยู่ในทรานซิสชัน?
ฉันกำลังล้างค่าการรวมในโครงการ C ++ ที่ฉันกำลังทำงานอยู่และฉันสงสัยอยู่เสมอว่าควรรวมส่วนหัวทั้งหมดที่ใช้โดยตรงในไฟล์ใดไฟล์หนึ่งหรือไม่หรือควรจะรวมเฉพาะขั้นต่ำเปล่าเท่านั้น นี่คือตัวอย่างEntity.hpp: #include "RenderObject.hpp" #include "Texture.hpp" struct Entity { Texture texture; RenderObject render(); } (สมมติว่าการประกาศล่วงหน้าสำหรับRenderObjectไม่ใช่ตัวเลือก) ตอนนี้ฉันรู้ว่าRenderObject.hppรวมถึงTexture.hpp- ฉันรู้ว่าเพราะแต่ละคนRenderObjectมีTextureสมาชิก ยังคงฉันอย่างชัดเจนรวมถึงTexture.hppในเพราะฉันไม่แน่ใจว่ามันเป็นความคิดที่ดีที่จะพึ่งพามันถูกรวมอยู่ในEntity.hppRenderObject.hpp ดังนั้น: เป็นการปฏิบัติที่ดีหรือไม่?
37 c++  c  headers  include 

6
เหตุใดคุณจึงมีคำนิยามวิธีการภายในไฟล์ส่วนหัวใน C ++ เมื่ออยู่ใน C คุณไม่สามารถ?
ใน C คุณไม่สามารถนิยามฟังก์ชัน / การนำไปใช้ภายในไฟล์ส่วนหัว อย่างไรก็ตามใน C ++ คุณสามารถใช้วิธีการเต็มรูปแบบภายในไฟล์ส่วนหัว ทำไมพฤติกรรมต่างกัน
23 c++  c  headers 

7
เหตุใดเราต้องรวม. h ขณะที่ทุกอย่างทำงานเมื่อรวมเฉพาะไฟล์. cpp
ทำไมเราต้องรวมทั้งไฟล์.hและ.cppในขณะที่เราสามารถทำให้มันทำงานได้โดยรวม.cppไฟล์ ตัวอย่างเช่นการสร้างfile.hที่มีการประกาศแล้วการสร้างคำนิยามที่มีและรวมทั้งในfile.cppmain.cpp อีกทางหนึ่ง: การสร้างการfile.cppประกาศ / คำจำกัดความที่มี (ไม่มีต้นแบบ) รวมถึงสิ่งmain.cppต่อไปนี้ ทั้งสองทำงานให้ฉัน ฉันไม่เห็นความแตกต่าง บางทีความเข้าใจในกระบวนการรวบรวมและเชื่อมโยงอาจช่วยได้บ้าง
18 c++  c  headers  linking  include 

1
ตำแหน่งที่จะวางคีย์ API: ส่วนหัว HTTP ที่กำหนดเอง VS ส่วนหัวการให้สิทธิ์ด้วยชุดรูปแบบที่กำหนดเอง
ฉันกำลังออกแบบ REST API โดยใช้การอนุญาต / การพิสูจน์ตัวตนผ่านทางคีย์ API ฉันพยายามคิดออกว่าเป็นที่ที่ดีที่สุดสำหรับสิ่งนั้นและพบว่าหลายคนแนะนำให้ใช้ส่วนหัว HTTP ที่กำหนดเองเช่นProjectName-Api-Keyเช่น: ProjectName-Api-Key: abcde แต่ก็เป็นไปได้และถูกต้องตามหลักอุดมการณ์ที่จะใช้Authorizationส่วนหัวกับชุดรูปแบบที่กำหนดเองเช่น: Authorization: ApiKey abcde ในทางกลับกันฉันพบการพิจารณาว่ารูปแบบการให้สิทธิ์ที่กำหนดเองอาจไม่คาดคิดและไม่ได้รับการสนับสนุนจากลูกค้าบางรายและนำไปสู่รหัสที่กำหนดเองอยู่ดีดังนั้นจึงเป็นการดีกว่าที่จะใช้ส่วนหัวที่กำหนดเอง คุณต้องการส่งคีย์ API ไปทางไหน

4
วิธีจัดระเบียบอินเทอร์เฟซและการนำไปใช้ใน C ++
ฉันได้เห็นว่ามีกระบวนทัศน์ที่แตกต่างกันใน C ++ เกี่ยวกับสิ่งที่จะเข้าไปในไฟล์ส่วนหัวและสิ่งที่จะ cpp ไฟล์ AFAIK ผู้คนส่วนใหญ่โดยเฉพาะผู้ที่อยู่ในพื้นหลัง C ทำ: foo.h class foo { private: int mem; int bar(); public: foo(); foo(const foo&amp;); foo&amp; operator=(foo); ~foo(); } foo.cpp #include foo.h foo::bar() { return mem; } foo::foo() { mem = 42; } foo::foo(const foo&amp; f) { mem = f.mem; } foo::operator=(foo …

4
ทำไมเราต้องเขียนไฟล์ส่วนหัว?
ก่อนที่คุณจะแสดงความคิดเห็นเกี่ยวกับคำสาปแช่งของคุณฉันรู้ว่า - นี่คือคำถาม nooby นี่เป็นครั้งแรกที่ฉันใช้ภาษา C ฉันเป็นนักศึกษาระดับปริญญาตรีที่กำลังเรียนรู้ Objective C สำหรับหลักสูตรวิทยาศาสตร์คอมพิวเตอร์เกี่ยวกับการพัฒนาโทรศัพท์มือถือ ฉันรู้ว่าในสภาพแวดล้อมทางวิชาการการพิจารณาในโลกแห่งความจริงจำนวนมากไม่จำเป็นเนื่องจากคุณกำลังสร้างโครงการขนาดเล็กทำงานในทีมขนาดเล็ก ฯลฯ แต่ศาสตราจารย์ของเราต้องการ - และ XCode รองรับ -. ไฟล์ส่วนหัว. h สำหรับทุกไฟล์การติดตั้ง. m สำหรับฉันดูเหมือนว่างานยุ่ง ฉันต้องให้แน่ใจว่าฉันคัดลอกทุกวิธีลายเซ็นและตัวแปรอินสแตนซ์ไปยังไฟล์อื่น ถ้าฉันเปลี่ยนไฟล์หนึ่งฉันต้องแน่ใจว่ามันสอดคล้องกับไฟล์อื่น ดูเหมือนจะเป็นเรื่องเล็ก ๆ น้อย ๆ ที่น่ารำคาญ แต่ฉันรู้ว่าจะต้องมีการใช้งานจริงสำหรับไฟล์ส่วนหัว คำตอบที่ดีจะตอบทั้ง: ไฟล์ส่วนหัวมีประโยชน์อะไรบ้างสำหรับไฟล์ที่ใช้งานไม่เหมาะ จุดประสงค์ของมันคืออะไร? เหตุใดเราในฐานะโปรแกรมเมอร์จึงต้องเขียนไฟล์ส่วนหัวด้วยตนเอง ดูเหมือนว่าพวกเขาสามารถสร้างขึ้นโดยอัตโนมัติได้อย่างง่ายดาย ขอบคุณล่วงหน้า!

3
การส่งโทเค็นการเข้าถึงผ่านทางส่วนหัว HTTP มีความปลอดภัยหรือไม่
นี่เป็นบริการเว็บสงบเป็นครั้งแรกและฉันกังวลเกี่ยวกับปัญหาด้านความปลอดภัย การส่งโทเค็นการเข้าถึงของฉันผ่านส่วนหัว HTTP ปลอดภัยหรือไม่ ตัวอย่างเช่น: POST /v1/i/resource HTTP/1.1 Content-Type: application/x-www-form-urlencoded Api-key: 5cac3297f0d9f46e1gh3k83881ba0980215cd71e Access_token: 080ab6bd49b138594ac9647dc929122adfb983c8 parameter1=foo&amp;parameter2=bar SSLการเชื่อมต่อทำมากกว่า นอกจากนี้สิ่งที่จะต้องมีการกำหนดเป็นscopeคุณลักษณะสำหรับทุกคนaccess token

3
มีอะไรพิเศษในวันที่ 26 กรกฎาคมและเพราะเหตุใดจึงใช้ในตัวอย่างสำหรับส่วนหัวหมดอายุบ่อยครั้ง
ฉันสังเกตว่าวันที่ 26 กรกฎาคม (วันเกิดของฉัน) ถูกใช้บ่อย ๆ ในตัวอย่าง PHP ต่างๆที่เกี่ยวข้องกับการป้องกันการแคช http โดยใช้Expiresส่วนหัวเช่น: /programming/12398714/cache-issue-with-private-networking-stream /programming/2833305/how-to-expire-page-in-php-when-user-logout http://expressionengine.com/archived_forums/viewthread/81945/ มีอะไรพิเศษในวันนั้น?
10 php  headers 

2
การใช้ส่วนหัวการให้สิทธิ์ที่กำหนดเองใน REST API
ฉันกำลังสร้าง REST api ที่ซึ่งลูกค้าได้รับการรับรองความถูกต้องโดยใช้ใบรับรองลูกค้า ลูกค้าในกรณีนี้ไม่ใช่ผู้ใช้รายบุคคล แต่เป็นเลเยอร์การนำเสนอบางประเภท ผู้ใช้จะได้รับการรับรองความถูกต้องโดยใช้วิธีการที่กำหนดเองและเป็นความรับผิดชอบของเลเยอร์การนำเสนอเพื่อดูว่าสิ่งนี้ทำถูกต้องแล้ว (หมายเหตุ: ฉันรู้ว่านี่ไม่ใช่วิธีการที่เหมาะสม แต่ api นั้นไม่ใช่สาธารณะ) ฉันต้องการส่งชื่อผู้ใช้สำหรับแต่ละคำขอ (ไม่ใช่รหัสผ่าน) แต่ฉันไม่แน่ใจว่าจะทำเช่นไร เป็นความคิดที่ดีที่จะใช้ส่วนหัวการให้อนุญาตหรือไม่
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.