In C language exist the type 'enum'.
An example,
typedef enum { btZero, btStatic, btActive } BLOCK_TYPE;
Does an equivalent thing (in Lisp) exists??
There is a way in order to make the type "Enum"?
Thanks in advance.
DaveNlp
"DaveNlp" <(NOSPAM)·········@iol.it> wrote in message news:<························@twister1.libero.it>...
> In C language exist the type 'enum'.
> An example,
>
> typedef enum { btZero, btStatic, btActive } BLOCK_TYPE;
Note that this is quite a weak construct in C. You can write:
BLOCK_TYPE x = 42; /* valid */
So the BLOCK_TYPE has mere documentary value, and btZero and friends
are merely integer constants.
> Does an equivalent thing (in Lisp) exists??
Lisp has integer constants, if you want symbolic names for particular
integer values. You can define your own types, for instance with
DEFTYPE. With these tools you can do just about what C enum does.
(defconstant *bt-zero* 0)
(defconstant *bt-static* 1)
(defconstant *bt-active* 2)
(defun block-type-p (x)
(member x '(#.*bt-zero* #.*bt-static* #.*bt-active*)))
(deftype block-type ()
`(satisfies block-type-p))
Now you can for instance check whether some number is of the type
BLOCK-TYPE:
(typep 42 'block-type) ==> NIL
(typep 2 'block-type) ==> T
> (defconstant *bt-zero* 0)
> (defconstant *bt-static* 1)
> (defconstant *bt-active* 2)
Kaz:
Any reason you used stars as the delimiters, rather than a separate
convention such as +bt-zero+ ?
I find the asterisks too strong an indicator, and think it is important
to separate the "specialness" of special variables. After all, one won't be
dynamically rebinding the value of *bt-zero*.
···@ashi.footprints.net (Kaz Kylheku) writes:
> (defconstant *bt-zero* 0)
> (defconstant *bt-static* 1)
> (defconstant *bt-active* 2)
>
> (defun block-type-p (x)
> (member x '(#.*bt-zero* #.*bt-static* #.*bt-active*)))
Better wrap an EVAL-WHEN around the DEFCONSTANT forms, to ensure
the constants will be available at read time.
···@ashi.footprints.net (Kaz Kylheku) writes:
> Lisp has integer constants, if you want symbolic names for particular
> integer values. You can define your own types, for instance with
> DEFTYPE. With these tools you can do just about what C enum does.
>
> (defconstant *bt-zero* 0)
> (defconstant *bt-static* 1)
> (defconstant *bt-active* 2)
>
> (defun block-type-p (x)
> (member x '(#.*bt-zero* #.*bt-static* #.*bt-active*)))
>
> (deftype block-type ()
> `(satisfies block-type-p))
>
> Now you can for instance check whether some number is of the type
> BLOCK-TYPE:
>
> (typep 42 'block-type) ==> NIL
> (typep 2 'block-type) ==> T
Is the following a reasonable way of packing this up?
(defmacro defenum (enum-name &rest bindings)
(let ((val 0)
(value-set '()))
`(eval-when (:compile-toplevel :load-toplevel :execute)
,@(loop for binding in bindings
collect (multiple-value-bind (key value)
(cond ((atom binding) (values binding val))
((atom (cdr binding)) (values (car binding)
(cdr binding)))
(t (values (car binding) (cadr binding))))
(check-type value integer)
(check-type key symbol)
(setq val (1+ value))
(push value value-set)
`(defconstant ,key ,value)))
(deftype ,enum-name () '(member ,@(nreverse value-set))))))
(macroexpand-1 '(defenum foo a b (c . 4) d (e 81) f g h))
=>
(EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
(DEFCONSTANT A 0)
(DEFCONSTANT B 1)
(DEFCONSTANT C 4)
(DEFCONSTANT D 5)
(DEFCONSTANT E 81)
(DEFCONSTANT F 82)
(DEFCONSTANT G 83)
(DEFCONSTANT H 84)
(DEFTYPE FOO () '(MEMBER 0 1 4 5 81 82 83 84)))
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
"DaveNlp" <(NOSPAM)·········@iol.it> writes:
> In C language exist the type 'enum'.
> An example,
>
> typedef enum { btZero, btStatic, btActive } BLOCK_TYPE;
>
> Does an equivalent thing (in Lisp) exists?? There is a way in order
> to make the type "Enum"?
Depends on how you want to use it. You could do
(deftype block-type ()
`(member bt-zero bt-static bt-active))
and then, for instance
CL-USER 5 > (typep 'bt-static 'block-type)
T
CL-USER 6 > (typep 42 'block-type)
NIL
If you want them to have numerical values, too, you could bind the
symbols, or push something onto their plists with (SETF GET) or some
such.
Regards,
--
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID #xEEFBA4AF
···@cartan.de (Nils G�sche) writes:
> "DaveNlp" <(NOSPAM)·········@iol.it> writes:
>
> > In C language exist the type 'enum'.
> > An example,
> >
> > typedef enum { btZero, btStatic, btActive } BLOCK_TYPE;
> >
> > Does an equivalent thing (in Lisp) exists?? There is a way in order
> > to make the type "Enum"?
>
> Depends on how you want to use it. You could do
>
> (deftype block-type ()
> `(member bt-zero bt-static bt-active))
>
> and then, for instance
>
> CL-USER 5 > (typep 'bt-static 'block-type)
> T
>
> CL-USER 6 > (typep 42 'block-type)
> NIL
>
> If you want them to have numerical values, too, you could bind the
> symbols, or push something onto their plists with (SETF GET) or some
> such.
For finite, non-extensible namespaces, I generally recommend keywords.
Almost always I'd translate an enum type into
(member :bt-zero :bt-static :bt-active)
since (a) it's easier to reference without symbol import/export issues
from a variety of packages and (b) it's in no danger of getting the meaning
of MY:BT-ZERO confused with YOUR:BT-ZERO.
In article <···············@shell01.TheWorld.com>, ······@nhplace.com
says...
>
> For finite, non-extensible namespaces, I generally recommend keywords.
> Almost always I'd translate an enum type into
>
> (member :bt-zero :bt-static :bt-active)
>
> since (a) it's easier to reference without symbol import/export issues
> from a variety of packages and (b) it's in no danger of getting the meaning
> of MY:BT-ZERO confused with YOUR:BT-ZERO.
I have a newbie question with regard to this practice: In common
implementations of CL, is there any reason to be concerned about
"polluting" the keyword package with a large number of symbols?
Dan Muller <·········@sneakemail.com> writes:
> I have a newbie question with regard to this practice: In common
> implementations of CL, is there any reason to be concerned about
> "polluting" the keyword package with a large number of symbols?
I don't think this is a problem because keyword symbols always
evaluate to themselves. You can't assign them values as variables so
different bits of code won't have clashes over their use.
--
Fred Gilham ······@csl.sri.com
The rage of dance and style that swept the country in the late '70s
crumbled from serious backlash as disco freaks seemed to finally wake
up and realize what they were wearing. -- Michael Okwu
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> Dan Muller <·········@sneakemail.com> writes:
>
>> I have a newbie question with regard to this practice: In common
>> implementations of CL, is there any reason to be concerned about
>> "polluting" the keyword package with a large number of symbols?
>
> I don't think this is a problem because keyword symbols always
> evaluate to themselves. You can't assign them values as variables so
> different bits of code won't have clashes over their use.
(defun :foo (x) (1+ x)) ;-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
In article <··············@snapdragon.csl.sri.com>,
······@snapdragon.csl.sri.com says...
>
> Dan Muller <·········@sneakemail.com> writes:
>
> > I have a newbie question with regard to this practice: In common
> > implementations of CL, is there any reason to be concerned about
> > "polluting" the keyword package with a large number of symbols?
>
> I don't think this is a problem because keyword symbols always
> evaluate to themselves. You can't assign them values as variables so
> different bits of code won't have clashes over their use.
I wasn't concerned about this aspect of it, since it didn't occur to me
to misuse keywords this way. I was curious about symbol lookup overhead
as the number of keywords increases -- I should have been more specific
in my question.
The other answers I got seem to indicate that the question doesn't have
a very clear answer. :-) Probably very implementation-dependent.
In article <·························@news1.toast.net>,
Dan Muller <·········@sneakemail.com> wrote:
> I wasn't concerned about this aspect of it, since it didn't occur to me
> to misuse keywords this way. I was curious about symbol lookup overhead
> as the number of keywords increases -- I should have been more specific
> in my question.
This is generally not a big concern. Symbol lookup normally only takes
place when input is occurring, either when processing user input or
loading a program file. The performance of this is almost always
dominated by the I/O speed, and symbol lookup shouldn't have much impact.
Also, packages are usually implemented as hash tables. Although there's
some size-related impact on performance, it's typically not very large
if you've implemented the tables well.
--
Barry Margolin, ······@alum.mit.edu
Woburn, MA
In article <····························@netnews.attbi.com>,
······@alum.mit.edu says...
> In article <·························@news1.toast.net>,
> Dan Muller <·········@sneakemail.com> wrote:
>
> > I wasn't concerned about this aspect of it, since it didn't occur to me
> > to misuse keywords this way. I was curious about symbol lookup overhead
> > as the number of keywords increases -- I should have been more specific
> > in my question.
>
> This is generally not a big concern. Symbol lookup normally only takes
> place when input is occurring, either when processing user input or
> loading a program file. The performance of this is almost always
> dominated by the I/O speed, and symbol lookup shouldn't have much impact.
Ah, I should've been able to figure that out myself. Amazing how much
I've forgotten about Lisp since the last time I used it regularly.
Thanks!
Dan Muller <·········@sneakemail.com> writes:
> In article <···············@shell01.TheWorld.com>, ······@nhplace.com
> says...
>>
>> For finite, non-extensible namespaces, I generally recommend keywords.
>> Almost always I'd translate an enum type into
>>
>> (member :bt-zero :bt-static :bt-active)
>>
>> since (a) it's easier to reference without symbol import/export issues
>> from a variety of packages and (b) it's in no danger of getting the meaning
>> of MY:BT-ZERO confused with YOUR:BT-ZERO.
>
> I have a newbie question with regard to this practice: In common
> implementations of CL, is there any reason to be concerned about
> "polluting" the keyword package with a large number of symbols?
Not really.
It is certainly not a problem for symbols that have been typed by the
user (it takes a lot of keystrokes to fill a significant amount of
memory). If you are generating them from a program, there may be
issues, but some Common Lisp implementations GC their symbols, so even
then it wouldn't be a problem.
Joe Marshall <···@ccs.neu.edu> writes:
> It is certainly not a problem for symbols that have been typed by
> the user (it takes a lot of keystrokes to fill a significant amount
> of memory). If you are generating them from a program, there may be
> issues, but some Common Lisp implementations GC their symbols, so
> even then it wouldn't be a problem.
Do you mean to say that in some implementations packages (or just
specifically the keyword package?) hold only a weak (i.e GC-breakable)
reference to symbols?
Having spent about 10 brain-seconds on this, it seems to me that this
would be reasonable (maybe even highly desirable) behavior, because I
can't see any reason to preserve a symbol's identity when it's only
known by one or more packages. But I'm also not able to convince
myself completely that this is in fact true.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> It is certainly not a problem for symbols that have been typed by
>> the user (it takes a lot of keystrokes to fill a significant amount
>> of memory). If you are generating them from a program, there may be
>> issues, but some Common Lisp implementations GC their symbols, so
>> even then it wouldn't be a problem.
>
> Do you mean to say that in some implementations packages (or just
> specifically the keyword package?) hold only a weak (i.e GC-breakable)
> reference to symbols?
On thinking about it, it is obvious that one cannot do this by default
because it would cause a detectable change in the behavior of
find-symbol, but there used to be a function
`garbage-collect-truly-worthless-atoms' that would do this, and a
tree-shaker ought to do it as well.
Joe Marshall <···@ccs.neu.edu> writes:
> On thinking about it, it is obvious that one cannot do this [have
> packages hold weak references to symbols] by default because it
> would cause a detectable change in the behavior of find-symbol, [..]
I believe you can do it undetectably if you just accept that you have
to keep the names (strings) present in the package structure. Then
find-symbol and intern can do make-symbol "on demand" if the symbol
has been swept away by GC.
Whether this is worth it is another question, I suppose. I'd guess
that the name-strings on average account for 50-60% of a symbol's
space requirement. Although this is obviously implementation and
average name-length dependent. But then again, if the names are
already otherwise present in the image, or if you dream up some
efficient name representation for e.g. gensym names, that might change
the balance of things.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Do you mean to say that in some implementations packages (or just
> specifically the keyword package?) hold only a weak (i.e GC-breakable)
> reference to symbols?
I hope not; the property list would be lost.
Kalle Olavi Niemitalo <···@iki.fi> writes:
> Frode Vatvedt Fjeld <······@cs.uit.no> writes:
>
>> Do you mean to say that in some implementations packages (or just
>> specifically the keyword package?) hold only a weak (i.e GC-breakable)
>> reference to symbols?
>
> I hope not; the property list would be lost.
Presumably you wouldn't do this for symbols that had a variable
binding, function binding, or non-null plist.
"DaveNlp" <(NOSPAM)·········@iol.it> writes:
> In C language exist the type 'enum'.
> An example,
>
> typedef enum { btZero, btStatic, btActive } BLOCK_TYPE;
>
> Does an equivalent thing (in Lisp) exists??
> There is a way in order to make the type "Enum"?
You need to understand that in C, enums serve two needs that
are conceptually quite different:
1. Unique identifiers.
2. Mappings between numbers and identifiers. This is used when
interfacing with something external to the program, like in a
network protocol or a hardware device driver. Or the OS kernel.
For 1. lispers use symbols (and often more specifically,
keywords). Understanding this use of symbols is IMHO an important part
of understanding lisp. For 2. there's no particular support in Common
Lisp. In some cases, defconstant is appropriate, but it will not
provide any mapping context (i.e. the mapping should be from (type,
identifier) to number, not just identifier to number), nor any way of
mapping back from number to identifier (which, strictly speaking, C
enums don't do either, but it's someting you'd perhaps expect from
lisp). It is however quite easy to roll your own macrology for doing
this.
One part of my binary-types library is an enum "binary type" (because
that library is all about mapping between lisp "symbolic" structures
and external, bits'n'bytes representations), and an example from an
ELF binary file reader looks like this, specifying how to interpret a
certain 8-bit field in an ELF file header:
(define-enum ei-class (u8)
elf-class-none 0
elf-class-32 1
elf-class-64 2)
<http://www.cliki.net/Binary-types>
--
Frode Vatvedt Fjeld
In article <··············@vserver.cs.uit.no>,
Frode Vatvedt Fjeld <······@cs.uit.no> wrote:
> You need to understand that in C, enums serve two needs that
> are conceptually quite different:
>
> 1. Unique identifiers.
>
> 2. Mappings between numbers and identifiers. This is used when
> interfacing with something external to the program, like in a
> network protocol or a hardware device driver. Or the OS kernel.
In my experience, it sees like enums are rarely used for the second
purpose. Usually #define'd constants are used.
--
Barry Margolin, ······@alum.mit.edu
Woburn, MA
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@vserver.cs.uit.no>,
> Frode Vatvedt Fjeld <······@cs.uit.no> wrote:
>
>> You need to understand that in C, enums serve two needs that
>> are conceptually quite different:
>>
>> 1. Unique identifiers.
>>
>> 2. Mappings between numbers and identifiers. This is used when
>> interfacing with something external to the program, like in a
>> network protocol or a hardware device driver. Or the OS kernel.
>
> In my experience, it sees like enums are rarely used for the second
> purpose. Usually #define'd constants are used.
In C++ code, this idiom is much used, e.g:
...
enum { buf_size = 1024 };
...
char buf[buf_size];
The main advantage of this is (probably) that the constants
defined in this way obey scoping rules, something preprocessor macros
most definitely do not.
Another common usage of enums is something like
enum { ll_trace, ll_debug, ll_info, ll_warning,
ll_error, ll_fatal } loglevel;
...
if (loglevel <= ll_info) { ...
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
In article <··············@raw.grenland.fast.no>,
Raymond Wiker <·············@fast.no> wrote:
> Barry Margolin <······@alum.mit.edu> writes:
>
> > In article <··············@vserver.cs.uit.no>,
> > Frode Vatvedt Fjeld <······@cs.uit.no> wrote:
> >
> >> You need to understand that in C, enums serve two needs that
> >> are conceptually quite different:
> >>
> >> 1. Unique identifiers.
> >>
> >> 2. Mappings between numbers and identifiers. This is used when
> >> interfacing with something external to the program, like in a
> >> network protocol or a hardware device driver. Or the OS kernel.
> >
> > In my experience, it sees like enums are rarely used for the second
> > purpose. Usually #define'd constants are used.
>
> In C++ code, this idiom is much used, e.g:
>
> ...
> enum { buf_size = 1024 };
>
> ...
>
> char buf[buf_size];
Ick. Wouldn't
const int buf_size = 1024;
work as well and be clearer?
> The main advantage of this is (probably) that the constants
> defined in this way obey scoping rules, something preprocessor macros
> most definitely do not.
>
> Another common usage of enums is something like
>
> enum { ll_trace, ll_debug, ll_info, ll_warning,
> ll_error, ll_fatal } loglevel;
>
> ...
>
> if (loglevel <= ll_info) { ...
That's different -- now you're depending on the fact that enum assigns
values in sequence.
Of course, it's trivial to create a DEFENUM macro in Lisp:
(defmacro defenum (&rest id-specs)
(let ((cur-val 0))
`(progn ,@(loop for spec in id-specs
collect (if (symbolp spec)
`(defconstant ,spec ,cur-val)
`(defconstant ,(car spec)
,(setf cur-val (cadr spec))))
do (incf cur-val)))))
(defenum ll-trace ll-debug ll-info ...)
(defenum (buf-size 1024))
--
Barry Margolin, ······@alum.mit.edu
Woburn, MA
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@raw.grenland.fast.no>,
> Raymond Wiker <·············@fast.no> wrote:
>> In C++ code, this idiom is much used, e.g:
>>
>> ...
>> enum { buf_size = 1024 };
>>
>> ...
>>
>> char buf[buf_size];
>
> Ick. Wouldn't
>
> const int buf_size = 1024;
>
> work as well and be clearer?
Wouldn't work... a const int is merely an unchangeable
integer; it cannot be used to specify the size of a vector (except for
heap-allocated vectors, created with new.) The problem is that the
value of the const int is not actually available to the compiler :-)
> Of course, it's trivial to create a DEFENUM macro in Lisp:
>
> (defmacro defenum (&rest id-specs)
> (let ((cur-val 0))
> `(progn ,@(loop for spec in id-specs
> collect (if (symbolp spec)
> `(defconstant ,spec ,cur-val)
> `(defconstant ,(car spec)
> ,(setf cur-val (cadr spec))))
> do (incf cur-val)))))
>
> (defenum ll-trace ll-debug ll-info ...)
>
> (defenum (buf-size 1024))
Which I did earlier in this thread :-)
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Raymond Wiker wrote:
> Barry Margolin <······@alum.mit.edu> writes:
>
>
>>In article <··············@raw.grenland.fast.no>,
>> Raymond Wiker <·············@fast.no> wrote:
>>
>>> In C++ code, this idiom is much used, e.g:
>>>
>>>...
>>> enum { buf_size = 1024 };
>>>
>>>...
>>>
>>> char buf[buf_size];
>>
>>Ick. Wouldn't
>>
>>const int buf_size = 1024;
>>
>>work as well and be clearer?
>
>
> Wouldn't work... a const int is merely an unchangeable
> integer; it cannot be used to specify the size of a vector (except for
> heap-allocated vectors, created with new.) The problem is that the
> value of the const int is not actually available to the compiler :-)
Actually, that works.
>
>
>>Of course, it's trivial to create a DEFENUM macro in Lisp:
>>
>>(defmacro defenum (&rest id-specs)
>> (let ((cur-val 0))
>> `(progn ,@(loop for spec in id-specs
>> collect (if (symbolp spec)
>> `(defconstant ,spec ,cur-val)
>> `(defconstant ,(car spec)
>> ,(setf cur-val (cadr spec))))
>> do (incf cur-val)))))
>>
>>(defenum ll-trace ll-debug ll-info ...)
>>
>>(defenum (buf-size 1024))
>
>
> Which I did earlier in this thread :-)
>
Michael Walter <··@unfinity.de> writes:
> Raymond Wiker wrote:
>> Wouldn't work... a const int is merely an unchangeable
>> integer; it cannot be used to specify the size of a vector (except for
>> heap-allocated vectors, created with new.) The problem is that the
>> value of the const int is not actually available to the compiler :-)
> Actually, that works.
Hum... seems you're right. A better reason to use the "enum
trick" is that it avoids allocating storage for the consant, as Pascal
Bourguignon suggests. Bjarne Stroustrup also says something about
this, at http://www.research.att.com/~bs/bs_faq2.html#in-class
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
On Sat, 06 Dec 2003 11:55:10 +0100, Raymond Wiker wrote:
> Bjarne Stroustrup also says something about
> this, at http://www.research.att.com/~bs/bs_faq2.html#in-class
Yet again showing that he's as bad at programming as at language design.
When a straightforward programming construct like...
static const int buf_size = 1024
... is available, it should be used, rather than some "trick". Stupid,
stupid, stupid advice (and I speak as one who has been using C++ since
cfront 1.0)...
faa
P.S. If he hadn't "designed" a language that was so hard to implement,
there wouldn't have been so many non-conforming compilers out there that
couldn't use the buf_size variable as an array size specifier in the first
place.
Hello!
Frank A. Adrian <·······@ancar.org> wrote:
>On Sat, 06 Dec 2003 11:55:10 +0100, Raymond Wiker wrote:
>> Bjarne Stroustrup also says something about
>> this, at http://www.research.att.com/~bs/bs_faq2.html#in-class
>Yet again showing that he's as bad at programming as at language design.
>When a straightforward programming construct like...
>static const int buf_size = 1024
>... is available, it should be used, rather than some "trick". Stupid,
>stupid, stupid advice (and I speak as one who has been using C++ since
>cfront 1.0)...
No. It's *annoying* to type things twice, as you have to in C++.
And w/ static const int ..., you have to type things twice more than
when using the enum trick (declare and set the value in the .h
file, define the variable/member in some compilation unit so
memory gets allocated).
Yes, C/C++ sucks anyway.
>[...]
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) writes:
> And w/ static const int ..., you have to type things twice more than
> when using the enum trick (declare and set the value in the .h file,
> define the variable/member in some compilation unit so memory gets
> allocated).
That's not so with static /integral/ constants, per C++98, so long as
you don't take the address.
--
Steven E. Harris :: ········@raytheon.com
Raytheon :: http://www.raytheon.com
Hello!
Steven E. Harris <········@raytheon.com> wrote:
>······@schlund.de (Hannah Schroeter) writes:
>> And w/ static const int ..., you have to type things twice more than
>> when using the enum trick (declare and set the value in the .h file,
>> define the variable/member in some compilation unit so memory gets
>> allocated).
>That's not so with static /integral/ constants, per C++98, so long as
>you don't take the address.
gcc 3.2/3.3 requires you to do what I've described.
Kind regards,
Hannah.
F'up to poster because of off topic
Raymond Wiker <·············@fast.no> writes:
> Michael Walter <··@unfinity.de> writes:
>
>> Raymond Wiker wrote:
>>> Wouldn't work... a const int is merely an unchangeable
>>> integer; it cannot be used to specify the size of a vector (except for
>>> heap-allocated vectors, created with new.) The problem is that the
>>> value of the const int is not actually available to the compiler :-)
>> Actually, that works.
>
> Hum... seems you're right. A better reason to use the "enum
> trick" is that it avoids allocating storage for the consant, as Pascal
> Bourguignon suggests. Bjarne Stroustrup also says something about
> this, at http://www.research.att.com/~bs/bs_faq2.html#in-class
Yeah, it is important to trim 4 bytes here and there. They add up.
--
~jrm
Barry Margolin <······@alum.mit.edu> writes:
> > enum { buf_size = 1024 };
> > char buf[buf_size];
>
> Ick. Wouldn't
>
> const int buf_size = 1024;
>
> work as well and be clearer?
I agree and I use const int or static const int, but I assume it
allocates some memory for the constant integer while enum {cst = 1024}
does not.
const int number=0;
enum { cst_num=0 };
const int* ptr =&number; //is valid
const int* cptr=&cst_num; //isn't: enum.c:4: error: invalid lvalue in unary `&'
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
* . . /\ ). . *
Living free in Alaska or in Siberia, a . . / .\ . * .
grizzli's life expectancy is 35 years, .*. / * \ . .
but no more than 8 years in captivity. . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
On Sat, 06 Dec 2003 11:17:06 +0100, Pascal Bourguignon wrote:
> I agree and I use const int or static const int, but I assume it
> allocates some memory for the constant integer while enum {cst = 1024}
> does not.
If your system is so tight on memory that four bytes would make a
difference, you should probably be coding in assembler, anyhow.
faa
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
> Barry Margolin <······@alum.mit.edu> writes:
> > > enum { buf_size = 1024 };
> > > char buf[buf_size];
> >
> > Ick. Wouldn't
> >
> > const int buf_size = 1024;
> >
> > work as well and be clearer?
>
> I agree and I use const int or static const int, but I assume it
> allocates some memory for the constant integer while enum {cst = 1024}
> does not.
If &buf_size never appears anywhere, there's no reason why any storage
needs to be allocated for it. The compiler can simply open-code all
references to it.
--
Barry Margolin, ······@alum.mit.edu
Woburn, MA
Barry Margolin <······@alum.mit.edu> writes:
> If &buf_size never appears anywhere, there's no reason why any storage
> needs to be allocated for it. The compiler can simply open-code all
> references to it.
The concept of an SSC didn't exist in the C(++) world at the time. It
was the programmer's job to compile the code. :)
--
Rahul Jain
DaveNlp schrieb:
>
> In C language exist the type 'enum'.
This can be a point to the wish list.
Often I read text writing form C-programmer who have a look at lisp and
hold in mind their c-knowledge.
Is it possible to create a c-package for lisp, includes all this what a
typical C-programmer wants?
Just a thought.
stefan
lin8080 wrote:
>
> DaveNlp schrieb:
>
>>In C language exist the type 'enum'.
>
>
> This can be a point to the wish list.
>
> Often I read text writing form C-programmer who have a look at lisp and
> hold in mind their c-knowledge.
> Is it possible to create a c-package for lisp, includes all this what a
> typical C-programmer wants?
Yes, has been done before AFAIK.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)