m5@bobkat.UUCP (Mike McNally ) (11/09/87)
In article <150@fxgrp.UUCP> ljz@fxgrp.UUCP (Lloyd Zusman) writes: >with a slightly different approach you might want to try ... > >#define WITH(Name, Type, Struct) { Type *Name = &(Struct); >#define ENDWITH } > >Lloyd Zusman, Master Byte Software, Los Gatos, California >"We take things well in hand." cute >...!ames!fxgrp!ljz On a related but completely different topic: does anybody else think that a "typeof(thing)" would be useful? Seems like it would make a lot of macros easier and cleaner. What are the philosophical issues behind extending (or the reluctance to extend) the preprocessor? Would more powerful macro capabilities actually introduce a new world of obscurity to the language? Anyone wishing to respond to this should do so by mail if hopeful that I receive the thoughts; I only read news before I get enough caffeine into my body to avoid the deadly "rn" command. -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5 (214) 238-7474
dag@chinet.UUCP (11/10/87)
In article <3025@bobkat.UUCP> m5@bobkat.UUCP (Mike McNally (Man from Mars)) writes: > [ lots of stuff deleted ] >On a related but completely different topic: does anybody else think that >a "typeof(thing)" would be useful? Seems like it would make a lot of macros >easier and cleaner. What are the philosophical issues behind extending >(or the reluctance to extend) the preprocessor? Would more powerful macro >capabilities actually introduce a new world of obscurity to the language? > [ more stuff deleted ] >-- >Mike McNally, mercifully employed at Digital Lynx --- > [ Signiture deleted ] Though the typeof(thing) facility which is being described in the above article might be nice, it could not be a part of the preprocessor pass. A compiler that combines parsing with preprocessing in one pass might get away with it, but the preprocessor, as defined, knows nothing about the C language other than preprocessor things (like comments). It does not know what variables are declared, what types are defined, or even what types are. C programmers who have never worked with languages with built-in macro facilities (C has a preprocessor, which is different) don't seem to realize that the macro facilities available to the C programmer through the preprocessor are minimal. There is no real macro capability in the C language itself. The C preprocessor does not know the structure of a program or of the C language. A particular implimentation might, but that is not portable. (For a good example of a "High Level" language with a really powerful macro facilities (not a preprocessor), take a look at BLISS.) So the typeof operator (if you don't already know, sizeof is an operator and only requires the "()"s for grouping.) would be a language extension, not a preprocessor extension. This operator might be useful, but does not fit anywhere in the current language definition. The semantics would have to be similar to declaration of identifiers, but in int foo; "int" is not an operator. Maybe it could be restricted to typecast semantics, but this would reduce its usefulness. -- Daniel A. Glasser ----------------------------------------+---------------------------- Cheese is not a discipline! | ...!ihnp4!chinet!dag | ...!ihnp4!mwc!gorgon!dag | ...!ihnp4!chinet!gorgon!dag Disclaimer: I assume full responsibility for my opinions. If my employer knew of some of them, I'd be unemployed.
tainter@ihlpg.ATT.COM (Tainter) (11/10/87)
In article <3025@bobkat.UUCP>, m5@bobkat.UUCP (Mike McNally ) writes: > On a related but completely different topic: does anybody else think that > a "typeof(thing)" would be useful? Seems like it would make a lot of macros should be typeof(thingy) :-) > easier and cleaner. What are the philosophical issues behind extending > (or the reluctance to extend) the preprocessor? Would more powerful macro > capabilities actually introduce a new world of obscurity to the language? In case people get the wronge idead from this posting: typeof() is not a prepocessor implementable routine There is however a serious risk in these macros. There is no way to insure those local variables do not clash with names in the parameters. This makes typeof() of questional value, since it would encourage this risky coding style. > Mike McNally, mercifully employed at Digital Lynx --- --j.a.tainter
sitze@nmsu-ee.UUCP (Richard Sitze) (11/13/87)
Rather than changing C to include a typeof() operator, might I suggest that you look at C++. C++ would allow you to make the run-time decisions based on type with some control over the situation. Shar and enjoy <ras>
greg@utcsri.UUCP (11/16/87)
In article <1827@chinet.UUCP> dag@chinet.UUCP (Daniel A. Glasser) writes: >Though the typeof(thing) facility which is being described in the above >article might be nice, it could not be a part of the preprocessor pass. True. >So the typeof operator (if you don't already know, sizeof is an operator >and only requires the "()"s for grouping.) would be a language extension, >not a preprocessor extension. This operator might be useful, but does not >fit anywhere in the current language definition. The semantics would >have to be similar to declaration of identifiers, but in > > int foo; > >"int" is not an operator. Maybe it could be restricted to typecast >semantics, but this would reduce its usefulness. > How about this: *type-specifier*: char short ... typeof ( *expression* ) << add this ( parens probably essential for parsibility ) typeof ( *type-name* ) << and this *type-name*: << one of many productions missing from K&R *type-specifier* *abstract-declarator* (type-name is anything you can put in parens to get a cast, or give to sizeof as a type). I would say it fits in pretty cleanly. The second case "typeof( *type-name* )" seems a little redundant, but it allows this: typeof( int *(*)()) x,y,z; instead of int *(*x)(), *(*y)(), *(*z)(); or typedef int *(*pfpi)(); pfpi x,y,z; Which might be very handy for certain preprocessers producing C output. #define new(ptr) ((ptr) = (typeof (ptr))malloc( sizeof( *(ptr) ))) -- ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Have vAX, will hack...