Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Compiler design in C? Date: Thu, 10 Nov 2016 14:28:26 -0800 Organization: None to speak of Lines: 93 Message-ID: References: <3e47c9bc-1c0a-40dc-9dc3-92e88ace6c31@googlegroups.com> <87lgwrzvqt.fsf@gmail.com> <87lgwrdaiu.fsf@gmail.com> <87shqz7n08.fsf@gmail.com> <362fc76e-f4aa-4c66-abfd-ea4e8d87da47@googlegroups.com> <87y40ruk7u.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="19f6983d7adc6a70870491918dcdf9b1"; logging-data="25197"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PtNhDlhMeUP6rMcjObvl0" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:npjbEW1LYu1ypGBWyL9OJPF63fY= sha1:rZLu5IwRUQWKmQf1mM9UVy0frt8= Xref: csiph.com comp.lang.c:96354 jacobnavia writes: > Le 10/11/2016 á 22:35, Keith Thompson a écrit : >> jacobnavia writes: >>> Le 10/11/2016 á 21:57, Gareth Owen a écrit : >>>> I actually considered mentioning this, but decided against it. >>> >>> And the reason was? >>> >>> Why is the pre-processor such an "evil"? >>> >>> Look at this for instance: (this is the "valarraygen.c file of the ccl) >>> >>> 81 static int ResizeTo(ValArray *AL,size_t newcapacity) >>> 82 { >>> 83 ElementType *oldcontents; >>> 84 >>> 85 if (AL->capacity == newcapacity) return 0; >>> 86 oldcontents = AL->contents; >>> 87 AL->contents = AL->Allocator->realloc(AL->contents,newcapacity >>> * sizeof(ElementType)); >>> 88 if (AL->contents == NULL) { >>> 89 AL->contents = oldcontents; >>> 90 return NoMemory("ResizeTo"); >>> 91 } >>> 92 AL->capacity = newcapacity; >>> 93 AL->timestamp++; >>> 94 return 1; >>> 95 } >>> >>> ElementType is a macro. A plain #define with the name of the underlying >>> type. >>> >>> I find it OK, you can do a lot of things with the preprocessor. >> >> I'm probably missing some context here, but what is the advantage of >> making ElementType a macro rather than a typedef? >> >> In particular, if ElementType is `int[3]`, then >> ElementType *oldcontents; >> is a syntax error. > > Look, you are effectively missing some context here. Yes, as I acknowledged. > This function is > included in a small C file that > > #define ElementType MyPieceOfData > > where "MyPieceOfData" can be a type you use whatever. > > Then you compile your small file > #include "valarraygen.c" > > and your type will have a vector-array for it, complete with a standard > interface. You can put the code in a library and only the functions that > you use will get included in the final executable. > > You point out that this doesn't work with > > #define MyElementType int[3] > > Yes. That doesn't work. You can then do: > > typedef MyPieceOfData int[3]; > > And then > > #define ElementType MyPieceOfData > > Not very difficult Mr Thompson. I never said it was very difficult. I still question whether it's better than using a typedef in the first place. You want me to write: #define ElementType MyPieceOfData #include "valarraygen.c" I'd prefer to write: typedef MyPieceOfData ElementType #include "valarraygen.c" and as far as I can tell it should still work. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"