ผลกระทบของคำสำคัญภายนอกในฟังก์ชั่น C

ใน C ฉันไม่ได้สังเกตเห็นผลกระทบใด ๆ ของexternคำหลักที่ใช้ก่อนการประกาศฟังก์ชัน ตอนแรกฉันคิดว่าเมื่อกำหนดextern int f();ไฟล์เดียวบังคับให้คุณใช้มันนอกขอบเขตของไฟล์ อย่างไรก็ตามฉันพบว่าทั้งสอง:

extern int f();
int f() {return 0;}

และ

extern int f() {return 0;}

รวบรวมได้ดีไม่มีคำเตือนจาก gcc ผมใช้gcc -Wall -ansi; มันจะไม่ยอมรับ//ความคิดเห็นด้วยซ้ำ

มีผลกระทบใด ๆ สำหรับการใช้extern ก่อนหน้านิยามฟังก์ชันหรือไม่? หรือเป็นเพียงแค่คีย์เวิร์ดเสริมที่ไม่มีผลข้างเคียงสำหรับฟังก์ชั่น

ในกรณีหลังนี้ฉันไม่เข้าใจว่าทำไมนักออกแบบมาตรฐานถึงเลือกที่จะทิ้งไวยากรณ์ด้วยคำหลักที่ไม่จำเป็น

แก้ไข:ชี้แจงฉันรู้ว่ามีการใช้งานสำหรับexternตัวแปร แต่ฉันก็แค่ถามเกี่ยวกับexternในฟังก์ชั่น

เรามีสองไฟล์ foo.c และ bar.c

นี่คือ foo.c

#include <stdio.h>

volatile unsigned int stop_now = 0;
extern void bar_function(void);

int main(void)
{
  while (1) {
     bar_function();
     stop_now = 1;
  }
  return 0;
}

ตอนนี้ที่นี่คือ bar.c

#include <stdio.h>

extern volatile unsigned int stop_now;

void bar_function(void)
{
   while (! stop_now) {
      printf("Hello, world!\n");
      sleep(30);
   }
}

อย่างที่คุณเห็นเราไม่มีส่วนหัวที่ใช้ร่วมกันระหว่าง foo.c และ bar.c อย่างไรก็ตาม bar.c ต้องการบางสิ่งที่ประกาศเป็น foo.c เมื่อเชื่อมโยงและ foo.c ต้องการฟังก์ชันจาก bar.c เมื่อเชื่อมโยง

ด้วยการใช้ 'extern' คุณกำลังบอกคอมไพเลอร์ว่าสิ่งใดก็ตามที่ตามมามันจะพบได้ (ไม่คงที่) ในเวลาลิงก์ อย่าจองอะไรไว้ในบัตรผ่านปัจจุบันเนื่องจากจะพบในภายหลัง ฟังก์ชั่นและตัวแปรได้รับการปฏิบัติอย่างเท่าเทียมกันในเรื่องนี้

มันมีประโยชน์มากถ้าคุณต้องการแชร์ระดับโลกระหว่างโมดูลและไม่ต้องการใส่ / เริ่มต้นในส่วนหัว

ในทางเทคนิคแล้วทุกฟังก์ชั่นในส่วนหัวของ public library คือ 'extern' แต่การทำ label มันให้มีประโยชน์น้อยมากและไม่มีประโยชน์ขึ้นอยู่กับคอมไพเลอร์ คอมไพเลอร์ส่วนใหญ่สามารถหาได้ด้วยตัวเอง อย่างที่คุณเห็นฟังก์ชั่นเหล่านั้นถูกนิยามไว้ที่อื่น

ในตัวอย่างด้านบน main () จะพิมพ์ hello world เพียงครั้งเดียว แต่ยังคงป้อน bar_function () โปรดทราบว่า bar_function () จะไม่กลับมาในตัวอย่างนี้ (เนื่องจากเป็นเพียงตัวอย่างง่ายๆ) เพียงแค่จินตนาการว่า stop_now กำลังถูกแก้ไขเมื่อมีการให้บริการสัญญาณ (ด้วยเหตุนี้ระเหยได้) หากนี่ดูเหมือนจะไม่เพียงพอ

Externs นั้นมีประโยชน์มากสำหรับสิ่งต่างๆเช่นตัวจัดการสัญญาณ, mutex ที่คุณไม่ต้องการใส่ไว้ในส่วนหัวหรือโครงสร้างเป็นต้นคอมไพเลอร์ส่วนใหญ่จะปรับให้เหมาะสมเพื่อให้แน่ใจว่าพวกเขาจะไม่จองหน่วยความจำใด ๆ สำหรับวัตถุภายนอก จะทำการจองในโมดูลที่มีการกำหนดวัตถุ อย่างไรก็ตามมีจุดเล็ก ๆ น้อย ๆ ในการระบุคอมไพเลอร์สมัยใหม่เมื่อสร้างต้นแบบฟังก์ชั่นสาธารณะ

หวังว่าจะช่วย :)

เท่าที่ฉันจำได้มาตรฐานการประกาศฟังก์ชั่นทั้งหมดถือเป็น "extern" โดยค่าเริ่มต้นดังนั้นจึงไม่จำเป็นต้องระบุอย่างชัดเจน

ไม่ได้ทำให้คำหลักนี้ไร้ประโยชน์เพราะมันสามารถใช้กับตัวแปรได้ (และในกรณีนี้ - มันเป็นทางออกเดียวในการแก้ปัญหาการเชื่อมโยง) แต่ด้วยฟังก์ชั่น - ใช่มันเป็นตัวเลือก

คุณต้องแยกความแตกต่างระหว่างแนวคิดที่แยกกันสองแนวคิด: นิยามฟังก์ชันและการประกาศสัญลักษณ์ "extern" เป็นตัวดัดแปลงการเชื่อมโยงคำใบ้ของคอมไพเลอร์เกี่ยวกับตำแหน่งที่มีการอ้างถึงสัญลักษณ์หลังจากนั้น (คำใบ้คือ "ไม่ใช่ที่นี่")

ถ้าฉันเขียน

extern int i;

ในขอบเขตไฟล์ (นอกบล็อกฟังก์ชั่น) ในไฟล์ C จากนั้นคุณกำลังพูดว่า "ตัวแปรอาจถูกกำหนดที่อื่น"

extern int f() {return 0;}

เป็นการประกาศฟังก์ชัน f และนิยามของฟังก์ชัน f คำจำกัดความในกรณีนี้มากเกินไปที่จะขับ extern

extern int f();
int f() {return 0;}

เป็นการประกาศครั้งแรกตามด้วยคำจำกัดความ

การใช้externผิดถ้าคุณต้องการประกาศและกำหนดตัวแปรขอบเขตไฟล์พร้อมกัน ตัวอย่างเช่น,

extern int i = 4;

จะให้ข้อผิดพลาดหรือคำเตือนขึ้นอยู่กับคอมไพเลอร์

การใช้งานexternจะมีประโยชน์หากคุณต้องการหลีกเลี่ยงการนิยามตัวแปรอย่างชัดเจน

ให้ฉันอธิบาย:

สมมติว่าไฟล์ ac มี:

#include "a.h"

int i = 2;

int f() { i++; return i;}

ไฟล์ ah รวมถึง:

extern int i;
int f(void);

และไฟล์ bc มี:

#include <stdio.h>
#include "a.h"

int main(void){
    printf("%d\n", f());
    return 0;
}

extern ในส่วนหัวมีประโยชน์เพราะมันบอกคอมไพเลอร์ในระหว่างขั้นตอนการเชื่อมโยง "นี่เป็นการประกาศและไม่ใช่คำจำกัดความ" หากฉันลบบรรทัดใน ac ซึ่งกำหนด i ให้จัดสรรพื้นที่สำหรับมันและกำหนดค่าให้กับมันโปรแกรมควรจะคอมไพล์ด้วยการอ้างอิงที่ไม่ได้กำหนด สิ่งนี้บอกผู้พัฒนาว่าเขาได้อ้างถึงตัวแปร แต่ยังไม่ได้กำหนด หากตรงกันข้ามฉันละเว้นคำหลัก "extern" และลบint i = 2บรรทัดโปรแกรมยังคงคอมไพล์ - ฉันจะถูกกำหนดด้วยค่าเริ่มต้นเป็น 0

ตัวแปรขอบเขตไฟล์ถูกกำหนดโดยปริยายด้วยค่าเริ่มต้นที่ 0 หรือ NULL หากคุณไม่ได้กำหนดค่าให้กับพวกเขาอย่างชัดเจน - ซึ่งแตกต่างจากตัวแปรขอบเขตบล็อกที่คุณประกาศที่ด้านบนของฟังก์ชั่น คำหลักภายนอกหลีกเลี่ยงคำจำกัดความที่ชัดเจนนี้และช่วยหลีกเลี่ยงข้อผิดพลาด

สำหรับฟังก์ชั่นในการประกาศฟังก์ชั่นคำหลักซ้ำซ้อนแน่นอน ประกาศฟังก์ชั่นไม่ได้มีความหมายโดยนัย

externคำหลักที่จะใช้เวลาในรูปแบบที่แตกต่างกันขึ้นอยู่กับสภาพแวดล้อม หากมีการประกาศexternคำหลักจะใช้การเชื่อมโยงตามที่ระบุไว้ก่อนหน้าในหน่วยการแปล ในกรณีที่ไม่มีการประกาศดังกล่าวให้externระบุการเชื่อมโยงภายนอก

static int g();
extern int g(); /* g has internal linkage */

extern int j(); /* j has tentative external linkage */

extern int h();
static int h(); /* error */

นี่คือย่อหน้าที่เกี่ยวข้องจาก C99 ฉบับร่าง (n1256):

6.2.2 การเชื่อมโยงของตัวระบุ

[ ... ]

4สำหรับตัวระบุที่ประกาศพร้อมตัวระบุคลาสการเก็บข้อมูลภายนอกในขอบเขตที่การประกาศก่อนหน้าของตัวระบุนั้นปรากฏให้เห็น 23) หากการประกาศก่อนหน้าระบุการเชื่อมโยงภายในหรือภายนอกการเชื่อมโยงของตัวระบุที่การประกาศในภายหลังจะเหมือนกัน ตามที่ระบุไว้ในประกาศก่อนหน้า หากไม่เห็นการประกาศก่อนหน้านี้หรือหากการประกาศก่อนหน้าระบุว่าไม่มีการเชื่อมโยงตัวระบุนั้นจะมีการเชื่อมโยงภายนอก

5หากการประกาศของตัวระบุสำหรับฟังก์ชั่นไม่มีตัวระบุระดับการจัดเก็บการเชื่อมโยงของมันจะถูกกำหนดว่าราวกับว่ามันถูกประกาศด้วยตัวระบุระดับชั้นเก็บข้อมูลภายนอก หากการประกาศของตัวระบุสำหรับวัตถุที่มีขอบเขตไฟล์และไม่มีตัวระบุระดับการจัดเก็บการเชื่อมโยงของมันคือภายนอก

ฟังก์ชันอินไลน์มีกฎพิเศษเกี่ยวกับความexternหมาย (โปรดทราบว่าฟังก์ชั่นแบบอินไลน์เป็นส่วนขยาย C99 หรือ GNU ซึ่งไม่ได้อยู่ในต้นฉบับ C

สำหรับฟังก์ชั่นที่ไม่ใช่แบบอินไลน์externไม่จำเป็นต้องใช้เนื่องจากเป็นค่าเริ่มต้น

โปรดทราบว่ากฎสำหรับ C ++ นั้นแตกต่างกัน ยกตัวอย่างเช่นextern "C"เป็นสิ่งจำเป็นในการประกาศ C ++ ของฟังก์ชั่นซีที่คุณจะโทรจาก C ++ inlineและมีกฎระเบียบที่แตกต่างกันเกี่ยวกับ

IOW ภายนอกคือซ้ำซ้อนและไม่ทำอะไรเลย

นั่นคือเหตุผล 10 ปีต่อมา:

• เครื่องมือการแปลงรหัสเช่นCoccinelleจะมีแนวโน้มที่จะตั้งค่าสถานะexternในการประกาศฟังก์ชั่นสำหรับการลบ;
• codebase git/gitดังนี้สรุปและลบออกexternจากรหัส (สำหรับ Git 2.22, Q2 2019)

ดูคอมมิท ad6dad0 , ยอมรับ b199d71 , ยอมรับ 5545442 (29 เม.ย. 2019) โดยDenton Liu ( Denton-L) )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 4aeeef3 , 13 พฤษภาคม 2019)}

*.[ch]: ลบออกexternจากการประกาศฟังก์ชั่นโดยใช้spatch

มีการผลักที่จะลบ externจากการประกาศฟังก์ชัน

ลบอินสแตนซ์บางส่วนของ " extern" สำหรับการประกาศฟังก์ชันที่ Coccinelle จับ
โปรดทราบว่า Coccinelle มีปัญหาในการประมวลผลฟังก์ชั่นด้วย__attribute__หรือ varargs ดังนั้นบางอย่างexternการประกาศจะถูกทิ้งไว้ข้างหลังเพื่อจัดการกับแพทช์ในอนาคต

นี่คือแพทช์ Coccinelle ที่ใช้:

  @@
    type T;
    identifier f;
    @@
    - extern
    T f(...);

และมันก็ทำงานด้วย:

  $ git ls-files \*.{c,h} |
    grep -v ^compat/ |
    xargs spatch --sp-file contrib/coccinelle/noextern.cocci --in-place

สิ่งนี้ไม่ได้ตรงไปตรงมาเสมอแม้ว่า:

ดูกระทำ 7027f50 (4 กันยายน 2019) โดยDenton หลิว (Denton-L )
^{(ผสานโดยDenton Liu - Denton-L- in 7027f50 , 05 Sep 2019)}

compat/*.[ch]: ลบออกexternจากการประกาศฟังก์ชั่นโดยใช้ spatch

ใน 5545442 ( *.[ch]: ลบexternจากการประกาศฟังก์ชั่นโดยใช้ spatch, 2019-04-29, Git v2.22.0-rc0) เราลบ externs ออกจากการประกาศฟังก์ชั่นการใช้spatchแต่เราตั้งใจแยกไฟล์ภายใต้compat/เนื่องจากบางส่วนถูกคัดลอกโดยตรงจากต้นน้ำและเราควรหลีกเลี่ยง การปั่นเพื่อให้การรวมการอัพเดทในอนาคตด้วยตนเองจะง่ายขึ้น

ในการคอมมิชชันล่าสุดเรากำหนดไฟล์ที่นำมาจากอัปสตรีมเพื่อให้เราสามารถแยกไฟล์และรัน spatchบนส่วนที่เหลือ

นี่คือแพทช์ Coccinelle ที่ใช้:

@@
type T;
identifier f;
@@
- extern
  T f(...);

และมันก็ทำงานด้วย:

$ git ls-files compat/\*\*.{c,h} |
    xargs spatch --sp-file contrib/coccinelle/noextern.cocci --in-place
$ git checkout -- \
    compat/regex/ \
    compat/inet_ntop.c \
    compat/inet_pton.c \
    compat/nedmalloc/ \
    compat/obstack.{c,h} \
    compat/poll/

Coccinelle มีปัญหาในการจัดการ__attribute__และ varargs ดังนั้นเราจึงดำเนินการต่อไปนี้เพื่อให้แน่ใจว่าไม่มีการเปลี่ยนแปลงที่เหลืออยู่:

$ git ls-files compat/\*\*.{c,h} |
    xargs sed -i'' -e 's/^\(\s*\)extern \([^(]*([^*]\)/\1\2/'
$ git checkout -- \
    compat/regex/ \
    compat/inet_ntop.c \
    compat/inet_pton.c \
    compat/nedmalloc/ \
    compat/obstack.{c,h} \
    compat/poll/

โปรดทราบว่าด้วย Git 2.24 (ไตรมาสที่ 4 ปี 2562) จะมีการปลอมแปลงใด ๆ externจะลดลง

ดูกระทำ 65904b8 (30 กันยายน 2019) โดยเอมิลี่ Shaffer (nasamuffin )
ช่วยโดย: เจฟฟ์คิง (peff )
ดูกระทำ 8464f94 (21 กันยายน 2019) โดยDenton หลิว (Denton-L )
ช่วยโดย: เจฟฟ์คิง (peff )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 59b19bc , 7 ตุลาคม 2019)}

promisor-remote.h: ลดลงexternจากการประกาศฟังก์ชั่น

ในระหว่างการสร้างไฟล์นี้, externทุกครั้งที่มีการประกาศฟังก์ชั่นใหม่ที่ได้รับการแนะนำให้รู้จักก็รวมถึง
อย่างไรก็ตามเริ่มจาก5545442 ( *.[ch]: ลบexternจากการประกาศฟังก์ชั่นการใช้spatch2019-04-29, Git v2.22.0-rc0) เราได้พยายามป้องกันไม่ให้มีการใช้งานภายนอกในการประกาศฟังก์ชั่นเพราะมันไม่จำเป็น

ลบexterns ปลอมเหล่านี้

externแจ้งคำหลักคอมไพเลอร์ที่ว่าฟังก์ชั่นหรือตัวแปรที่มีการเชื่อมโยงภายนอก - ในคำอื่น ๆ ว่ามันมองเห็นได้จากไฟล์อื่น ๆ มากกว่าหนึ่งในการที่จะมีการกำหนด ในแง่นี้มันมีความหมายตรงกันข้ามกับstaticคำหลัก มันค่อนข้างแปลกที่จะใส่externในช่วงเวลาของการกำหนดเนื่องจากไม่มีไฟล์อื่น ๆ ที่จะมีความสามารถในการมองเห็นของความหมาย (หรือมันจะส่งผลในหลายคำนิยาม) โดยปกติคุณใส่externคำประกาศในบางจุดด้วยการมองเห็นภายนอก (เช่นไฟล์ส่วนหัว) และใส่คำจำกัดความที่อื่น

ประกาศฟังก์ชั่นภายนอกหมายความว่าคำจำกัดความของมันจะได้รับการแก้ไขในเวลาของการเชื่อมโยงไม่ได้ในระหว่างการรวบรวม

ซึ่งแตกต่างจากฟังก์ชั่นทั่วไปซึ่งไม่ได้ประกาศภายนอกมันสามารถกำหนดได้ในไฟล์ต้นฉบับใด ๆ (แต่ไม่ได้อยู่ในไฟล์ต้นฉบับหลายไฟล์มิฉะนั้นคุณจะได้รับข้อผิดพลาด linker ที่บอกว่าคุณได้กำหนดหลายฟังก์ชั่น) รวมถึง ซึ่งมันถูกประกาศภายนอกดังนั้นในกรณีที่ linker แก้ไขคำนิยามฟังก์ชั่นในไฟล์เดียวกัน

ฉันไม่คิดว่าการทำเช่นนี้จะมีประโยชน์มาก แต่การทำการทดลองแบบนี้จะช่วยให้เข้าใจได้ดีขึ้นว่าคอมไพเลอร์และตัวเชื่อมโยงของภาษาทำงานอย่างไร

เหตุผลที่มันไม่มีผลกระทบเป็นเพราะในเวลาลิงค์ลิงเกอร์พยายามที่จะแก้ไขคำนิยามภายนอก (ในกรณีของคุณextern int f()) ไม่สำคัญว่าจะพบไฟล์เดียวกันหรือไฟล์อื่นตราบใดที่พบ

หวังว่านี่จะตอบคำถามของคุณ