http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* atexit - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/ecb78db904bcd136?hl=en
* China factory wholesale NFL,mlb,nhl,nbaJerseys Free Shipping Paypal payment <
www.wtojerseys.com> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f769d521a2fb7599?hl=en
* ┡┢┣ High quality+low price→cheap wholesale Air Force One shoes in paypal
payment (www.fjrjtrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/af79e6b9a73107ca?hl=en
* How can I use unqualified names? (Possibly hard or impossible?) - 2 messages,
1 author
http://groups.google.com/group/comp.lang.c++/t/e2f24a95fe72b591?hl=en
* Designer Ed hardy Womens Shoes - Discount - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/373a5a670eb26a0d?hl=en
* "Concepts" were removed from C++0x - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/2a650fa1f3c8016a?hl=en
==============================================================================
TOPIC: atexit
http://groups.google.com/group/comp.lang.c++/t/ecb78db904bcd136?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Jul 26 2009 10:16 am
From: James Kanze
On Jul 26, 5:37 pm, Pete Becker <p...@versatilecoding.com> wrote:
> James Kanze wrote:
> > On Jul 26, 12:00 pm, "Fraser Ross" <z...@zzzzzz.com> wrote:
> >> I've been looking at N2914. 3.6.3/3 only refers to non-local
> >> statics.
> > There is no such thing as N2914. (The latest I can see is
> > N2881.)
> N2914 is the working draft in the pre-Frankfurt mailing. It's
> dated 2009-06-22. It's now the current working draft.
So I see. And I didn't have the latest mailings downloaded to
my machine here.
The wording of §3.6.3 has been completely changed with regards
to the standard, to take into account threading and thread local
storage. And §3.6.3 has been changed to exclude static objects
with local scope. Is this intentional, and for what reason?
(It may break existing programs.) Or is it an unintentional
side effect of some other change? I presume that the intent
here is to exclude objects with thread storage duration; if so,
should I raise a defect report, or is the original intent clear
enough that you could handle it as an editorial change. (It
looks a bit big for an editorial change to me, but if the
proposal that was actually voted on was clear, perhaps that
would be acceptable.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
== 2 of 2 ==
Date: Sun, Jul 26 2009 11:03 am
From: Pete Becker
James Kanze wrote:
> On Jul 26, 5:37 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> James Kanze wrote:
>>> On Jul 26, 12:00 pm, "Fraser Ross" <z...@zzzzzz.com> wrote:
>>>> I've been looking at N2914. 3.6.3/3 only refers to non-local
>>>> statics.
>
>>> There is no such thing as N2914. (The latest I can see is
>>> N2881.)
>
>> N2914 is the working draft in the pre-Frankfurt mailing. It's
>> dated 2009-06-22. It's now the current working draft.
>
> So I see. And I didn't have the latest mailings downloaded to
> my machine here.
>
> The wording of §3.6.3 has been completely changed with regards
> to the standard, to take into account threading and thread local
> storage. And §3.6.3 has been changed to exclude static objects
> with local scope. Is this intentional, and for what reason?
> (It may break existing programs.) Or is it an unintentional
> side effect of some other change? I presume that the intent
> here is to exclude objects with thread storage duration; if so,
> should I raise a defect report, or is the original intent clear
> enough that you could handle it as an editorial change. (It
> looks a bit big for an editorial change to me, but if the
> proposal that was actually voted on was clear, perhaps that
> would be acceptable.)
>
It's still under discussion. See N2880 and and N2917. The problem
centers around interactions between detached threads and destruction of
function-static objects.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
==============================================================================
TOPIC: China factory wholesale NFL,mlb,nhl,nbaJerseys Free Shipping Paypal
payment <www.wtojerseys.com>
http://groups.google.com/group/comp.lang.c++/t/f769d521a2fb7599?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Jul 26 2009 10:28 am
From: hehe
ALL ARE IN HAND,FAST SHIPMENT!
We use EMS,it usually takes 4-7 days arrive your hand!
BRAND NEW WITH tAG (NWT)
FASTEST SHIPPING PROMIS
SIZE:M,L,XL,XXL48,50,52,54
M48:81--65cm(length-width)
L50:83--66cm(length-width)
XL52:85--67cm(length-width)
XXL54:88--67cm( length-width)
We offer money back(not include shipment) guarantee on all my
jerseys,
if you are not happy you can return it for a FULL REFUND as long as
the item is in the same condition that you received.
ALL LETTERS AND NUMBERS ARE SEWN ON!!!
High Quality Promised!!!
and you can mix the order!!!
Arizona Cardinals(www.wtojerseys.com)
Atlanta Falcons(www.wtojerseys.com)
Baltimore Ravens(www.wtojerseys.com)
Buffalo Bills(www.wtojerseys.com)
Carolina Panthers(www.wtojerseys.com)
Chicago Bears(www.wtojerseys.com)
Cincinnati Bengals(www.wtojerseys.com)
Cleveland Browns(www.wtojerseys.com)
Dallas Cowboys(www.wtojerseys.com)
Denver Broncos(www.wtojerseys.com)
Detroit Lions(www.wtojerseys.com)
Green Bay Packers(www.wtojerseys.com)
Houston Texans(www.wtojerseys.com)
Indianapolis Colts(www.wtojerseys.com)
Jacksonville Jaguars(www.wtojerseys.com)
Kansas City Chiefs(www.wtojerseys.com)
Miami Dolphins(www.wtojerseys.com)
Minnesota Vikings(www.wtojerseys.com)
New England Patriots(www.wtojerseys.com)
New Orleans Saints(www.wtojerseys.com)
New York Giants(www.wtojerseys.com)
San Francisco 49ers(www.wtojerseys.com)
Seattle Seahawks(www.wtojerseys.com)
St. Louis Rams(www.wtojerseys.com)
Tampa Bay Buccaneers(www.wtojerseys.com)
Tennessee Titans(www.wtojerseys.com)
Washington Redskins(www.wtojerseys.com)
New York Jets(www.wtojerseys.com)
Oakland Raiders(www.wtojerseys.com)
Philadelphia Eagles(www.wtojerseys.com)
Pittsburgh Steelers(www.wtojerseys.com)
San Diego Chargers(www.wtojerseys.com)
==============================================================================
TOPIC: ┡┢┣ High quality+low price→cheap wholesale Air Force One shoes in
paypal payment (www.fjrjtrade.com)
http://groups.google.com/group/comp.lang.c++/t/af79e6b9a73107ca?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Jul 26 2009 11:02 am
From: "www.wholesale789.com"
┡┢┣High quality+low price→cheap wholesale Air Force One shoes in
paypal payment (www.fjrjtrade.com)
Welcome to visit www.fjrjtrade.com
Cheap Wholesale Air Force One Shoes
Wholesale Air Force One Shoes (paypal payment)
http://www.fjrjtrade.com/category-916-b0-Air-Force-one.html
Wholesale Air Force One 25 Men (paypal payment)
http://www.fjrjtrade.com/category-1627-b0-Air-Force-one-25%28M%29.html
Wholesale Air Force One 25 Women (paypal payment)
http://www.fjrjtrade.com/category-1628-b0-Air-Force-One-25%28W%29.html
Wholesale Air Force One Children (paypal payment)
http://www.fjrjtrade.com/category-1629-b0-Air-force-One-Children.html
Wholesale Air Force One low (paypal payment)
http://www.fjrjtrade.com/category-1630-b0-Air-Force-one%28low%29.html
Wholesale Air Force One M&W (paypal payment)
http://www.fjrjtrade.com/category-1631-b0-Air-Force-One%28MW%29.html
Wholesale Air Force One Mid (paypal payment)
http://www.fjrjtrade.com/category-1632-b0-Air-Force-one%28Mid%29.html
Wholesale Air Force One Mid Men (paypal payment)
http://www.fjrjtrade.com/category-1771-b0-Air-Force-one-Mid-Man.html
Wholesale Air Force One Mid Women (paypal payment)
http://www.fjrjtrade.com/category-1772-b0-Air-Force-one-Mid-Women.html
Wholesale Air Force One Women (paypal payment)
http://www.fjrjtrade.com/category-1633-b0-Air-Force-One%28W%29.html
Cheap Wholesale Air Force One Shoes
Wholesale Air Force One Shoes (paypal payment)
http://www.fjrjtrade.com/category-916-b0-Air-Force-one.html
Wholesale Air Force One 25 Men (paypal payment)
http://www.fjrjtrade.com/category-1627-b0-Air-Force-one-25%28M%29.html
Wholesale Air Force One 25 Women (paypal payment)
http://www.fjrjtrade.com/category-1628-b0-Air-Force-One-25%28W%29.html
Wholesale Air Force One Children (paypal payment)
http://www.fjrjtrade.com/category-1629-b0-Air-force-One-Children.html
Wholesale Air Force One low (paypal payment)
http://www.fjrjtrade.com/category-1630-b0-Air-Force-one%28low%29.html
Wholesale Air Force One M&W (paypal payment)
http://www.fjrjtrade.com/category-1631-b0-Air-Force-One%28MW%29.html
Wholesale Air Force One Mid (paypal payment)
http://www.fjrjtrade.com/category-1632-b0-Air-Force-one%28Mid%29.html
Wholesale Air Force One Mid Men (paypal payment)
http://www.fjrjtrade.com/category-1771-b0-Air-Force-one-Mid-Man.html
Wholesale Air Force One Mid Women (paypal payment)
http://www.fjrjtrade.com/category-1772-b0-Air-Force-one-Mid-Women.html
Wholesale Air Force One Women (paypal payment)
http://www.fjrjtrade.com/category-1633-b0-Air-Force-One%28W%29.html
Cheap Wholesale Air Force One Shoes
Wholesale Air Force One Shoes (paypal payment)
http://www.fjrjtrade.com/category-916-b0-Air-Force-one.html
Wholesale Air Force One 25 Men (paypal payment)
http://www.fjrjtrade.com/category-1627-b0-Air-Force-one-25%28M%29.html
Wholesale Air Force One 25 Women (paypal payment)
http://www.fjrjtrade.com/category-1628-b0-Air-Force-One-25%28W%29.html
Wholesale Air Force One Children (paypal payment)
http://www.fjrjtrade.com/category-1629-b0-Air-force-One-Children.html
Wholesale Air Force One low (paypal payment)
http://www.fjrjtrade.com/category-1630-b0-Air-Force-one%28low%29.html
Wholesale Air Force One M&W (paypal payment)
http://www.fjrjtrade.com/category-1631-b0-Air-Force-One%28MW%29.html
Wholesale Air Force One Mid (paypal payment)
http://www.fjrjtrade.com/category-1632-b0-Air-Force-one%28Mid%29.html
Wholesale Air Force One Mid Men (paypal payment)
http://www.fjrjtrade.com/category-1771-b0-Air-Force-one-Mid-Man.html
Wholesale Air Force One Mid Women (paypal payment)
http://www.fjrjtrade.com/category-1772-b0-Air-Force-one-Mid-Women.html
Wholesale Air Force One Women (paypal payment)
http://www.fjrjtrade.com/category-1633-b0-Air-Force-One%28W%29.html
Website:
http://www.fjrjtrade.com
==============================================================================
TOPIC: How can I use unqualified names? (Possibly hard or impossible?)
http://groups.google.com/group/comp.lang.c++/t/e2f24a95fe72b591?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Jul 26 2009 1:35 pm
From: "Alf P. Steinbach"
* James Kanze:
> On Jul 26, 11:11 am, "Alf P. Steinbach" <al...@start.no> wrote:
>> * James Kanze:
>
>>> On Jul 25, 11:23 am, "Alf P. Steinbach" <al...@start.no> wrote:
>>>> * James Kanze:
>>>>> I don't know. I don't really understand what's going on,
>>>>> without seeing the definitions of the macros you're using.
>
>>>> They're ugly! :-)
>
>>>> Or "in-elegant"...
>
>>>> Hence the plea for simpler pure-C++ solution that supports
>>>> the same, in particular extension and simple notation
>>>> (client code).
>
>>> Just curious, but why does it have to be "pure-C++"? As I
>>> said earlier, a short AWK script does the job just fine.
>
>> Why not pure C++?
>
> Because some other tool does the job better? "Pure C++" isn't a
> particular goal in my mind, any more than "pure OO" or pure
> anything else. I use the tools best fitted for the job.
Avoiding extra languages is a worthwhile goal.
With extra languages other people need to be familiar with them; you have code
generation which means that you have extra files that must be managed and must
not be modified; the build process needs to accomodate the code and you have at
least one extra build step; anyone wishing to use your code needs the tools for
the extra language, which may not be easily available; so on.
I see that as just needless complication & restriction.
>> If something as simple as this can't be expressed easily, then
>> at least we can (perhaps, hopefully) find out where the flaws
>> in the language are.
>
> Why is it necessarily a flaw in the language? No tool can be
> perfect for everything. Use the most appropriate tool.
Simple things should be simple to express.
C++ isn't an inappropriate language, but that's only due to the factors that
count against using physical code generation.
[snip]
>
>>>> <code>
>>>> #include <boost/mpl/clear.hpp>
>>>> #include <boost/mpl/front.hpp>
>>>> #include <boost/mpl/inherit.hpp>
>>>> #include <boost/mpl/inherit_linearly.hpp>
>>>> #include <boost/mpl/list.hpp>
>>>> #include <boost/mpl/pop_front.hpp>
>
>>>> namespace cppx { namespace typelist {
>
>>>> typedef boost::mpl::clear< boost::mpl::list<> >::type Empty;
>
>>> You've already lost me. I don't have the slightest
>>> knowledge of Boost::mpl, and in general, I find most of the
>>> advanced meta-programming idioms too complicated for general
>>> use.
>
>> I don't have the slightest knowledge either. I just used the
>> MPL typelist, checking the docs as I wrote, instead of
>> locating or downloading new version of Loki, or writing one
>> from scratch (it's pretty simple, really). The above
>> expression is probably overkill for its purpose: it addresses
>> that the type of 'mpl::list<>', a logically empty list of
>> types, is not the same as the type of an empty list produced
>> by reduction of a list. Probably just
>
>> typedef boost::mpl::list<>::type Empty;
>
>> would suffice to define the "real" empty list type.
>
>> But I don't know, I've never used that typelist implementation
>> before, and was a bit surprised that this was necessary.
>
> Well, that sounds like another reason to use something else. I
> wouldn't use a tool that I didn't at least vaguely understand.
*Hark*.
I find it difficult to believe that you're unfamiliar with typelists.
But anyway, a pencil is a pencil is a pencil, there is nothing mysterious about
them. If the pencil you grab to write something with is covered with very small
cactus-like things that hurt your fingers, then, after looking around to check
whether there's any other pencil near you, you simply wrap the pencil in
something, and perhaps remark: "huh, that's odd, why the heck did they design
the pencil that way". It's less work to wrap than to go buy a set of pencils.
> (It's a difficult issue, of course---I suspect that most C++
> programmers wouldn't be capable of writing a C++ compiler, and
> they shouldn't need that knowledge.
In contrast it's trivial to write a typelist implementation that provides basic
functionality, and any C++ programmer should be able to do so: any C++
programmer should be able to just sit down and write it without any second thought.
> But I don't even know what
> Boost::mpl---or anything in Loki---really does.)
Boost::mpl is much more than typelists.
But.
A typelist is a list of types. There are two main ways to build a typelist:
using the idea of a list as a head + a tail, which is a recursive definition,
and using the idea of a list as an array, which requires defaulting on template
parameters. The latter is what MPL does for the general 'list' type constructor,
which is the reason that a computed MPL empty list has a different type.
[snip]
> For using it, there is one argument in favor of all C++, if it's
> straightforward: presumable new people on the project will
> understand it immediately. IMHO, as soon as you use Boost::mpl,
> or Loki, you've lost that advantage.
Do you need to understand the details of the innards of your TV to use it?
I haven't found any need to be TV engineer (whatever) in order to use a TV.
Similarly, one does not need to understand template metaprogramming in order to
use something (such as my code) that uses that internally.
If you start looking at the inner parts that you don't understand, and think
that the high-voltage thingies etc. make the TV very dangerous, and that the
complexity of the circuitry inside makes the TV unsuable, well that's wrong.
Simply don't peer into the innards, use the controls at the front of the TV! :-)
> As for maintenance: the
> input file for my AWK script looks something like:
>
> x double 3.14159
> y int 42
> # ...
>
> It's hard for me to imagine anything easier to maintain---to add
> a new attribute, it's one line. (In the form I actually use,
> the AWK script is about twice as long, and the input has the
> form:
>
> [Option] # the class name...
> x double 3.14159
> y int 42
> # ...
>
> The results are two files, Option.hh and Option.cc.)
With C++ you add one line and modify the line that defines the class, e.g., with
JK as James Kanze macro prefix:
JK_DEF_OPT( x, 3.14159 )
JK_DEF_OPT( y, int, 42 )
JK_DEF_OPT_CLS_2( Option, nobase, x, y )
The result is generated code at the point of those macro invocations, no extra
files to care about and manage, no generated files to remember to not modify.
E.g. the code can be generated inside any desired namespace or class.
[snip]
> Extensible in what way?
My up-thread usage example's definition was
CPPX_DEFINE_OPTION( x, double )
CPPX_DEFINE_OPTION( y, double )
CPPX_DEFINE_2OPTIONCLASS( Pos2Options, cppx::options::NoBase, x, y )
CPPX_DEFINE_OPTION( z, double )
CPPX_DEFINE_1OPTIONCLASS( Pos3Options, Pos2Options, z )
where the last line expresses a base-derived class relationship.
>> In particular it can not, AFAICS, be used to produce the two
>> option classes in my example usage code shown earlier in
>> thread (natural modifications OK, of course), which you'll see
>> if you try.
>
> I'll look at it, but I'll admit that I've never found any reason
> to "extend" an options class. They're normally one-of sort of
> things.
So, this isn't the problem you've been dealing with. :-)
>> But you make me wonder: what does the script buy you over the
>> above, which AFAICS offers the same functionality with less
>> code and easier maintainance?
>
> First, the AWK stuff doesn't use macros, so doesn't impinge on
> the global namespace in anyway. (My actual AWK script handles
> options to specify the namespace in which to build the class,
> files to include, etc.) And the AWK stuff generates a complete
> class; there's absolutely nothing else to do. Still, for a
> one-of use, I'd use the above; the AWK script came about because
> it fulfilled a more or less recurrent need.
Namespace contamination is a valid concern, but it's minimal.
That the AWK stuff generates a complete class is not an argument in its favor.
It only indicates that there something so AWKward ;-) about it that generating a
complete class is somehow seen as an accomplishment. The C++ macros I presented
of course also generate a complete class.
And the C++ macros that I presented don't suffer from the problems of the AWK
script, i.e. with a proper C++ solution
* you don't generate extra files to worry about,
* you don't have extra tool requirements and extra tools usage, and
* you don't restrict the generated class' namespace or container class,
which with C++ is just where you invoke the macro.
>>> The resulting class will be bigger than necessary (since
>>> each Fallible requires an additional bool), and slightly
>>> slower, at least if the types involved are cheap to
>>> construct, but I doubt that it really matters in most cases.
>
>> If that's all that you require of the class then that scheme
>> is superb, because it's simple. :-) But the little
>> inefficiency is not necessary. Just replace Fallible with a
>> class that constructs the contained value with the specified
>> default.
>
> But then you have to maintain the default outside of the macro
> declarations.
No.
> IMHO, it's not usually a big deal, but it does
> mean that you have to cite the name of the attribute twice, and
> update in two locations if you add one.
>
>> Of course you need one such class per option, even when the
>> options are of the same type. And then you have the basic
>> options-as-types scheme... ;-)
>
> I'm not sure I follow. You need one class for each distinct set
> of options. Typically, in a GUI, there will only be one or two
> distinct sets of options... in a lot of GUI's, there will only
> be one (although some components may ignore certain options).
The reason you're not sure you follow is probably that you've interjected
comments so as to take the statement you don't follow out of context.
I was taking about replacing the Fallible class you used in your example.
I.e. replacing Fallible with something that for the purpose is simpler and more
efficient (actually I've already presented complete code for that).
>> But the above is not a superb solution to my little problem,
>> for it does not let you extend the resulting class except by
>> requiring the code that uses the setters to always use base
>> class setters last, which to me feels very wrong.
>
>> I think that problem indicates that there's a missing feature
>> in C++, because it "should" be trivial to express, and indeed
>> is trivial in any scripting language.
>
> The basic problem is that you're "generating" code. Which is
> fairly simple to express in interpreted languages like Lisp or
> the shell, which can interpret the code you've just generated.
> (In classical computer science, this is called "self modifying
> code", and has a very bad reputation with regards to
> maintainability.
Uh oh, careful now. The code isn't self-modifying. The code isn't the kind that
has a bad reputation. :-)
Cheers,
- Alf
== 2 of 2 ==
Date: Sun, Jul 26 2009 10:44 pm
From: "Alf P. Steinbach"
* Alf P. Steinbach:
> * James Kanze:
>
> [snip]
>> Extensible in what way?
>
> My up-thread usage example's definition was
>
> CPPX_DEFINE_OPTION( x, double )
> CPPX_DEFINE_OPTION( y, double )
> CPPX_DEFINE_2OPTIONCLASS( Pos2Options, cppx::options::NoBase, x, y )
>
> CPPX_DEFINE_OPTION( z, double )
> CPPX_DEFINE_1OPTIONCLASS( Pos3Options, Pos2Options, z )
>
> where the last line expresses a base-derived class relationship.
>
>
>>> In particular it can not, AFAICS, be used to produce the two
>>> option classes in my example usage code shown earlier in
>>> thread (natural modifications OK, of course), which you'll see
>>> if you try.
>>
>> I'll look at it, but I'll admit that I've never found any reason
>> to "extend" an options class. They're normally one-of sort of
>> things.
>
> So, this isn't the problem you've been dealing with. :-)
Perhaps an example can help you/others understand the intentded usage.
In MainWindow constructor (this is just ephemeral try-it-out code) there is
new Edit( *this, Edit::Params()
.text( L"Blah blah" )
.position( Point( 10, 10 ) )
.size( Point( 300, 20 ) )
);
new Button( *this, Button::Params()
.text( L"My button" )
.position( Point( 10, 40 ) )
.size( Point( 160, 24 ) )
.isDefault( true )
);
where the Params passed to the Edit control and the Params passed to the Button
control have the same .text, .position and .size elements, because they're
derived from the same base general window Params class.
The Params passed to the Button control have an additional .isDefault, which is
not meaningful for the Edit control and hence doesn't exist in Edit::Params.
In class Button the extra .isDefault option is added thusly, in a nested class
ApiWindowFactory:
class ApiWindowFactory
: public Outer::Base::ApiWindowFactory
{
typedef Outer::Base::ApiWindowFactory Base;
private:
bool myIsDefaultButton;
public:
CPPX_DEFINE_OPTION_VALUE( isDefault, bool, false )
CPPX_DEFINE_1OPTIONCLASS( Params, Base::Params, isDefault )
ApiWindowFactory(
Window& parentWindow,
Params const& params = Params()
)
: Base( parentWindow, params )
, myIsDefaultButton( params.isDefault() )
{}
virtual ButtonKind::Enum apiButtonKind() const
{
CPPX_IS_OVERRIDE_OF( Base::apiButtonKind );
return (myIsDefaultButton? ButtonKind::defPushButton :
ButtonKind::pushButton);
}
};
As you can see defining the derived Params with an extra .isDefault, adding in
derived class setters for all the base class elements (.text, .position, .size
etc.), is very very simple, two lines of code, placed right where the definition
is desired -- and no external script or extra files or ... :-)
There is a limitation of the macro implementations I posted earlier that the
base class can't be specified via typedef, but I don't consider that a problem;
rather, the problem is that I would want a simpler macro implementation.
Cheers,
- Alf
==============================================================================
TOPIC: Designer Ed hardy Womens Shoes - Discount
http://groups.google.com/group/comp.lang.c++/t/373a5a670eb26a0d?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Jul 26 2009 6:20 pm
From: gosee
Finding Designer Ed hardy Womens Shoes for wholesale & resell ?
Order Designer Ed hardy Womens Shoes - we show some keywords on each
products page,you have a wide choice on discounted.
Please see them:
http://www.showluxury.com/goods.php?id=1215
And find more new fashionable cloth,shoes and apparels,
Please check our web and feel free contact us.
Believe You can find anything of you want here!
==============================================================================
TOPIC: "Concepts" were removed from C++0x
http://groups.google.com/group/comp.lang.c++/t/2a650fa1f3c8016a?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Jul 26 2009 8:00 pm
From: "Tech07"
"Ioannis Vranos" <ivranos@freemail.gr> wrote in message
news:h47c90$l80$1@news.grnet.gr...
> Ioannis Vranos wrote:
>> I just happened to find the link in a forum:
>>
>>
>>
>> "The Rise and Fall of C++0x Concepts":
>>
>> http://www.devx.com/cplus/Article/42365
>
>
> Two other interesting links on the topic:
>
>
> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>
>
>
> Bjarne Stroustrup's thoughts:
>
> http://www.ddj.com/cpp/218600111
>
Were "concepts" a first attempt at invention by the committee? It would
appear from the above links that "the committee" admittedly does not have
such a capability and will stick to "standardizing existing practice". But
again, were "concepts" a test of that concept (that the comittee could
actually invent something useful)? Is it ironic that a committee of
developers (or is it one of those at all?!) cannot develop something? Were
they even trying?!! (or just trying to legitimitize the template concept,
"throwing good money after bad"?).
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment