about C program CPP macro
Hello, all:
I have a program problem, ( may it not have close releationship with
Debian), it described like this:
I want to using #define / #undef, and want to put them in a single macro,
some thing like:
#define DECALRE_TYPE(type) \
{ #undef __curr_type; #define _curr_type type; }
as we know, this can not passed with CPP, but I need this logical here.
Generally, the problem comes from
#define ser_field(type, var) \
ser_new_field(tra, #type, #var, offsetof(struct_type, var))
I do not want another additional parameter in this macro like
#define ser_field(type,var,struct_type), and I want a sentence declare
current struct type
and all later work of ser_field will defaultly use this type.
I am not sure whether I can express it clearly, any ideas will be greately
appreciated!
Thanks and B.R.
2013/12/10 Zenaan Harkness z...@freedbms.net
OK, I removed the no-bitmaps.conf x11 symlink and restarted X.
Now eg
xterm -fn 6x10 -fa
works as advertised to give me normal xterm bitmap font.
However, my custom xterm bitmap font, which I access by:
xterm -fa Zen
produces an xterm with my custom font, but a very/extra- large spacing
above each line.
Any custom or bitmap font gurus or xterm font junkies who might know
what is now wrong?
(I guess there could be some font parameter which was previously being
ignored, but is now being honored? dunno myself).
TIA
Zenaan
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
http://lists.debian.org/caosgnsrzcaleleuyad7bnjphjd_hscz5yzkvgtcw5qw-rpy...@mail.gmail.com
Re: about C program CPP macro
Den 10. des. 2013 15:19, skrev Nicol TAO:
I want to using #define / #undef, and want to put them in a single
macro, some thing like:
#define DECALRE_TYPE(type) \
{ #undef __curr_type; #define _curr_type type; }
Why do you need to #undef it first? Can you do without the #undef and
use typedef instead of the #define-macro?
Btw., You can ask about this on Stackoverflow, sometimes questions get
answered in 20 seconds or so :-)
http://ww.stackoverflow.com/
Atle.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52a79813.8050...@goliathdns.no
FW: About C/C++: C Programming Tips
Title: C/C++ -Original Message-From: John Kopp - About.com C/C++ Guide [mailto:[EMAIL PROTECTED]Sent: Thursday, December 11, 2003 4:26 AMTo: Sreelal ChandrasenanSubject: About C/C++: C Programming Tips C/C++ In the Spotlight | More Topics from John Kopp, your Editor and Guide In the Spotlight C Programming TipsThese tips will improve your code, help you avoid bugs and, in general, make you a better personread more More Topics Standard Template Library UNIX and GNU Resources for C and C++ Visual C++ Programming More Tutorials C Programming Tips Advanced Topics in C++These articles are a collection of tutorials on intermediate and advanced topics in C++ programming. For introductory material, check out the C++ Tutorialread more Book Review - Programming Perl by WallA review of "Programming Perl", 3rd Edition By Larry Wall, Tom Christiansen, Jon Orwant. This book, co-authored by Larry Wall, the creator of Perl, serves as the Perl "bible" for many Perl programmers. It is very well written and covers...read more Featured Offer Visit Related About GuideSites: Computer Certification Delphi Programming Focus on Java Focus on _javascript_ Focus on Linux Focus on Windows Perl/PHP Visual Basic Search About More Newsletters: To sign up for more free newsletters on What You Need to Know About your favorite topics, visit: http://talk.about.com You are receiving this newsletter because you subscribed to the About C/C++ newsletter as [EMAIL PROTECTED] If you no longer wish to receive emails from us, please visit:http://about.com/nl/usgs.htm?nl=cplus[EMAIL PROTECTED] About respects your privacy. Our Privacy Policy.Our Contact Information. © 2003 About, Inc.
FW: About C/C++: Book Review - Programming the Perl DBI by Descartes
Title: C/C++ -Original Message-From: John Kopp - About.com C/C++ Guide [mailto:[EMAIL PROTECTED]Sent: Thursday, December 04, 2003 1:56 AMTo: Sreelal ChandrasenanSubject: About C/C++: Book Review - Programming the Perl DBI by Descartes C/C++ In the Spotlight | More Topics from John Kopp, your Editor and Guide In the Spotlight Book Review - Programming the Perl DBI by DescartesA review of "Programming the Perl DBI", by Alligator Descartes, Tim Bunce. This is a great book. It covers the essential of Perl database programming using DBI in a few short chapters without skipping essential details for producing production quality...read more More Topics C and C++ Magazines Object-Oriented Analysis And Design Polls for C/C++ Developers and Students Software Engineering Style Guidelines for C and C++ C/C++ Glossary Tips Book Review - Learning PerlA review of "Learning Perl" by Schwartz and Phoenix. This book is one of the best introductions to the Perl programming language. It is perfect for beginners and will give you enough knowledge to really begin to use Perlread more Book reviewsNew Reviews. Effective STL by Scott Meyers Swing by Matthew Robinson STL Tutorial and Reference Guide by Musser, Derge and Saini...read more Featured Offer Visit Related About GuideSites: Computer Certification Delphi Programming Focus on Java Focus on _javascript_ Focus on Linux Focus on Windows Perl/PHP Visual Basic Search About More Newsletters: To sign up for more free newsletters on What You Need to Know About your favorite topics, visit: http://talk.about.com You are receiving this newsletter because you subscribed to the About C/C++ newsletter as [EMAIL PROTECTED] If you no longer wish to receive emails from us, please visit:http://about.com/nl/usgs.htm?nl=cplus[EMAIL PROTECTED] About respects your privacy. Our Privacy Policy.Our Contact Information. © 2003 About, Inc.
Re: ? about C++
On Thursday, March 7, 2002, at 03:57 PM, Dimitri Maziuk wrote: Anyhow, my point was, name 4 problem areas in C. You're lucky with 'none of the above'. It could be... 1. No array bounds checking (Fix: use vector or equivalent) Real-world idiot fix: My name is 7 characters; give it twenty, we'll never need more than that! Then use that twenty inline in the code, as well as simplifying the expressions a little so we get the related constants 21 (w/ null), 19 (can't count, paranoid), 8, 9, 10 (unicode), and infinity (core dump). 2. Pointers (Fix: use references, iterators etc.). Real-world idiot fix: Pass everything by value. Who needs pointers, references, etc.? Use indices with magic constants as the bounds (see above) to iterate arrays. BTW: I disagree _strongly_ that pointers are a misfeature of C. They are a very useful tool. However, misuse of pointers is a misfeature of some programmers. 3. Forgetting to free() malloc()'ed memory (Fix: use auto_ptr, destructors etc.) Real-world idiot fix: Buy more memory. If that proves impossible, increase amount of disk used for swap. In the event of hitting architectural limits, go 64-bit. Or just make the program crash more often. Then it won't leak as much memory. Tell the user to save often. 4. Using pointers to (hopefully array) (hopefully allocated) (hopefully null-terminated) of char as string data type (see also 1, 2, 3) (Fix: use std::string) Real-world idiot fix: Add 'hopefully not overflowed' to the list. Fix allocation problems by allocating on the stack. If worried about array not being large enough, increase static size. See #1. If worried about excess stack usage, see #3. And, for the hell of it, see #4 ;-)
Re: ? about C++
* Anthony DeRobertis ([EMAIL PROTECTED]) spake thusly: On Thursday, March 7, 2002, at 03:57 PM, Dimitri Maziuk wrote: Anyhow, my point was, name 4 problem areas in C. You're lucky with 'none of the above'. It could be... Luck has nothing to do with it 1. No array bounds checking (Fix: use vector or equivalent) Real-world idiot fix: My name is 7 characters; give it twenty, we'll never need more than that! Then use that twenty inline in the code, as well as simplifying the expressions a little so we get the related constants 21 (w/ null), 19 (can't count, paranoid), 8, 9, 10 (unicode), and infinity (core dump). 2. Pointers (Fix: use references, iterators etc.). Real-world idiot fix: Pass everything by value. Who needs pointers, references, etc.? Use indices with magic constants as the bounds (see above) to iterate arrays. BTW: I disagree _strongly_ that pointers are a misfeature of C. They are a very useful tool. However, misuse of pointers is a misfeature of some programmers. Real-world troubleshooting technique: put ulimit on stack size. If program segfaults on int main( int argc, char **argv ), - segfault here --- it has both of the above. [ snip ] Yeah. BTDT, got more t-shirts than I'll ever need. Dima -- The wombat is a mixture of chalk and clay used for respiration. -- MegaHal
Re: ? about C++
Lo, on Thursday, March 7, Dimitri Maziuk did write: * Craig Dickson ([EMAIL PROTECTED]) spake thusly: begin Dimitri Maziuk quotation: Does anyone know about a school that teaches people to use vector, auto_ptr, basic_string and references? I have no idea what they teach in school these days, but I should think they would have to teach references if they teach operator overloading. Not according to the code I get to play with. [ snip ] The standard auto_ptr is an abomination. [ snip ] Well, there's that... I'd argue that garbage collection is very hard to get 100% right anyway In C and C++, this is basically correct, although it depends on exactly what you mean by `right'. In advanced languages which actually provide type safety, I disagree. Correct GCs have been pretty well understood since, oh, about the mid '70s. (I want to say '74, but I don't recall exactly when the mark-and-sweep algorithm was developed.) Most of the research in this area since then has been concerned with performance improvements, rather than correctness issues. This is pretty irrelevant when you're talking about auto_ptr; it's not a full GC. IMO, most of auto_ptr's bad reputation comes from people trying to use it as though it single-handedly solved all memory allocation problems. It doesn't, and it was most specifically not designed for that in the first place. It does, however, do a wonderful job at what it *was* designed for: it prevents memory leaks in the face of exceptions. and there are other ways to detect memory leaks... Yes, although this is not really one of the main benefits of using a GC. For my money, one of the primary benefits of GC is that I don't have to worry about a lot of really annoying bugs, especially dangling pointers or heap corruptions through incorrect deletions. Anyhow, my point was, name 4 problem areas in C. 1. No array bounds checking (Fix: use vector or equivalent) Agreed. 2. Pointers (Fix: use references, iterators etc.). Pointers are not the problem; the fact that they're not safe is the problem. Solution: get rid of void*, and prevent all typecasts involving pointers except those between different classes in an inheritance hierarchy. Oh, and check pointer arithmetic, too, but that's basically equivalent to point #1. Referencs a la C++ have their own problems; they allow variable aliasing, which causes all kinds of grief during optimization. 3. Forgetting to free() malloc()'ed memory (Fix: use auto_ptr, destructors etc.) auto_ptr and destructors are a step in the right direction, but I don't find that they're completely general. This may be due to the fact that I'm used to the freedom and flexibility that comes with a GC language. 4. Using pointers to (hopefully array) (hopefully allocated) (hopefully null-terminated) of char as string data type (see also 1, 2, 3) (Fix: use std::string) Oh, absolutely. This is basically related to the other three points. Richard
Re: ? about C++
* a ([EMAIL PROTECTED]) spake thusly:
(sorry! if you know any other mailing list i should send, pls tell me)
why the program below is wrong?
Because you and your teachers should seriously consider
a career in lawnmoving.
using namespace std;
class t
{public :
string p;
};
Does anyone know about a school that teaches people to use
vector, auto_ptr, basic_string and references?
Dima
--
Backwards compatibility is either a pun or an oxymoron. -- PGN
Re: ? about C++
begin Dimitri Maziuk quotation: Does anyone know about a school that teaches people to use vector, auto_ptr, basic_string and references? I have no idea what they teach in school these days, but I should think they would have to teach references if they teach operator overloading. I'm actually a little surprised how rarely I use vector -- more often I use deque when I want an array-like container, because the ability to add and remove members at both ends comes in handy. Maybe that just says something about the kind of data I work with. The standard auto_ptr is an abomination. When more than one such object points to the same data, only the most recently-assigned one owns the pointer, which can lead to nasty, counter-intuitive problems if you delete the auto_ptrs in a different order than you assigned them. A few years back, I wrote my own AutoPtr that improves on auto_ptr in at least three different ways: (1) The data is only deleted when there are no more AutoPtrs referencing it; (2) Deletion of the referenced data is handled by a function object (which is one of the template parameters), and therefore can do things other than just delete ptr; if needed (e.g. delete[] ptr;, ptr-Destroy();, or whatever); (3) AutoPtr comes in two flavors, AutoPtr and ConstAutoPtr (read-only pointer), mimicking quite closely the relationship between X* and const X*, including the fact that you can assign an AutoPtrX to a ConstAutoPtrX, but not the other way around. With this, you can safely put AutoPtrs to the same data in different objects, and the data will stick around until it's no longer needed, regardless of the order in which the objects are deleted. Unfortunately, this code is not open-source. Craig pgpQuICWdzBGX.pgp Description: PGP signature
Re: ? about C++
* Craig Dickson ([EMAIL PROTECTED]) spake thusly: begin Dimitri Maziuk quotation: Does anyone know about a school that teaches people to use vector, auto_ptr, basic_string and references? I have no idea what they teach in school these days, but I should think they would have to teach references if they teach operator overloading. Not according to the code I get to play with. [ snip ] The standard auto_ptr is an abomination. [ snip ] Well, there's that... I'd argue that garbage collection is very hard to get 100% right anyway, and there are other ways to detect memory leaks... Anyhow, my point was, name 4 problem areas in C. 1. No array bounds checking (Fix: use vector or equivalent) 2. Pointers (Fix: use references, iterators etc.). 3. Forgetting to free() malloc()'ed memory (Fix: use auto_ptr, destructors etc.) 4. Using pointers to (hopefully array) (hopefully allocated) (hopefully null-terminated) of char as string data type (see also 1, 2, 3) (Fix: use std::string) We have a bunch of C++ code written by CS students here, and I get to support it. Guess which of the fixes above one finds in their code? Dima (A: none of the above) -- Tlaloc: What was Elrond's second name? Gruber: Hubbard -- [EMAIL PROTECTED]
Re: ? about C++
begin Dimitri Maziuk quotation:
Anyhow, my point was, name 4 problem areas in C.
1. No array bounds checking (Fix: use vector or equivalent)
Of course, the behavior of vector::operator[] is undefined if the index
is invalid, which is sort of weird, since vector::at() does the right
thing.
2. Pointers (Fix: use references, iterators etc.).
Iterators help a lot with STL collections, but references aren't all
that great. They're mostly just syntactic sugar, useful for, e.g.,
operator overloading, where you typically define, say, operator+= as:
class X { X operator+=(const X x); };
This is really why references exist in C++ at all, because without them,
you'd either have to pass the argument to operator+= (and similar
operators) by value, which is inefficient for non-trivial objects (and
not always possible), or as a pointer, which would be syntactically ugly
(e.g.: Object x, y; x += y;).
There is, unfortunately, such a thing as a null reference (consider the
expression X x = *((X*) 0);, for a trivial and obvious example). On
the plus side, you can't index off a reference without explicitly
converting it to a pointer first.
The other annoying thing about references in C++ is that every time you
define some function that takes another object by reference, you get to
argue with yourself about whether it should be a pointer or a reference,
which in turn depends on where the object is coming from. More often
than not, it might as well be a pointer, because if the object was
created by new then you've already got a pointer to it anyway. And
creating references from pointers (e.g. X* p; X x = *p;) is ugly and
leads people to forget that the object may not exist (null pointer).
Craig
pgpbln0BnPZsR.pgp
Description: PGP signature
Re: ? about C++
* Craig Dickson ([EMAIL PROTECTED]) spake thusly:
begin Dimitri Maziuk quotation:
Anyhow, my point was, name 4 problem areas in C.
1. No array bounds checking (Fix: use vector or equivalent)
Of course, the behavior of vector::operator[] is undefined if the index
is invalid, which is sort of weird, since vector::at() does the right
thing.
LOL. I learned something today.
[ snip pointers references ]
Oh well. I guess it's just as well that I don't do much C++
nowadays. The code I get to deal with is usually poorly written
C with a few cout's (yes, there are printf()'s too), often preceded
by // debug, and occaisonally, a class ... {...} around the whole
thing. Can't help but wonder who taught these people... and the OP's
code snippet definitely looked like he has the same teachers.
Dima
--
I'm going to exit now since you don't want me to replace the printcap. If you
change your mind later, run-- magicfilter config script
? about C++
(sorry! if you know any other mailing list i should send, pls tell me)
why the program below is wrong?
class t
{public :
static char *p;
};
char t::*p;
main()
{t k;
k.p=;
}
i'll leave the list soon,pls reply to [EMAIL PROTECTED]
Re: ? about C++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 07 Mar 2002 15:52, a wrote:
(sorry! if you know any other mailing list i should send, pls tell me)
This is a mailing list on how to use the debian operating system, so it isn't
a particularly good choice. You'd have been better off on a specialist
programming mailing list for, or even debian-devel.
why the program below is wrong?
class t
{public :
static char *p;
};
char t::*p;
main()
{t k;
k.p=;
}
Firstly, formatting would make this much easier to read.
class t {
public:
static char *p;
};
char t::*p;
main() {
t k;
k.p=;
}
There is a lot of personal preference involved, but this is much easier to
read than the one you wrote.
Now, the problem is with the line char t::*p
This says to use the default initialiser for the character pointed to by t's
member named p. I'm not sure this is valid even if t::p had been declared,
but it isn't valid if it hasn't.
changing it to
char * t::p should work.
Corrin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6d-cvs (GNU/Linux)
iD8DBQE8huMsi5A0ZsG8x8cRAgAjAJ0TJtBB3vKQW+YQFKXFPrmKlRssugCeL+O+
UqbqZ2by+tlczpPA+8mcMiI=
=5laQ
-END PGP SIGNATURE-
Re: ? about C++
Corrin Lakeland wrote: why the program below is wrong? Generally, it's adviseable not to reply to questions that look like someone who needs help with his school assignments. When someone presents a trivial programming problem based on a nonsensical code fragment and doesn't even tell you what errors the compiler generated, it's a good guess that he never tried to compile it -- the code, and the question what is wrong with this code are almost certainly a homework assignment. The best response, if one must respond at all, is simply, Figure it out yourself -- that's why your teacher gave it to you. Craig pgpOQZms4L9us.pgp Description: PGP signature
[off topic] The truth about 'C++' revealed...
The truth about 'C++' revealed... Fro Jason . in Utah On the 1st of January, 1998, Bjarne Stroustrup gave an interview to the IEEE's 'Computer' magazine. Naturally, the editors thought he would be giving a retrospective view of seven years of object-oriented design, using the language he created. By the end of the interview, the interviewer got more than he had bargained for and, subsequently, the editor decided to suppress its contents, 'for the good of the industry' but, as with many of these things, there was a leak. Here is a complete transcript of what was was said,unedited, and unrehearsed, so it isn't as neat as planned interviews. You will find it interesting... __ Interviewer: Well, it's been a few years since you changed the world of software design, how does it feel, looking back? Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing 'C' and, the trouble was, they were pretty damn good at it. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word 'competent' - graduates at a phenomenal rate. That's what caused the problem. Interviewer: problem? Stroustrup: Yes, problem. Remember when everyone wrote Cobol? Interviewer: Of course, I did too Stroustrup: Well, in the beginning, these guys were like demi-gods. Their salaries were high, and they were treated like royalty. Interviewer: Those were the days, eh? Stroustrup: Right. So what happened? IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen. Interviewer: That's why I got out. Salaries dropped within a year, to the point where being a journalist actually paid better. Stroustrup: Exactly. Well, the same happened with 'C' programmers. Interviewer: I see, but what's the point? Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity. [NJW Comment: That explains everything. Most of my thesis work was in raw X-windows. :)] Interviewer: You're kidding...? Stroustrup: Not a bit of it. In fact, there was another problem. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn? Interviewer: You bet I do, that's what I used to do. Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too. Interviewer: I don't believe you said that... Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would. Interviewer: So how exactly did you do it? Stroustrup: It was only supposed to be a joke, I never thought people would take the book seriously. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient. Interviewer: What? Stroustrup: And as for 're-useable code' - when did you ever hear of a company re-using its code? Interviewer: Well, never, actually, but... Stroustrup: There you are then. Mind you, a few tried, in the early days. There was this Oregon company - Mentor Graphics, I think they were called - really caught a cold trying to rewrite everything in C++ in about '90 or '91. I felt sorry for them really, but I thought people would learn from their mistakes. Interviewer: Obviously, they didn't? Stroustrup: Not in the slightest. Trouble is, most companies hush-up all their major blunders, and explaining a $30 million loss to the shareholders would have been difficult. Give them their due, though, they made it work in the end. Interviewer: They did? Well, there you are then, it proves O-O works. Stroustrup: Well, almost. The executable was so huge, it took five minutes to load, on an HP workstation, with 128MB of RAM. Then it ran like treacle. Actually, I thought this would be a major stumbling- block, and I'd get found out within a week, but nobody cared. Sun and HP were only too glad to sell
