http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Who gets higher salary a Java Programmer or a C++ Programmer? - 19 messages,
6 authors
http://groups.google.com/group/comp.lang.c++/t/4017272356b778c8?hl=en
* Types through a macro - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/bb3a4df299d49059?hl=en
* out of scope pointers in threads - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/1413d3875476ff47?hl=en
* incredible slowdown switching to 64 bit g++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/549e75880a00909c?hl=en
==============================================================================
TOPIC: Who gets higher salary a Java Programmer or a C++ Programmer?
http://groups.google.com/group/comp.lang.c++/t/4017272356b778c8?hl=en
==============================================================================
== 1 of 19 ==
Date: Fri, Nov 28 2008 12:20 pm
From: LR
Arne Vajhøj wrote:
> LR wrote:
>> James Kanze wrote:
>>> For some types of
>>> software, at laest. For real time software, it's less obvious,
>>> since it's fairly hard to be sure that you've analysed all
>>> possible timing issues.
>> I don't think testing all the possible interactions is possible for most
>> software. Consider a fairly simple program that reads inputs for say 64
>> boolean variables and has at least one conditional branch for each
>> variable.
>
> >> But it's still several orders of
> >> magnitude easier than verifying that you've analysed all
> >> possible physical interactions which might affect a bridge.
> >
> > But that isn't done. AFAIK ever. I don't think there's enough time in
> > the universe to do that. Not even for all the likely cases.
>
> That is a very unscientific and non-engineering way of
> thinking.
What about this way of thinking is unscientific or non-engineering. Do
>
> It can be done is most cases. It will not be done in most cases
> for cost reasons.
Time isn't a factor?
>
>>>> I was wondering if you
>>>> could take a shot at answering what I think is a simple
>>>> question with what might be a quick answer: What scientific
>>>> principle is being applied in "software engineering"?
>>> Mathematics.
>> Yeah, that's it then. Except math is not a science.
>
> Sure is.
>
> It is a formal science and a basis for all the empirical
> sciences.
Certainly not what I was taught in school.
LR
== 2 of 19 ==
Date: Fri, Nov 28 2008 12:22 pm
From: LR
AL wrote:
> LR wrote:
> [...] But to my mind that would make
>> "software engineering" a unique thing. Different from say chemical,
>> mechanical or civil. But perhaps there is another branch of engineering
>> that doesn't require the application of scientific principle?
>
> Perhaps there is.
Perhaps. Perhaps not.
I was wondering if perhaps someone could point out an instance instead
of referring to the class.
LR
== 3 of 19 ==
Date: Fri, Nov 28 2008 12:24 pm
From: Tom Anderson
On Fri, 28 Nov 2008, LR wrote:
> Lew wrote:
>> Martin Gregorie wrote:
>>>> Same here: its well recognised in the UK. I hold a CE in software
>>>> engineering as well as an MSc (Chemistry).
>>
>> Tom Anderson wrote:
>>> But i'm right in thinking that one doesn't need either of those to call
>>> oneself a software engineer, i hope?
>>
>> Absolutely.
>
> What is your understanding of the requirements to call yourself a
> software engineer?
In the UK, there are no requirements. We don't regulate the term
'engineer' directly, but instead have the specific title of Chartered
Engineer (we also have Chartered Accountants, Chartered Surveyors, etc),
which is regulated by a professional society, and which probably has exams
and rules and all sorts of things.
tom
--
Would you like to remember more?
== 4 of 19 ==
Date: Fri, Nov 28 2008 12:29 pm
From: LR
Kai-Uwe Bux wrote:
> James Kanze wrote:
>
>> On Nov 28, 1:28 am, Arne Vajhøj <a...@vajhoej.dk> wrote:
>>> Matthias Buelow wrote:
>>>> Lew wrote:
>>>> Also, it is impossible to
>>>> make perfect and totally reliable software.
>>> Not true.
>> I disagree. It is impossible to make a perfect and totally
>> reliable anything, as long as it is being made by human beings;
>> software is no different.
>
> You are getting philosophical :-)
In a discussion where people speak of programs being provably able to
halt, excuse me the set of programs that were written to the design of
being provably able to halt, philosophy is perfectly ok. Well, if the
philosophy is man made, perhaps not perfectly ok. ;)
> This is not how "perfect" is used in ordinary language. BTW: people
> sometimes get hickups about "true" and "to know", as well, and forget that
> they are using these terms on a daily basis in many non-controversal
> statements. The same applies to "perfect" and "totally reliable". There is
> no reasonable doubt that some things qualify as perfect and that some of
> them are man-made; otherwise, we probably wouldn't have a need for those
> terms. (Of course, there are many different opinions which things
> qualify :-)
Can a program be perfect? Provably so? Proof in the sense of
mathematical proof?
However, I note that I've read some stuff recently that suggests that
mathematicians have some doubts about the concept of proof.
LR
== 5 of 19 ==
Date: Fri, Nov 28 2008 12:30 pm
From: Patricia Shanahan
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> Lew wrote:
>>>> LR wrote:
>>>>> Tom Anderson wrote:
>>>>>
>>>>>> Still, i call myself a 'software engineer' because it sounds more
>>>>>> high-status than 'programmer', and i go to a lot of parties with lawyers
>>>>>> and academics and the like.
>>>>> IANAL, but since you're calling yourself a "software engineer" might I
>>>>> ask what jurisdiction you do that in?
>>>> I call myself a "software engineer" in Maryland, the U.S. of A.
>>>>
>>> On business cards? Letterhead? I'm sorry, I don't recall, did you say
>>> you were a PE?
>> Software engineer is a widely used title in the US.
>>
>> Try search on dice.com or monster.com !
>
> At one time, or so I was told in school, many people believed the world
> was flat. It did not make it so.
Indeed. One must look at the actual shape of the world to find out
whether the world is flat or not just as one must look at the actual
behavior of speakers of a language to find out what a term means in that
language.
Patricia
== 6 of 19 ==
Date: Fri, Nov 28 2008 12:38 pm
From: LR
Sabine Dinis Blochberger wrote:
> LR wrote:
[snips]
>
>
>>> The criteria are different, so you can't apply physical strength to any
>>> project. There is stress testing in software development.
>> There are viruses and bugs too. Is software development biology? I
>> don't mean to be flippant, but the mere use of a word doesn't confer
>> meaning on the object it refers to, does it?
>>
> The terms come from when computers were huge, room filling things with
> radio tubes. They would stop working properly when roaches/insects
> entered the structure, hence the term "bugs".
>
> Computer viruses are called that because of their self-replicating and
> -spreading characteristics.
May I take that as a no?
>
>>> The
>>> engineering part makes sure the software has been tested for all
>>> possible (and impossible) events/usages.
>> I suspect that this is not even likely. I gave a counter example else
>> thread involving input for a number of boolean variables, let's say 64.
>> Tough to test all of those.
>>
> And that's not what a sane person tests.
No one sane starts a task that can't be completed.
> The example yougive with booleans would be unit-tested, or otherwise at
> a "low" level of development. If you have a GUI with 64 check buttons,
> you really need to rethink that design.
Wasn't there a recent discussion in this ng about some compiler and the
interactions of it's many flags?
Perhaps that software wasn't "engineered". But I suspect that even if it
was, many of those options would still exist, many of them would
conflict, some of the ways that they'd conflict would cause the software
to fail, some of the failures would be immediately noticable. Some
would have more interesting consequences.
> If it is settings, then
> they/their effects need to be tested. No way around it.
How many tests do you think could be done every second and how long
would the testing take to complete?
> It usually suffices to make up test cases that cover areas - allowed
> inputs, impossible inputs, and wrong inputs (whatever that means within
> the project).
Assuming someone has the time to figure that out. How much time would
it take to do that for 64 inputs?
>
>>> And AFAIK civil engineers have formulas to calculate physical strengths
>>> and such, that are based on observation and experimentation.
>> They do. I'm sorry, did I say anything to indicate otherwise? If so,
>> please allow me to withdraw that. Although, I suspect they may not know
>> all there is to know about this yet. I also note that, AFAIK, at least
>> some of these are of comparatively recent origin. For example, I think
>> the use of timber in bridges wasn't even reasonably understood until
>> Herman Haupt did the experiments to figure out what the strength of the
>> beams were.
>
> That doesn't make it less engineering. Even inventors use engineering
> techniques.
I agree that using engineering techniques is not in anyway sufficient to
call an activity engineering.
LR
== 7 of 19 ==
Date: Fri, Nov 28 2008 12:39 pm
From: LR
James Kanze wrote:
> On Nov 28, 10:35 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
>> James Kanze wrote:
>>> On Nov 28, 1:28 am, Arne Vajhøj <a...@vajhoej.dk> wrote:
>>>> Matthias Buelow wrote:
>>>>> Lew wrote:
>>>>> Also, it is impossible to
>>>>> make perfect and totally reliable software.
>
>>>> Not true.
>
>>> I disagree. It is impossible to make a perfect and totally
>>> reliable anything, as long as it is being made by human beings;
>>> software is no different.
>
>> You are getting philosophical :-)
>
> Not really. Much of what makes engineering engineering is
> deciding just how close to perfect and totally reliable we have
> to be. Claiming perfection, however, is not responsible
> engineering (software or otherwise).
Is it in math?
LR
== 8 of 19 ==
Date: Fri, Nov 28 2008 12:43 pm
From: Kai-Uwe Bux
LR wrote:
[snip]
>
> Can a program be perfect? Provably so? Proof in the sense of
> mathematical proof?
There are correctness proofs for algorithms, and those proofs are
mathematical proofs. Whether that qualifies as a correctness proof for a
program depends in part on your understanding of the term "program". After
all, programs are to some degree algorithms worded in a programming
language and translated by a compiler on a specific piece of hardware; so
there are many things about which the correctness proof does not talk.
> However, I note that I've read some stuff recently that suggests that
> mathematicians have some doubts about the concept of proof.
Where did you read that? Neither my colleagues nor myself seem to have any
doubt about "the concept of proof". In fact, we devote a huge chunk of our
time to train students to produce exactly that old-fashioned thing called
proof. And I do not see any signs of change.
Best
Kai-Uwe Bux
== 9 of 19 ==
Date: Fri, Nov 28 2008 12:49 pm
From: LR
Arne Vajhøj wrote:
> LR wrote:
>> Lew wrote:
>>> Martin Gregorie wrote:
>>>>> Same here: its well recognised in the UK. I hold a CE in software
>>>>> engineering as well as an MSc (Chemistry).
>>> Tom Anderson wrote:
>>>> But i'm right in thinking that one doesn't need either of those to call
>>>> oneself a software engineer, i hope?
>>> Absolutely.
>> What is your understanding of the requirements to call yourself a
>> software engineer?
>
> In most places it is a job title not an academic title or other
> type of certification.
>
> So in most places the requirements is that a company will give
> you a job with that title.
Are you certain about this? As I've written else thread, my
understanding is there are legal issues surrounding calling yourself an
engineer of any type.
LR
== 10 of 19 ==
Date: Fri, Nov 28 2008 12:52 pm
From: LR
Arne Vajhøj wrote:
> LR wrote:
>> OTOH, I've never heard of someone actually being prosecuted for calling
>> themselves an engineer. I repeat IANAL, but I suspect, but do not know,
>> that if you did something that might be considered to be malpractice
>> whilst calling yourself an engineer things might get interesting.
>
> If someone design a bridge, it collapses and it turns out he is a
> software engineer with degree in computer science, then I am sure
> all hell will break out.
>
> But if a software engineer designs a piece of software that crashes
> then I can not imagine him being prosecuted for not having an
> engineering degree in bridge building.
I think it might depend on consequences of the failure and to who and
why it failed.
I think that engineers do sometimes get prosecuted for their failures in
much the same way that physicians do.
I didn't find a specific case, and this isn't proof, but evidence. A
google(tm) search for engineering malpractice insurance turns up quite a
few hits.
LR
== 11 of 19 ==
Date: Fri, Nov 28 2008 12:52 pm
From: Tom Anderson
On Fri, 28 Nov 2008, Martin Gregorie wrote:
> On Thu, 27 Nov 2008 21:13:44 +0000, Tom Anderson wrote:
>
>> On Thu, 27 Nov 2008, Martin Gregorie wrote:
>>
>>> On Wed, 26 Nov 2008 22:36:41 -0500, LR wrote:
>>>
>>>> Martin Gregorie wrote:
>>>>> On Wed, 26 Nov 2008 16:32:19 -0500, LR wrote:
>>>>>
>>>>>> But I think I made it plain that engineers don't consider the entire
>>>>>> physics of the bridge. They might not consider fluid interactions or
>>>>>> wind loading or some such. The parameters are likely to be driven
>>>>>> by budget, customer requirements or perhaps good practice.
>>>>>>
>>>>> That's quite wrong. The engineers who designed the Tay and the Tacoma
>>>>> Narrows bridges ignored wind and look where that got them.
>>>>
>>>> I'm sorry, but what is quite wrong? I completely fail to understand
>>>> how your response contradicts anything I wrote above. Please explain,
>>>> because I utterly bewildered by your response.
>>>
>>> This:
>>> "But I think I made it plain that engineers don't consider the entire
>>> physics of the bridge. They might not consider fluid interactions or
>>> wind loading or some such."
>>>
>>> I suggest you do some reading about those bridges.
>>
>> Hold up - those examples show that, in the cases of those bridges (or
>> Tacoma Narrows, at least), the engineers indeed did not consider wind
>> loading!
>
> Exactly so. Look back up this post and you'll see that "LR" said it
> didn't matter whether bridge designers looked at wind loading or not
No, he said they might not - and those examples clearly show that in some
cases they didn't. And why not? Perhaps budget was a factor, as he
suggests - the client didn't want to pay to have the job done properly.
But as you imply, nobody could reasonably disagree that bridge engineers
*should* consider wind and water, and i would imagine they almost always
do.
I think you may have been attaching different meanings to the precise
words used, that's all.
And now for something completely different - Edsger Dijkstra, writing in
1993, on why software engineering is "just humbug; from an academic i.e.
scientific and educational point of view it is a sham, a fraud":
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1165.html
The wikipedia article from which i cribbed that is worth a read:
http://en.wikipedia.org/wiki/Debates_within_software_engineering
tom
--
Would you like to remember more?
== 12 of 19 ==
Date: Fri, Nov 28 2008 12:53 pm
From: Arne Vajhøj
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> courpron@gmail.com wrote:
>>>> On 26 nov, 02:00, LR <lr...@superlink.net> wrote:
>>>>> courp...@gmail.com wrote:
>>>>>> On 25 nov, 15:38, LR <lr...@superlink.net> wrote:
>>>>>>> {...]
>>>>>>> Do the programs provably work? To the same extent that an engineer could
>>>>>>> "prove" that the bridge they designed will work?
>>>>>> There is a whole branch of computer science that is dedicated to
>>>>>> "program provability". In the practical world, the theory gave rise to
>>>>>> what is called "design by contract", by which you define formally the
>>>>>> specifications of your program with pre/postconditions, invariants,
>>>>>> etc. You can mathematically prove that your program will work by those
>>>>>> means. This is used in any sensible environment that needs absolutely
>>>>>> reliable softwares.
>>>>> Absolutely reliable? Suppose you have a customer who wants a formal
>>>>> proof that the program you've written will halt. Can you provide that?
>>>> Yes, absolutely reliable. The program is proven to be correct in any
>>>> way. The proof can be given in the form of mathematical notations.
>>> I'm not sure you responded to my question, so please allow me to restate
>>> it. Suppose you have a customer who wants a formal proof that the
>>> program you've written will halt, can you provide that?
>> Most likely yes.
>>
>> Computer science has proven that it is not possible to do that
>> for all programs, but it can be done for some programs. If one
>> is willing to spend the money, then it can be done for most
>> programs.
>>
>> (the examples used to prove the haling problem is not
>> generally solvable are not very realistic programs)
>
> What is the relevance of their being realistic programs or not?
You asked whether some real world programs could be verified to halt.
The fact that those programs and the programs that can be shown
not to halt are not similar is very relevant.
Arne
== 13 of 19 ==
Date: Fri, Nov 28 2008 12:53 pm
From: "Mike Schilling"
LR wrote:
>
> At one time, or so I was told in school, many people believed the
> world was flat. It did not make it so.
And what you were told might not be true. Certainly the ancient
Greeks know the world was round, both from the way that a ship sailing
towards you from over the horizon becomes visible from the top down,
and from the fact that the earth's shadow seen during a lunar eclipse
is curved. Medieval Europeans knew this too: Columbus's voyage seemed
risky not because he might fall off the edge, but because the voyage
was of unknown length. (And in fact, had the New World not been in
the way, he almost certainly would have perished in the
15,000-mile-wide ocean.)
I suppose the larger point stands,though: the fact that many people
think that the ancients believed the world was flat does not make it
so.
== 14 of 19 ==
Date: Fri, Nov 28 2008 12:55 pm
From: Arne Vajhøj
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> Lew wrote:
>>>> LR wrote:
>>>>> Tom Anderson wrote:
>>>>>
>>>>>> Still, i call myself a 'software engineer' because it sounds more
>>>>>> high-status than 'programmer', and i go to a lot of parties with lawyers
>>>>>> and academics and the like.
>>>>> IANAL, but since you're calling yourself a "software engineer" might I
>>>>> ask what jurisdiction you do that in?
>>>> I call myself a "software engineer" in Maryland, the U.S. of A.
>>>>
>>> On business cards? Letterhead? I'm sorry, I don't recall, did you say
>>> you were a PE?
>> Software engineer is a widely used title in the US.
>>
>> Try search on dice.com or monster.com !
>
> At one time, or so I was told in school, many people believed the world
> was flat. It did not make it so.
No.
People sailed around the globe and proved it was round.
You can prove to yourself that my statement is correct by doing the
search I suggested.
Arne
== 15 of 19 ==
Date: Fri, Nov 28 2008 12:58 pm
From: LR
Tom Anderson wrote:
> On Fri, 28 Nov 2008, LR wrote:
>
>> Lew wrote:
>>> Martin Gregorie wrote:
>>>>> Same here: its well recognised in the UK. I hold a CE in software
>>>>> engineering as well as an MSc (Chemistry).
>>> Tom Anderson wrote:
>>>> But i'm right in thinking that one doesn't need either of those to call
>>>> oneself a software engineer, i hope?
>>> Absolutely.
>> What is your understanding of the requirements to call yourself a
>> software engineer?
>
> In the UK, there are no requirements. We don't regulate the term
> 'engineer' directly, but instead have the specific title of Chartered
> Engineer (we also have Chartered Accountants, Chartered Surveyors, etc),
> which is regulated by a professional society, and which probably has exams
> and rules and all sorts of things.
Ok, that's good to know. Thanks.
LR
== 16 of 19 ==
Date: Fri, Nov 28 2008 12:59 pm
From: Arne Vajhøj
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> James Kanze wrote:
>>>> For some types of
>>>> software, at laest. For real time software, it's less obvious,
>>>> since it's fairly hard to be sure that you've analysed all
>>>> possible timing issues.
>>> I don't think testing all the possible interactions is possible for most
>>> software. Consider a fairly simple program that reads inputs for say 64
>>> boolean variables and has at least one conditional branch for each
>>> variable.
>> >> But it's still several orders of
>> >> magnitude easier than verifying that you've analysed all
>> >> possible physical interactions which might affect a bridge.
>> >
>> > But that isn't done. AFAIK ever. I don't think there's enough time in
>> > the universe to do that. Not even for all the likely cases.
>>
>> That is a very unscientific and non-engineering way of
>> thinking.
>
> What about this way of thinking is unscientific or non-engineering.
Not distinguishing between what is possible and what is
practical possible.
>> It can be done is most cases. It will not be done in most cases
>> for cost reasons.
>
> Time isn't a factor?
It can be. In most cases time is just a surrogate for cost.
>>>>> I was wondering if you
>>>>> could take a shot at answering what I think is a simple
>>>>> question with what might be a quick answer: What scientific
>>>>> principle is being applied in "software engineering"?
>>>> Mathematics.
>>> Yeah, that's it then. Except math is not a science.
>> Sure is.
>>
>> It is a formal science and a basis for all the empirical
>> sciences.
>
> Certainly not what I was taught in school.
Possible.
But did you ever notice what a master degree in math is called ?
Arne
== 17 of 19 ==
Date: Fri, Nov 28 2008 1:03 pm
From: Arne Vajhøj
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> Lew wrote:
>>>> Martin Gregorie wrote:
>>>>>> Same here: its well recognised in the UK. I hold a CE in software
>>>>>> engineering as well as an MSc (Chemistry).
>>>> Tom Anderson wrote:
>>>>> But i'm right in thinking that one doesn't need either of those to call
>>>>> oneself a software engineer, i hope?
>>>> Absolutely.
>>> What is your understanding of the requirements to call yourself a
>>> software engineer?
>> In most places it is a job title not an academic title or other
>> type of certification.
>>
>> So in most places the requirements is that a company will give
>> you a job with that title.
>
> Are you certain about this? As I've written else thread, my
> understanding is there are legal issues surrounding calling yourself an
> engineer of any type.
I have already told you how you can verify it (look at job ads sites).
Arne
== 18 of 19 ==
Date: Fri, Nov 28 2008 1:05 pm
From: Tom Anderson
On Fri, 28 Nov 2008, LR wrote:
> Martin Gregorie wrote:
>> On Thu, 27 Nov 2008 21:21:01 +0000, Tom Anderson wrote:
>>
>>> Oh, absolutely. I'm not knocking the value of qualifications! At least,
>>> not all of them. I was just wondering if my lack of them made me a
>>> criminal.
>>
>> Why on earth would it do that?
>>
>> We're not yet /required/ to belong to a professional association like
>> medical doctors.
>
> Are doctors required to belong to a professional association?
Yes.
Although it's a matter of registration with them, rather than membership
per se.
> May I ask what jurisdiction you're speaking of.
Martin and i are both sited in the UK. As, in his case, his sig makes
clear.
> However, in almost every jurisdiction that I know of where it would
> matter, software engineers, actually anyone who calls themselves an
> engineer, like doctors, lawyers and hairdressers are required to have a
> license.
>
> Am I wrong?
Yes.
Also, whilst the term is formally regulated in the USA, i don't believe
the regulation has any teeth in practice.
tom
--
Would you like to remember more?
== 19 of 19 ==
Date: Fri, Nov 28 2008 1:06 pm
From: Arne Vajhøj
LR wrote:
> Arne Vajhøj wrote:
>> LR wrote:
>>> OTOH, I've never heard of someone actually being prosecuted for calling
>>> themselves an engineer. I repeat IANAL, but I suspect, but do not know,
>>> that if you did something that might be considered to be malpractice
>>> whilst calling yourself an engineer things might get interesting.
>> If someone design a bridge, it collapses and it turns out he is a
>> software engineer with degree in computer science, then I am sure
>> all hell will break out.
>>
>> But if a software engineer designs a piece of software that crashes
>> then I can not imagine him being prosecuted for not having an
>> engineering degree in bridge building.
>
> I think it might depend on consequences of the failure and to who and
> why it failed.
If someone prosecuted a software engineer for not having an
engineering degree in bridge building should have their head
examined by a shrink.
> I think that engineers do sometimes get prosecuted for their failures in
> much the same way that physicians do.
>
> I didn't find a specific case, and this isn't proof, but evidence. A
> google(tm) search for engineering malpractice insurance turns up quite a
> few hits.
When I make that search there do not show any hits up about software
engineers being prosecuted for not having an engineering degree in
construction.
So please provide a link to one of your hits.
Arne
==============================================================================
TOPIC: Types through a macro
http://groups.google.com/group/comp.lang.c++/t/bb3a4df299d49059?hl=en
==============================================================================
== 1 of 4 ==
Date: Fri, Nov 28 2008 12:30 pm
From: Kaba
Hello,
Assume:
template <typename A, typename B>
class C
{
};
#define MACRO(x) x
template <typename D>
class E
{
};
What I'd like to do is essentially the following:
E<MACRO(C<int, int>)> e;
However, now the comma inside the macro is interpreted as separating
macro parameters which results in an error. Ok, let us try to add
parentheses:
E<MACRO((C<int, int>))> e;
This get's rid of the earlier error but brings another one: the
declaration
E<(C<int, int>)> e;
is not legal C++.
Is there a way around?
Aside, it seems that
(C<int, int>) c;
is legal. What else can you do with parenthesized types?
== 2 of 4 ==
Date: Fri, Nov 28 2008 12:45 pm
From: Andrey Tarasevich
Kaba wrote:
>
> What I'd like to do is essentially the following:
>
> E<MACRO(C<int, int>)> e;
>
> However, now the comma inside the macro is interpreted as separating
> macro parameters which results in an error. Ok, let us try to add
> parentheses:
>
> E<MACRO((C<int, int>))> e;
>
> This get's rid of the earlier error but brings another one: the
> declaration
>
> E<(C<int, int>)> e;
>
> is not legal C++.
>
> Is there a way around?
There is, but it is ugly to the point of being virtually unusable
#define ARGS C<int, int>
E<MACRO(ARGS)> e;
#undef ARGS
--
Best regards,
Andrey Tarasevich
== 3 of 4 ==
Date: Fri, Nov 28 2008 12:55 pm
From: Kaba
Kaba wrote:
> Is there a way around?
Oh, I came up with a solution:
#define DEDUCTION(x) typename Deductor<void ##x>::Result
template <typename Type>
class Deductor
{
};
template <typename Type>
class Deductor<void (Type)>
{
public:
typedef Type Result;
};
template <int A, typename B>
class A
{
};
template <typename C>
class B
{
};
int main()
{
B<DEDUCTION((A<1, int>))> a;
return 0;
}
== 4 of 4 ==
Date: Fri, Nov 28 2008 12:56 pm
From: Kaba
Andrey Tarasevich wrote:
> There is, but it is ugly to the point of being virtually unusable
>
> #define ARGS C<int, int>
> E<MACRO(ARGS)> e;
> #undef ARGS
Thanks for your reply:)
==============================================================================
TOPIC: out of scope pointers in threads
http://groups.google.com/group/comp.lang.c++/t/1413d3875476ff47?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Nov 28 2008 1:11 pm
From: Pete Becker
On 2008-11-28 14:47:04 -0500, James Kanze <james.kanze@gmail.com> said:
> (I'm guessing here that
> LPVOID is a void*; where the L comes from, I don't know.)
The L stands for LONG. It's from the days when Windows still exposed
the Intel segmented architecture, so there were SHORT and LONG variants
of pointers.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
==============================================================================
TOPIC: incredible slowdown switching to 64 bit g++
http://groups.google.com/group/comp.lang.c++/t/549e75880a00909c?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Nov 28 2008 1:19 pm
From: nandor.sieben@gmail.com
Thank you everybody for the help. I have found the solution.
It is simple, I just need the compiler flag -ffast-math.
==============================================================================
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