On 9/26/07, Dave Smith <[EMAIL PROTECTED]> wrote:
> I stand mistaken. It's called the C++ FAQ LITE, and this is the URL:
>
>http://www.parashift.com/c++-faq-lite/
>
> Lots of good stuff there, like should you use the "this" pointer in a
> constructor? :)
>
>http://www.parashift.com/c++-faq-
Derek Davis wrote:
Do you have a link to the super faq?
I stand mistaken. It's called the C++ FAQ LITE, and this is the URL:
http://www.parashift.com/c++-faq-lite/
Lots of good stuff there, like should you use the "this" pointer in a
constructor? :)
http://www.parashift.com/c++-faq-
On 9/19/07, Dave Smith <[EMAIL PROTECTED]> wrote:
> 2. You need to read a few entries in the C++ Super FAQ and a few pages
> from the beginning of Josuttis's book, The C++ Standard Library (which
> pages incidentally have nothing to do with the C++ Standard Library but
> cover basic C++ language fe
"Jonathan Ellis" <[EMAIL PROTECTED]> writes:
>
> As with many "design patterns" from lower-level languages, dynamic
> languages have been doing AOP for years without bothering to call it
> that. You don't need an AOP library in Python, Ruby, or Javascript.
>
The whole point of "design patterns"
On 9/20/07, Nicholas Leippe <[EMAIL PROTECTED]> wrote:
> AOP is not dead. There are many projects to add AOP to several languages.
> They include at least (from my recollection when I last read up on it) Lisp,
> PHP, boo, Ruby, Python, javascript, and I believe even C++ --although code
> weaving in
Dave Smith <[EMAIL PROTECTED]> writes:
>
> I'm surprised no one has mentioned Aspect Oriented Programming for
> debugging, which to me is a textbook no-brainer application. It
> operates (potentially) directly on the parse tree and should be ideal
> for removing/adding debugging code at build time
On 9/20/07, Dave Smith <[EMAIL PROTECTED]> wrote:
> I'm surprised no one has mentioned Aspect Oriented Programming for
> debugging, which to me is a textbook no-brainer application. It operates
> (potentially) directly on the parse tree and should be ideal for
> removing/adding debugging code at bu
On Thursday 20 September 2007, Dave Smith wrote:
> I'm surprised no one has mentioned Aspect Oriented Programming for
> debugging, which to me is a textbook no-brainer application. It operates
> (potentially) directly on the parse tree and should be ideal for
> removing/adding debugging code at bui
Levi Pearson wrote:
If debug is defined as a constant, the code ought to be completely
eliminated by any reasonable compiler. Why keep dead code around?
C-style preprocessing is pretty much the worst possible way to do most
of the things it does, but at least it does them in a fairly simple
and
Levi Pearson wrote:
Most user-interactive desktop applications aren't really dealing with
'raw speed', whatever that means. I'm not really sure where the
slowness of modern desktop applications comes from, but I'd point the
finger at the mountains of code beneath the surface before I pointed
at
Nicholas Leippe <[EMAIL PROTECTED]> writes:
> On Thursday 20 September 2007, Levi Pearson wrote:
>> If only there was a sane macro system available that operated on
>> the parse tree rather than the text...
>
> If only ;)
>
> (/me points out Levi's allusion to Lisp for anyone that missed it)
Well
On Thursday 20 September 2007, Levi Pearson wrote:
> If only there was a sane macro system available that operated on
> the parse tree rather than the text...
If only ;)
(/me points out Levi's allusion to Lisp for anyone that missed it)
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsub
"Bryan Sant" <[EMAIL PROTECTED]> writes:
> A blessing and a curse. Macro-based debugging has merit, but nasty
> black magic macros used for non-debugging purposes can be a bear to
> debug. I'd also argue that the single jump instruction that is
> produced with an "if (debug) {" test one would use
Dave Smith <[EMAIL PROTECTED]> writes:
> Levi Pearson wrote:
>> C++ is hugely complex and has a myriad of ways to do things, so it's really
>> a tool that requires deep knowledge of the language, available libraries,
>> and best practices to use well.
>>
>
> I disagree with 2 of your 3 statem
On 9/19/07, Dave Smith <[EMAIL PROTECTED]> wrote:
> If you do those two things, you'll be in good shape to code lots of
> awesome C++.
Thanks for the tips.
> 2. Macro-based debugging. Using the macro system, you can remove and
> insert entire chunks of code just by flipping a flag in your makefil
On 9/19/07, Michael L Torrie <[EMAIL PROTECTED]> wrote:
> Manual memory management is often, in my opinion, a huge plus of C and
> C++. With reference-counting smart pointers and destructors, memory
> management in C++ is very straight-forward, fast, and safe. Just
I agree. Using smart pointers
Levi Pearson wrote:
C++ is hugely complex and has a myriad of ways to do things, so it's really a
tool that requires deep knowledge of the language, available libraries, and
best practices to use well.
I disagree with 2 of your 3 statements and only partially agree with the
other. Let me
Michael L Torrie <[EMAIL PROTECTED]> writes:
> Manual memory management is often, in my opinion, a huge plus of C and
> C++. With reference-counting smart pointers and destructors, memory
> management in C++ is very straight-forward, fast, and safe. Just
> understanding a bit about how C++ does
On 9/19/07, Michael L Torrie <[EMAIL PROTECTED]> wrote:
> Bryan Sant wrote:
> > Oh the joys of life with manual memory management :-)
>
> Manual memory management is often, in my opinion, a huge plus of C and
> C++. With reference-counting smart pointers and destructors, memory
> management in C++
Bryan Sant wrote:
> Oh the joys of life with manual memory management :-)
Manual memory management is often, in my opinion, a huge plus of C and
C++. With reference-counting smart pointers and destructors, memory
management in C++ is very straight-forward, fast, and safe. Just
understanding a bi
20 matches
Mail list logo
