comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=encomp.lang.c++@googlegroups.com
Today's topics:
* Unresolved external - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/a789cd8350122100?hl=en
* Who gets higher salary a Java Programmer or a C++ Programmer? - 7 messages,
4 authors
http://groups.google.com/group/comp.lang.c++/t/4017272356b778c8?hl=en
* Types through a macro - 8 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/bb3a4df299d49059?hl=en
* The Java vs C++ higher salary thread - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/be2a8dac2cb503c3?hl=en
* out of scope pointers in threads - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/1413d3875476ff47?hl=en
* inorder traversal in binary tree class - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/ccf460b6cbb39dab?hl=en
* "free(): invalid next size" when using std::map as a class member - 2
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/d919e86752ec61ce?hl=en
==============================================================================
TOPIC: Unresolved external
http://groups.google.com/group/comp.lang.c++/t/a789cd8350122100?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Nov 30 2008 7:50 am
From: Obnoxious User
On Sun, 30 Nov 2008 15:00:07 +0000, Kenny M wrote:
> I am trying to build a program written by a colleague and get an
> 'unresolved external' error when I run the Borland make utility
> (offending function below). Any ideas what's wrong? I am not a c++
> programmer so a simple solution would be very welcome.
>
> /*
> * strtoko.cpp
> *
> * Does exactly the same as the standard function "strtok", but *
> also rebuilds the original string as it goes, but storing the *
> separator which was overwritten with an end-of-string and restoring
> * it on the subsequent entry.
> *
> * Returns a pointer to the next symbol found, or NULL if end of
> string.
> *
> * s i-o : string to be scanned. * ct in : string containing
> all valid separators. */
>
> #include <stdio.h>
> #include <string.h>
> #include <stdlib.h>
>
> char *strtoko( char *s, const char *ct )
>
> { static char *localp, hold;
> char *token;
>
> if ( s != NULL )
> localp = s;
> else
> { if ( localp == NULL )
> { fprintf( stderr, "\nError in 'strtoko' : Called with NULL
> prior " );
> fprintf( stderr, "to a call with string for scanning.\n"
> );
> exit(1);
> }
> if ( hold == '\0' ) return( NULL );
> *localp = hold;
> localp++;
> }
>
> localp += strspn( localp, ct ); /* skip over any separator
> characters */
> if ( localp == '\0' ) return( NULL ); token = localp;
> localp += strcspn( localp, ct ); /* skip to next separator (or
> end-string)*/
> hold = *localp;
> *localp = '\0';
> return( token );
> }
Do you link strtoko.o?
--
OU
Remember 18th of June 2008, Democracy died that afternoon.
http://frapedia.se/wiki/Information_in_English
== 2 of 2 ==
Date: Sun, Nov 30 2008 10:30 am
From: "Thomas J. Gritzan"
Kenny M schrieb:
> I am trying to build a program written by a colleague and get an
> 'unresolved external' error when I run the Borland make utility
> (offending function below). Any ideas what's wrong? I am not a c++
> programmer so a simple solution would be very welcome.
First, this is not a program, it is a function. You would have to
provide a main function that calls the function.
The simplest solution would be to ask your colleague for a main function.
Second, the code compiles with a C compiler, so it actually is C code.
It is C++ code too, but in modern C++ you normally want to use
std::string and friends.
> /*
> * strtoko.cpp
> *
> * Does exactly the same as the standard function "strtok", but
> * also rebuilds the original string as it goes, but storing the
> * separator which was overwritten with an end-of-string and
> restoring
> * it on the subsequent entry.
[...]
> char *strtoko( char *s, const char *ct )
>
> { static char *localp, hold;
> char *token;
The function is not reentrant. Since this function is supposed to be a
better strtok, I would at least fix that. Of course the interface
(function signature) would need to be changed for this.
> if ( s != NULL )
> localp = s;
> else
> { if ( localp == NULL )
> { fprintf( stderr, "\nError in 'strtoko' : Called with NULL
> prior " );
> fprintf( stderr, "to a call with string for scanning.\n"
> );
> exit(1);
I would ASSERT here (in debug mode), and return NULL otherwise. It is a
programming/logic error, and a library function shouldn't exit() a program.
> if ( hold == '\0' ) return( NULL );
> *localp = hold;
> localp++;
> }
>
> localp += strspn( localp, ct ); /* skip over any separator
> characters */
> if ( localp == '\0' ) return( NULL );
This condition is never true. It should be:
if ( *localp == '\0' ) return( NULL );
Otherwise, it won't find the end of the string sometimes.
> token = localp;
> localp += strcspn( localp, ct ); /* skip to next separator (or
> end-string)*/
> hold = *localp;
> *localp = '\0';
> return( token );
> }
--
Thomas
==============================================================================
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 7 ==
Date: Sun, Nov 30 2008 8:11 am
From: LR
Keith H Duggar wrote:
> [snip] science
> does not require "proof"; it requires testing.
Testing of things that are observable in the real world?
> The Four Color
> Theorem was a well tested and practical "fact" long before it
> was mathematically proved.
I remember being taught in geometry class that points and lines, in the
sense that geometry uses the terms, are not real and do not exist.
While I suspect that much of plane geometry developed from observation,
it requires proof, not testing of something observable.
LR
== 2 of 7 ==
Date: Sun, Nov 30 2008 8:39 am
From: Lew
LR wrote:
> I remember being taught in geometry class that points and lines, in the
> sense that geometry uses the terms, are not real and do not exist.
Of course they exist, or we wouldn't even be able to talk about them. One
could argue that mathematical existence is stronger and more real than
physical existence.
The discussion of the nature of being as such, i.e., what exists and doesn't
exist, was the subject of one of the most fascinating and enduringly relevant
courses I took at university.
Even more relevant is the question of applied ontology - how one can empower
oneself through insight into the nature of being as such.
When you assert that points and lines don't exist, you start down a slippery
slope that in the Usenet context is unlikely to resolve much. On the flip
side one could argue that quanta, quarks and the like don't exist, or perhaps
that I don't exist and you are actually arguing with yourself. In fact, with
respect to physical existence, quantum mechanics tells us that nothing
absolutely exists, only probabilistically. I subscribe to the notion that
existence is just the Red King's dream, and when he wakes up we'll all vanish.
--
Lew
== 3 of 7 ==
Date: Sun, Nov 30 2008 11:37 am
From: Keith H Duggar
On Nov 30, 11:11 am, LR <lr...@superlink.net> wrote:
> Keith H Duggar wrote:
> > [snip] science
> > does not require "proof"; it requires testing.
>
> Testing of things that are observable in the real world?
Observation is required. Neither "things" nor a "real world"
need be defined (if you can even define them suitably).
In the most pedantic form, a scientific hypothesis consists
of a detailed description of an experimental setup, methods,
conditions, procedures, etc and a predicted observation. In
practice such details are not pedantically spelled out since
there is a large shared body of auxiliary knowledge that we
can rely upon to communicate the details. For example, if we
hypothesize that the boiling point of water depends on salt
concentration we might specify the hypothesis thusly:
1) dissolve sodium chloride in distilled water to prepare
salt solutions at concentrations of 2.0, 1.0, 0.5, 0.25,
and 0.125 molar.
2) for each solution pour 150ml into a clean 250ml Pyrex
beaker. Use an arm clamp to suspend a thermometer in the
center of the fluid and drop a magnetic stir bar into the
beaker.
3) Use a hot plate with low stir to heat the solution to a
vigorous boil.
4) Once the temperature stabilizes note the reading.
There is a great deal of assumed common knowledge in such a
description. For example, it does not explain what distilled
water and sodium chloride are nor how to produce them. It does
not explain how to construct a thermometer nor a Pyrex beaker.
Etc, etc, etc. One could write thousands of pages describing
the details of such a simple experiment as this and still not
cover every possible detail or objection.
But then, it is not necessary to cover every detail for it is
by the very process of science that we refine our descriptions
and methods when needed. Science strives to develop a coherent
body of knowledge, not an absolute body of knowledge.
> > The Four Color
> > Theorem was a well tested and practical "fact" long before it
> > was mathematically proved.
>
> I remember being taught in geometry class that points and
> lines, in the sense that geometry uses the terms,
Even very young children know how to draw maps on a piece
of paper and how to color them. Hopefully your high-school
geometry class did not rob you of that simple ability?
> are not real and do not exist.
What does "real" mean? What does "exist" mean? No matter,
whatever those words mean science does not concern itself
with such definitions nor other metaphysical meaning.
> While I suspect that much of plane geometry developed from
> observation, it requires proof,
"it requires proof" -- "requires" for what purpose? Geometric
rules were discovered and used successfully for thousands of
years in the Ancient world before they were "proved". Again,
science does not require "proof" no matter how many times you
claim that it does.
> not testing of something observable.
Testing of observables such as this pyramid has the right
height, Venus rose when expected, the rocket reached orbit,
etc is what science requires; it does not require "proof".
Do you understand these points now?
KHD
== 4 of 7 ==
Date: Sun, Nov 30 2008 12:09 pm
From: LR
Keith H Duggar wrote:
> On Nov 30, 11:11 am, LR <lr...@superlink.net> wrote:
>> I remember being taught in geometry class that points and
>> lines, in the sense that geometry uses the terms, are not real and do not exist.
>
> What does "real" mean? What does "exist" mean?
Would saying that points and lines, as the terms are used in geometry,
are abstract and/or conceptual, work for you?
> No matter,
I think it's an important distinction.
LR
== 5 of 7 ==
Date: Sun, Nov 30 2008 1:26 pm
From: Keith H Duggar
On Nov 30, 3:09 pm, LR <lr...@superlink.net> wrote:
> Keith H Duggar wrote:
> > On Nov 30, 11:11 am, LR <lr...@superlink.net> wrote:
> > > I remember being taught in geometry class that points and
> > > lines, in the sense that geometry uses the terms, are not
> > > real and do not exist.
>
> > What does "real" mean? What does "exist" mean?
>
> Would saying that points and lines, as the terms are used in
> geometry, are abstract and/or conceptual, work for you?
Work for me to what end? It seems that you have some place you
want to get to. Some notion you want to persuade us to believe.
I remain as a participant in this thread solely to help raise
you from your admitted ignorance of engineering. In other words
to educate you. I have absolutely no desire to be lured into an
evergreen debate of semantics and metaphysics.
Now, there is much substance in my most recent posts that you
did not respond to. I suggest you contemplate them further and
then respond by pointing out explicitly what you have learned
or now agree with and your remaining questions of substance.
> > No matter,
>
> I think it's an important distinction.
It is far more important that you stop snipping and responding
to conjunctions and instead respond substantively to the entire
substance of posts, if you were serious about wanting to learn.
I must say you are demonstrating the lack of any such intention
in this and many of you other posts. Phrases like "Ok, perhaps
you got me", "work for you?", "the particular idea I am trying
to explain here", "I've gotten .. over the past apprx 35 years",
"I don't know anyone who ...", "I don't think anyone ever, or at
least not since Newton ...", etc are red flags.
KHD
== 6 of 7 ==
Date: Sun, Nov 30 2008 2:30 pm
From: LR
Keith H Duggar wrote:
> On Nov 30, 3:09 pm, LR <lr...@superlink.net> wrote:
>> Keith H Duggar wrote:
>>> On Nov 30, 11:11 am, LR <lr...@superlink.net> wrote:
>>>> I remember being taught in geometry class that points and
>>>> lines, in the sense that geometry uses the terms, are not
>>>> real and do not exist.
>>> What does "real" mean? What does "exist" mean?
>> Would saying that points and lines, as the terms are used in
>> geometry, are abstract and/or conceptual, work for you?
>
> Work for me to what end?
Work for you to understand what I meant within the context of this
discussion.
> It is far more important that you stop snipping and responding
> to conjunctions and instead respond substantively to the entire
> substance of posts, if you were serious about wanting to learn.
I think that I've learned a few things from this thread, some even
directly related to the subject matter that was discussed. Some of the
things I already knew have been reinforced. Some I didn't know before.
From that perspective it's been somewhat useful for me, for which I am
always grateful. I am also grateful for the chance to practice my
admittedly limited communication skills.
I've tried to be careful about responding frankly to the substantive
parts of other people's posts, but perhaps I've failed in this. Your
suggestions in this regard makes me think that profitably communicating
with you on these issues rises to a level of difficulty that I am unable
to overcome. I would like to thank you for making the attempt.
LR
== 7 of 7 ==
Date: Sun, Nov 30 2008 3:02 pm
From: Arne Vajhøj
Keith H Duggar wrote:
> On Nov 30, 11:11 am, LR <lr...@superlink.net> wrote:
>> Keith H Duggar wrote:
>>> [snip] science
>>> does not require "proof"; it requires testing.
>> Testing of things that are observable in the real world?
>
> Observation is required. Neither "things" nor a "real world"
> need be defined (if you can even define them suitably).
>
> In the most pedantic form, a scientific hypothesis consists
> of a detailed description of an experimental setup, methods,
> conditions, procedures, etc and a predicted observation. In
> practice such details are not pedantically spelled out since
> there is a large shared body of auxiliary knowledge that we
> can rely upon to communicate the details.
Now you are talking about natural sciences not all sciences.
Arne
==============================================================================
TOPIC: Types through a macro
http://groups.google.com/group/comp.lang.c++/t/bb3a4df299d49059?hl=en
==============================================================================
== 1 of 8 ==
Date: Sun, Nov 30 2008 8:12 am
From: courpron@gmail.com
On 30 nov, 14:42, Kaba <n...@here.com> wrote:
> wrote:
> > > However, using a separate Identity metafunction is more generic.
>
> > Question is : " does we really need this generecity, since we control
> > the declaration of the class ?"
>
> > Generally, you use the identity function from a library, boost for
> > example (otherwise the "identity" solution is obviously the worst one
> > since you have to declare the identity structure each time).
>
> > So the identity solution requires :
> > -including the header :
> > #include "...."
>
> Yep. Anyway, I have to include one specific header file anyway which
> contains my own type definitions, such as
>
> typedef float real;
>
> which I can use to decide if I wan't to use float or doubles in my
> library. There I can include the implementation:
At first sight, I would say that *generic* structures like Identity
(or macros like yours) and *specific-to-the-project* typedefs like
the one above should not belong to the same header file. I suppose
there are specific cases where it might be ok though, but generally
it's not a clean design.
>
> #define PASTEL_NO_DEDUCTION(x) typename Pastel::ParenthesesRemover<void
> (x)>::Type
>
> namespace Pastel
> {
>
> template <typename T>
> class ParenthesesRemover
> {
> };
>
> template <typename T>
> class ParenthesesRemover<void (T)>
> {
> public:
> typedef T Type;
> };
>
> }
If you think you have a clearer interface using this macro, then I
guess this solution is perfectly ok, especially if you use it in a one-
man/small-team project. However, a macro, leaving the usual drawbacks
aside, hides the real expression to a reader of your code. Whether it
is good or not is a matter of opinion. I tend to believe the usage of
a macro in C++ is justified mainly in 4 situations :
- the substituted expression is complex / long / hard to understand
- the name of the macro is very widely known (e.g. STATIC_ASSERT) so
that its signification is clear to everyone
- taking care of issues about a specific compiler/environnment on a
portable project
- preprocessor metaprogramming
The first situation might be applied to your macro. But, of course, as
I said, that's a matter of opinion.
> > On the other hand, the type_trait solution just need a nested
> > typedef :
> > typedef Type type_trait;
>
> However, this is intrusive
The "instrusive" argument does not stand since we have the control of
the class definition.
> and in principle this information does not
> belong in the class.
I don't see why it should not belong to the class. It is precisely a
direct property of the class type.
>
> > It seems that, with the identity solution, you have to write more
> > code, you depend on an external structure and on an (additional)
> > library, and you put more stress on the compiler.
>
> I think it works out nice. To demonstrate, my current library has 362
> uses of the macro PASTEL_NO_DEDUCTION as given. Let us pick some
> examples:
>
> template <int N, typename Real>
> Vector<N, Real> refract(
> const Vector<N, Real>& from,
> const Vector<N, Real>& normal,
> const PASTEL_NO_DEDUCTION(Real)& fromIndex,
> const PASTEL_NO_DEDUCTION(Real)& toIndex);
>
> template <typename Type>
> ConstantColorImageSampler<Type> constantColorImageSampler(
> const PASTEL_NO_DEDUCTION(Type)& color);
>
> template <int N, typename Image_View>
> void diamondElement(
> const View<N, bool, Image_View>& image,
> const PASTEL_NO_DEDUCTION((Vector<N, real>))& diameter);
>
> As you can see its uses are frequent and varied. Sometimes there is no
> type to attach the type into: in this case the more generic alternative
> is required.
Yes, however those uses are outside the problem you described in your
article. Again that's perfectly ok for a specific project.
Nonetheless, as a general pattern for the problem you described, the
type trait solution seems to be smoother than a generic solution that
requires an external structure and a macro.
Alexandre Courpron.
== 2 of 8 ==
Date: Sun, Nov 30 2008 9:58 am
From: Kaba
> If you think you have a clearer interface using this macro, then I
> guess this solution is perfectly ok, especially if you use it in a one-
> man/small-team project. However, a macro, leaving the usual drawbacks
> aside, hides the real expression to a reader of your code. Whether it
> is good or not is a matter of opinion. I tend to believe the usage of
> a macro in C++ is justified mainly in 4 situations :
> - the substituted expression is complex / long / hard to understand
> - the name of the macro is very widely known (e.g. STATIC_ASSERT) so
> that its signification is clear to everyone
> - taking care of issues about a specific compiler/environnment on a
> portable project
> - preprocessor metaprogramming
>
> The first situation might be applied to your macro. But, of course, as
> I said, that's a matter of opinion.
The reason is as you state. The problem is that 'typename Identity
<Type>::Result' (or a more suggestive 'typename NoDeduction
<Type>::Result') would clutter my interfaces unreadable (to my eyes).
For the most part I avoid macros as far as possible, but here I can't
see a way to make the syntax nice without a macro. On the other hand,
it's not that bad since clashing the name of the macro is pretty
improbable. Can you see other options?
> > However, this is intrusive
>
> The "instrusive" argument does not stand since we have the control of
> the class definition.
>
> > and in principle this information does not
> > belong in the class.
>
> I don't see why it should not belong to the class. It is precisely a
> direct property of the class type.
We could be talking of different situations here. The problem in the
article is just one instance of the general problem of restricting
template parameter deduction. In general, how you want the template
deduction to work for each function should not relate to what types you
work with.
> Yes, however those uses are outside the problem you described in your
> article. Again that's perfectly ok for a specific project.
> Nonetheless, as a general pattern for the problem you described, the
> type trait solution seems to be smoother than a generic solution that
> requires an external structure and a macro.
I am not sure what you refer to with the problem I described. To me the
general problem is to restrict template parameter deduction. If you mean
the specific problem given in the article, in isolation, then you might
be right. However, when we extend the technique over the whole library
then your technique does not, in my opinion, generalize in a practical
manner.
--
http://kaba.hilvi.org
== 3 of 8 ==
Date: Sun, Nov 30 2008 12:12 pm
From: courpron@gmail.com
On 30 nov, 18:58, Kaba <n...@here.com> wrote:
> [...]
> The reason is as you state. The problem is that 'typename Identity
> <Type>::Result' (or a more suggestive 'typename NoDeduction
> <Type>::Result') would clutter my interfaces unreadable (to my eyes).
> For the most part I avoid macros as far as possible, but here I can't
> see a way to make the syntax nice without a macro. On the other hand,
> it's not that bad since clashing the name of the macro is pretty
> improbable. Can you see other options?
Another option to make the interface clearer ?
Well no, at least not in C++03. In fact the construct "typename
my_struct<T>::type" is a pretty basic one and sometimes the only
purpose of structures like my_struct is to encapsulate a more complex
expression in order to give a simpler interface.
> > > However, this is intrusive
>
> > The "instrusive" argument does not stand since we have the control of
> > the class definition.
>
> > > and in principle this information does not
> > > belong in the class.
>
> > I don't see why it should not belong to the class. It is precisely a
> > direct property of the class type.
>
> We could be talking of different situations here. The problem in the
> article is just one instance of the general problem of restricting
> template parameter deduction. In general, how you want the template
> deduction to work for each function should not relate to what types you
> work with.
Yes I think we are talking about different problems. See below.
>
> > Yes, however those uses are outside the problem you described in your
> > article. Again that's perfectly ok for a specific project.
> > Nonetheless, as a general pattern for the problem you described, the
> > type trait solution seems to be smoother than a generic solution that
> > requires an external structure and a macro.
>
> I am not sure what you refer to with the problem I described.
The problem I'm referring to is the one you stated at the beginning of
your article :
"The problem is to make a generalization of class A, a class template
D, that can use float, or any other type Type as the underlying type,
and that works for float exactly like the given class A. "
This is already a general problem, and the type trait solution is a
simple pattern to use, that depends on nothing, and is flexible ( i.
e., if it's needed, you can also use a custom type trait instead of
the straight template parameter of the class, depending on the class
specializations, etc.).
The problem you are referring to concerns the capability of putting an
arbitrary type in a non-deduced context. In that case, you indeed need
a generic and non-intrusive solution.
Alexandre Courpron.
== 4 of 8 ==
Date: Sun, Nov 30 2008 2:40 pm
From: "Chris M. Thomasson"
"Kaba" <none@here.com> wrote in message
news:MPG.239a816e68a85a8c98972c@news.cc.tut.fi...
> 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?
what about something simple like:
#define INVOKE(X) X()
template<typename A, typename B>
class C {
};
template<typename D>
class E {
};
#define TYPE1() C<int, int>
#define TYPE2() C<char, char>
#define TYPE3() C<short, int>
E<INVOKE(TYPE1)> e1;
E<INVOKE(TYPE2)> e2;
E<INVOKE(TYPE3)> e3;
int main() {
return 0;
}
?
== 5 of 8 ==
Date: Sun, Nov 30 2008 2:44 pm
From: "Chris M. Thomasson"
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:RCEYk.2985$4c1.1820@newsfe25.iad...
[...]
Ahhh, nevermind. That's not what you want. I should have read the thread.
;^(...
== 6 of 8 ==
Date: Sun, Nov 30 2008 2:49 pm
From: "Chris M. Thomasson"
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:WGEYk.2988$4c1.2816@newsfe25.iad...
>
> "Chris M. Thomasson" <no@spam.invalid> wrote in message
> news:RCEYk.2985$4c1.1820@newsfe25.iad...
> [...]
>
> Ahhh, nevermind. That's not what you want. I should have read the thread.
>
> ;^(...
Humm... What about something really odd like:
#define CONCAT_X(T1, T2)T1##T2
#define CONCAT(T1, T2)CONCAT_X(T1, T2)
#define PLACE_1(X) X
#define PLACE_2(X1, X2) X1, X2
#define PLACE_3(X1, X2, X3) X1, X2, X3
#define PLACE_4(X1, X2, X3, X4) X1, X2, X3, X4
#define PLACE(D, X)CONCAT(PLACE_, D)X
template<typename A, typename B>
class C {
};
template<typename D>
class E {
};
E<PLACE(2, (C<int, short>))> e1;
E<PLACE(2, (C<char, short>))> e2;
E<PLACE(2, (C<short, long>))> e3;
int main() {
return 0;
}
lol... ;^D
== 7 of 8 ==
Date: Sun, Nov 30 2008 4:07 pm
From: Kaba
Chris M. Thomasson wrote:
> Humm... What about something really odd like:
Not necessarily practical, but clever anyway:)
--
http://kaba.hilvi.org
== 8 of 8 ==
Date: Sun, Nov 30 2008 4:25 pm
From: blargg.h4g@gishpuppy.com (blargg)
Chris M. Thomasson wrote:
[...]
> Humm... What about something really odd like:
>
> #define CONCAT_X(T1, T2)T1##T2
> #define CONCAT(T1, T2)CONCAT_X(T1, T2)
>
> #define PLACE_1(X) X
> #define PLACE_2(X1, X2) X1, X2
> #define PLACE_3(X1, X2, X3) X1, X2, X3
> #define PLACE_4(X1, X2, X3, X4) X1, X2, X3, X4
> #define PLACE(D, X)CONCAT(PLACE_, D)X
[...]
> E<PLACE(2, (C<int, short>))> e1;
> E<PLACE(2, (C<char, short>))> e2;
> E<PLACE(2, (C<short, long>))> e3;
[...]
I used to do something sort of like that for macros that needed to accept
types, including template instatiations:
#define PLACE_1( t1 ) { t1 obj; ... }
#define PLACE_2( t1, t2 ) { t1,t2 obj; ... }
#define PLACE_3( t1, t2, t3 ) { t1,t2,t3 obj; ... }
...
Kind of funny how the parts of the type get put back together in such an
odd-looking way in the macros. I like the original poster's type-deducing
version much better, though.
==============================================================================
TOPIC: The Java vs C++ higher salary thread
http://groups.google.com/group/comp.lang.c++/t/be2a8dac2cb503c3?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Nov 30 2008 11:01 am
From: Ian Collins
James Kanze wrote:
> On Nov 29, 8:32 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> Zjargands wrote:
>>> Can we, as a group, please stop posting to this thread? It
>>> has over 100 posts, many of them (most) unrelated to the
>>> original question or simply restatements of what others have
>>> already said.
>
>>> Many of the sub threads have devolved into arguments between
>>> 2 or three people going back and forth with petty arguments
>>> that should be resolved in private e-mail.
>
>>> A good example would be the "what constitutes an engineer"
>>> sub thread. This topic has nothing to do with c++.
>
>>> Thank you for your constructive comments and consideration.
>
>> Just kill the thread if you don't want to read it.
>
> Sorry Ian, but he's right. We're being manipulated. I have
> nothing against it when a thread drifts off-topic for a little
> bit, but this one has become ridiculous.
>
Which is why I've killed it. One keystroke and it's gone!
--
Ian Collins
== 2 of 3 ==
Date: Sun, Nov 30 2008 10:19 am
From: Hendrik Schober
LR wrote:
> James Kanze wrote:
>
>> We're being manipulated.
>
> Please don't speak in riddles.
>
> In what way are you being manipulated?
>
> Who are you being manipulated by?
I wonder why you ask this question. No one else
bothered to ask.
> LR
Schobi
== 3 of 3 ==
Date: Sun, Nov 30 2008 1:54 pm
From: LR
Hendrik Schober wrote:
> LR wrote:
>> James Kanze wrote:
>>
>>> We're being manipulated.
>> Please don't speak in riddles.
>>
>> In what way are you being manipulated?
>>
>> Who are you being manipulated by?
>
> I wonder why you ask this question.
I asked because I don't know what he meant and because I would like to know.
LR
==============================================================================
TOPIC: out of scope pointers in threads
http://groups.google.com/group/comp.lang.c++/t/1413d3875476ff47?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Nov 30 2008 10:18 am
From: Hendrik Schober
Pete Becker wrote:
> On 2008-11-30 06:53:48 -0500, Hendrik Schober <spamtrap@gmx.de> said:
>
>> James Kanze wrote:
>>> [LPVOID]
>>>
>>> Interesting example of why you shouldn't use Hungarian
>>> notation:-).
>> But this isn't HN. ('lpvMyPtr' would be.)
>>
>
> Well, yes, but Microsoft certainly promoted it as Hungarian Notation,
> despite Charles Simonyi's disclaimers.
I thought I knew the difference between Charles' idea (i.e
prefixing with meaning) and its application at MS (prefixing
with type). I hadn't thought that HN -- in the MS sense of
the word -- applied to types.
Schobi
==============================================================================
TOPIC: inorder traversal in binary tree class
http://groups.google.com/group/comp.lang.c++/t/ccf460b6cbb39dab?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Nov 30 2008 1:10 pm
From: Vijay Meena
Hi,
I cant think of an implementation of inorder tree traversal for my
binary tree class given below -
class BTree {
private:
struct Node {
int key;
Node* parent;
Node* left;
Node* right;
Node(int key, Node* parent, Node* left, Node* right);
}* root;
public:
BTree();
void treeInsert(int key);
void treePrint(void); //inorder traversal
//some more API function here
};
inline BTree::BTree() {
root = 0;
}
inline BTree::Node::Node(int key, Node* parent, Node* left, Node*
right) {
this->key = key;
this->parent = parent;
this->right = right;
this->left = left;
}
void BTree::treeInsert(int key) {
Node* node = new Node(key, 0, 0, 0);
Node* parentNode = 0;
Node* placementNode = root;
while(placementNode) {
parentNode = placementNode;
if(node->key < placementNode->key)
placementNode = placementNode->left;
else
placementNode = placementNode->right;
}
node->parent = parentNode;
if(!parentNode)
root = node;
else
if(placementNode == parentNode->left)
parentNode->left = node;
else
parentNode->right = node;
}
void BTree::printTree(void) {
if(!root)
return;
//--- how to implement inorder traversal here ?
}
//main function should be something like -
int main(int argc, char *argv[]) {
BTree btree;
btree.treeInsert(4);
btree.printTree();
}
== 2 of 2 ==
Date: Sun, Nov 30 2008 1:57 pm
From: red floyd
Vijay Meena wrote:
> Hi,
>
> I cant think of an implementation of inorder tree traversal for my
> binary tree class given below -
> [code redacted]
Ask your instructor. Inorder, preorder, and postorder traversal of
is one of the fundamental operations performed on a binary tree.
You didn't even bother to *TRY* to do the assignment of inorder
traversal, why should we do your homework for you.
But here's a hint: What goes before and what goes after
the current node in an inorder traversal?
See FAQ 5.2
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.2
==============================================================================
TOPIC: "free(): invalid next size" when using std::map as a class member
http://groups.google.com/group/comp.lang.c++/t/d919e86752ec61ce?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Nov 30 2008 4:16 pm
From: Chuck Chopp
Included here is a very simple class declaration. When this declaration
is placed in its own header file [test.hpp] and the class member
function definitions are placed in their own file [test.cpp], then the
simple usage case that follows results in a SIGABRT when built with GCC
v4.12 on SUSE Linux Enterprise Server v10.0 SP1.
header file "test.hpp":
#include <map>
class CTest01
{
public:
CTest01();
CTest01(const CTest01& X);
~CTest01();
CTest01& operator=(const CTest01& X);
protected:
private:
std::map<int, int> m_Map;
};
code module "test.cpp":
CTest01::CTest01()
:
m_Map()
{
return;
}
CTest01::CTest01(const CTest01&)
:
m_Map()
{
return;
}
CTest01::~CTest01()
{
return;
}
CTest01& CTest01::operator=(const CTest01&)
{
return (*this);
}
test case that uses CTest01:
#include "test.hpp"
int main(int argc, char* argv[])
{
CTest01 *pTest = NULL;
pTest = new CTest01();
if (NULL != pTest)
{
delete pTest;
}
return 0;
}
Building this as a console application on Windows Vista using Visual
C/C++ v9.0 [Visual Studio 2008] results in a binary that executes w/o
any faults.
Building this on SUSE Linux Enterprise Server v10.0 SP1 using GCC v4.12,
I get a clean compilation but a SIGABRT at run time.
"*** glibc detected *** ./x86_64/test: free(): invalid next size (fast):
0x0000000000588240 ***
followed by a back trace that I'll omit for now.
The problem occurs in the same way for both 32-bit and 64-bit builds,
running on i386 or x86_64 builds of SLES 10.
I'm not entirely certain if I'm dealing with a problem with GCC, a
problem with the glibc implementation on SLES 10 or if I'm missing some
subtle detail related to using std::map as a data member in another
class. So, I'm starting here and if it's necessary to take this to a
more appropriate newsgroup, I'll repost elsewhere as-needed.
Interestingly enough, if I combine the declaration & definition of
CTest01 and it's members directly into the file scope of the code that
makes use of CTest01, then the problem goes away. It's only when the
definition is in an external file that this problem occurs.
Using an std::list class object as a class data member in CTest01 does
not result in this problem occurring. It's only when I use a std::map
class object as a data member in CTest01 that this problem occurs.
Also, it makes no difference what values I use for the template
instantiation of std::map, as the problem happens with <int, int>,
<inst, std::string> and even <std::string, int>, etc....
Any ideas or thoughts as to what might be causing this?
== 2 of 2 ==
Date: Sun, Nov 30 2008 5:56 pm
From: Salt_Peter
On Nov 30, 7:16 pm, Chuck Chopp <ChuckCh...@rtfmcsi.com> wrote:
> Included here is a very simple class declaration. When this declaration
> is placed in its own header file [test.hpp] and the class member
> function definitions are placed in their own file [test.cpp], then the
> simple usage case that follows results in a SIGABRT when built with GCC
> v4.12 on SUSE Linux Enterprise Server v10.0 SP1.
>
> header file "test.hpp":
>
> #include <map>
>
> class CTest01
> {
> public:
>
> CTest01();
>
> CTest01(const CTest01& X);
>
> ~CTest01();
>
> CTest01& operator=(const CTest01& X);
>
> protected:
>
> private:
>
> std::map<int, int> m_Map;
>
> };
>
> code module "test.cpp":
#include "test.hpp"
>
> CTest01::CTest01()
> :
> m_Map()
> {
> return;
remove the return statement
>
> }
>
> CTest01::CTest01(const CTest01&)
> :
> m_Map()
CTest01::CTest01(const CTest01& cpy)
: m_Map(cpy.m_Map)
> {
> return;
remove the return statement.
>
> }
>
> CTest01::~CTest01()
> {
> return;
remove it
>
> }
>
> CTest01& CTest01::operator=(const CTest01&)
> {
> return (*this);
// self assignment check
if( this == &rhv ) return *this;
// assign
m_Map = rhv.m_Map;
return *this;
>
> }
>
> test case that uses CTest01:
>
> #include "test.hpp"
>
> int main(int argc, char* argv[])
> {
> CTest01 *pTest = NULL;
>
> pTest01 = new CTest01();
pTest = new CTest01;
Why allocate on the heap at all?
CTest01 instance;
Only use the heap when absolutely needed.
Even then there are better solutions.
>
> if (NULL != pTest)
> {
> delete pTest;
> }
>
> return 0;
>
> }
>
> Building this as a console application on Windows Vista using Visual
> C/C++ v9.0 [Visual Studio 2008] results in a binary that executes w/o
> any faults.
>
> Building this on SUSE Linux Enterprise Server v10.0 SP1 using GCC v4.12,
> I get a clean compilation but a SIGABRT at run time.
>
> "*** glibc detected *** ./x86_64/test: free(): invalid next size (fast):
> 0x0000000000588240 ***
>
> followed by a back trace that I'll omit for now.
>
> The problem occurs in the same way for both 32-bit and 64-bit builds,
> running on i386 or x86_64 builds of SLES 10.
>
> I'm not entirely certain if I'm dealing with a problem with GCC, a
> problem with the glibc implementation on SLES 10 or if I'm missing some
> subtle detail related to using std::map as a data member in another
> class. So, I'm starting here and if it's necessary to take this to a
> more appropriate newsgroup, I'll repost elsewhere as-needed.
>
> Interestingly enough, if I combine the declaration & definition of
> CTest01 and it's members directly into the file scope of the code that
> makes use of CTest01, then the problem goes away. It's only when the
> definition is in an external file that this problem occurs.
>
> Using an std::list class object as a class data member in CTest01 does
> not result in this problem occurring. It's only when I use a std::map
> class object as a data member in CTest01 that this problem occurs.
> Also, it makes no difference what values I use for the template
> instantiation of std::map, as the problem happens with <int, int>,
> <inst, std::string> and even <std::string, int>, etc....
>
> Any ideas or thoughts as to what might be causing this?
free(): invalid next size (fast):
The above error is usually indicative of a corrupted stack or heap.
The code shown is not the problem as far as i can tell.
==============================================================================
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
