| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
| agent@drrob1.com: Nov 10 05:12PM -0500 >typedef FILE* FileHandle; >typedef char* PointerToCharType; >typedef char* CharPointerType; Thanks to all who replied. I now understand that I needed const char *. For some reason, const CharPointerType did not do what I hoped. I have noticed that my macros offend experienced C-ish programmers. I am not an experienced C-ish programmer, but come to this after many years of working with other languages. What seems natural to my eye is insulting to many. This is why I first posted code without my macros. But I missed a few of my macro references and that made some mad and not interested in helping. So it goes. --rob |
| Ian Collins <ian-news@hotmail.com>: Nov 11 11:19AM +1300 > On Mon, 10 Nov 2014 08:04:33 -0500, agent@drrob1.com wrote: <snip> > Thanks to all who replied. I now understand that I needed > const char *. For some reason, const CharPointerType did not do what > I hoped. This a a good, if not compelling, reason not to use such macros and typedefs! "const CharPointerType" qualifies CharPointerType as const, not what it is pointing to. > am not an experienced C-ish programmer, but come to this after many > years of working with other languages. What seems natural to my eye > is insulting to many. If you are going to learn C, drop the macros sooner rather than later they don't help and can (and did) lead to confusion. -- Ian Collins |
| Keith Thompson <kst-u@mib.org>: Nov 10 02:50PM -0800 > On Mon, 10 Nov 2014 08:04:33 -0500, agent@drrob1.com wrote: [snip] >>#define NE != >>#define BEGIN { >>#define END } [...] > am not an experienced C-ish programmer, but come to this after many > years of working with other languages. What seems natural to my eye > is insulting to many. I don't think they're offensive or insulting. I just think they're a really bad idea. Consider this. One might argue that a language that uses "EQ", "NE", "BEGIN", and "END" rather than C and C++'s "==", "!=", "{", and "}" is better (more readable, more maintainable) than C or C++. I wouldn't necessarily agree, but it's a perfectly valid opinion. But that's not what those macros give you. Instead, they apply a thin layer on top of standard C syntax. To understand a program written using those macros, someone would have to understand *both* standard C syntax *and* the macros (which I'll guess are not documented anywhere other than in the header file that defines them). -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> 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" |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 10 11:26PM >>This is the code I actually use, with my macros and all. I tried to >>remove these macros before posting, but it seems that I did not do >>that correctly. <snip> >>#define ENDIF } >>#define ENDFOR } >>#define ENDCASE } <snip similar> > Thanks to all who replied. I now understand that I needed > const char *. For some reason, const CharPointerType did not do what > I hoped. The reason is that the const, here, applies to the type you defined as CharPointerType -- it makes the pointer const. const char * is a pointer to characters that are const. > am not an experienced C-ish programmer, but come to this after many > years of working with other languages. What seems natural to my eye > is insulting to many. I'm not offended by them. I think they are a source of trouble. Nothing checks them; new readers need to learn them; everyone does it differently; the superficial similarity to other languages can be misleading; ... <snip> -- Ben. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 10 11:44PM +0100 On 10.11.14 22.02, Öö Tiib wrote: > "b" from scope 5 that it hides. You can modify name "b" > in lookup table and memorize to restore the scope 5 "b" > to power at end of scope 7. This was my first idea, too. But I dropped it because it makes the code for modification on the lookup table somewhat complicated. Symbols could be legally redefined in the same scope. It is only one of my extensions to protect symbols against redefinition inside the same (maybe global) scope. In this case I must not put the current symbol value into the recovery container, of course. > classes, namespaces and ADL) then it must be is > even more simple. I see no reason why you should > have so complex, multi-layer lookup table on that case. Hmm, maybe I should rethink about the above approach. > For assembler it likely does not matter. Assembler > presumably does not preprocess into million line monsters > like C++. No, obviously not. The expansion factor is only in the order of 2 to 4. I.e. 1 line of source emits 2 to 4 instructions depending on whether you count comment lines as well or not. > However ... simplicity is also quality on its > own. Indeed. > Why you should do several lookups? It is simply easier to implement. Each level start with its own empty dictionary. Each modifying directive applies to the deepmost dictionary for local operations or on the outermost dictionary for global changes. At the end of the scope I simply do a pop_back and the previous state is restored with exception of the global changes. From the code's point of view there are several locations where the dictionaries are modified with different directives. But there is only one read access: the instruction parser for macros and the expression parser for anything else. > Is there some > diagnostic about defects that you want to improve > somehow with it? I think printing meaningful diagnostic messages is easily possible with any of the discussed data models. Marcel |
| Rosario193 <Rosario@invalid.invalid>: Nov 10 11:10PM +0100 On Mon, 10 Nov 2014 15:15:22 -0600, Robert Hutchings wrote: >> but if i have to choose [i not use private]: >> public: >> Record *a; u32 isize; i forgot to write the size index so at end of construction "a" point to space for number isize Record >>> } >Okay, when you said "one u32 one index" are you talking about a Struct? one array of structs Record so a[0] would be the first record and a[isize-1] the last record Record... |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment