comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* How is it that this code seems to work? - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/9561ec5e330ee93f?hl=en
* More swearing was: Islam is the fastest growing religion ... - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/c16b2698bcfe93c5?hl=en
* public member variable vs. get/set functions - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/92f780d94e30f6f6?hl=en
* Sort comparator function - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/c28f056fa89ab849?hl=en
* Native Aspect-oriented programming in C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/27f28eff7b33632c?hl=en
* Available C++ Libraries FAQ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/22a557c7fec86af9?hl=en
* Want to debug this? - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
* Hope for your project - a little off topic. - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/e4b7c8315db7f411?hl=en
* My two string classes could be "templatized" into one, but for one problem...
- 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
* Does anyone have a workaround for this gcc4.3 issue? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ec22c35f0ecf58cb?hl=en
==============================================================================
TOPIC: How is it that this code seems to work?
http://groups.google.com/group/comp.lang.c++/t/9561ec5e330ee93f?hl=en
==============================================================================
== 1 of 5 ==
Date: Fri, Dec 13 2013 2:25 pm
From: Mr Flibble
On 13/12/2013 21:49, Paavo Helde wrote:
> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
> news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
>
>> On 13/12/2013 17:50, Scott Lurndal wrote:
>>> $ cat /tmp/a.cpp
>>> #include <stdlib.h>
>>> #include <string.h>
>>>
>>> bool bar(void) { return strcasecmp(getenv("FRED"), "joe") == 0; }
>>> bool baz(void) { return strcasecmp(getenv("HOME"), "/home/fred")==0;
>>> }
>>>
>>> extern void wibble(void);
>>>
>>> bool foo(void) { if (bar()) return baz(); wibble(); }
>>> $ g++ -Wall -c -o /tmp/a /tmp/a.cpp
>>> /tmp/a.cpp: In function 'bool foo()':
>>> /tmp/a.cpp:9:54: warning: control reaches end of non-void function
>>> [-Wreturn-type]
>>
>> Well that warning is clearly a bag of shite, what were they thinking?
>> The salient point here though is that it is only a warning and not an
>> error which has to be the case.
>
> This cannot be a compile-time error. The standard clearly states:
>
> "Flowing off the end of a function is equivalent to a return with no
> value; this results in undefined behavior in a value-returning function."
>
> So this is undefined behavior at run-time (not ill-formed code); there is
> no way it could be undefined behavior at run-time if compilers refused to
> compile the code in the first place. Ergo: a conforming compiler may not
> refuse to compile the code, and the compiled code must actually run
> normally as far as the "flowing off the end of a function" UB does not
> actually happen.
I said that already, did you misunderstand me? I said it has to be the
case that it cannot be an error.
/Flibble
== 2 of 5 ==
Date: Fri, Dec 13 2013 3:11 pm
From: Paavo Helde
Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
news:wq-dnY52RO-iFDbPnZ2dnUVZ8g-dnZ2d@giganews.com:
> On 13/12/2013 21:49, Paavo Helde wrote:
>> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
>> news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
>>> Well that warning is clearly a bag of shite, what were they
>>> thinking? The salient point here though is that it is only a warning
>>> and not an error which has to be the case.
>>
>> This cannot be a compile-time error. The standard clearly states:
>
> I said that already, did you misunderstand me? I said it has to be the
> case that it cannot be an error.
On second reading, it might be indeed that your claim can be interpreted
also in the way where "which" applies to "salient point", not to "error".
However, in such interpretation it is unclear why do you think the warning
is "a big of "shite"".
Cheers
Paavo
== 3 of 5 ==
Date: Fri, Dec 13 2013 3:35 pm
From: Mr Flibble
On 13/12/2013 23:11, Paavo Helde wrote:
> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
> news:wq-dnY52RO-iFDbPnZ2dnUVZ8g-dnZ2d@giganews.com:
>
>> On 13/12/2013 21:49, Paavo Helde wrote:
>>> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
>>> news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
>
>>>> Well that warning is clearly a bag of shite, what were they
>>>> thinking? The salient point here though is that it is only a warning
>>>> and not an error which has to be the case.
>>>
>>> This cannot be a compile-time error. The standard clearly states:
>>
>> I said that already, did you misunderstand me? I said it has to be the
>> case that it cannot be an error.
>
> On second reading, it might be indeed that your claim can be interpreted
> also in the way where "which" applies to "salient point", not to "error".
> However, in such interpretation it is unclear why do you think the warning
> is "a big of "shite"".
It is a bag of shite as the warning will likely be a false positive
unless the compiler can determine that control will indeed always flow
off the end.
"Bag of shite" is a catchphrase of Paul Calf:
http://www.youtube.com/watch?v=F-kfeyEzAT8
/Leigh
== 4 of 5 ==
Date: Fri, Dec 13 2013 7:54 pm
From: woodbrian77@gmail.com
On Friday, December 13, 2013 5:35:08 PM UTC-6, Mr Flibble wrote:
Please don't swear here.
== 5 of 5 ==
Date: Sat, Dec 14 2013 8:21 am
From: Mr Flibble
On 14/12/2013 03:54, woodbrian77@gmail.com wrote:
> On Friday, December 13, 2013 5:35:08 PM UTC-6, Mr Flibble wrote:
>
> Please don't swear here.
"Well that's a shit load of fucking bastard cunts" -- Paul Calf
http://www.youtube.com/watch?v=F-kfeyEzAT8
==============================================================================
TOPIC: More swearing was: Islam is the fastest growing religion ...
http://groups.google.com/group/comp.lang.c++/t/c16b2698bcfe93c5?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Dec 13 2013 3:38 pm
From: Mr Flibble
On 13/12/2013 20:50, woodbrian77@gmail.com wrote:
> On Friday, December 13, 2013 2:38:06 PM UTC-6, Mr Flibble wrote:
>>
>
> Please don't swear here.
"Well that's a shit load of fucking bastard cunts" -- Paul Calf
http://www.youtube.com/watch?v=F-kfeyEzAT8
==============================================================================
TOPIC: public member variable vs. get/set functions
http://groups.google.com/group/comp.lang.c++/t/92f780d94e30f6f6?hl=en
==============================================================================
== 1 of 5 ==
Date: Fri, Dec 13 2013 3:47 pm
From: Seungbeom Kim
On 2013-12-11 13:23, �� Tiib wrote:
> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>
>> It surprises me that the real and imaginary components are not
>> public variables in the <complex> class template. Very unclear
>> to me the value of making them private.
>
> It is nowhere said that 'std::complex<float>' must be implemented as
> a class with two float members. The processor may have native support
> for complex arithmetic and 'std::complex' may internally use it or
> it may be is more efficient to implement it as array of two floats
> internally for whatever reasons.
That used to be true. However, with the adoption of LWG Issue #387[1],
I doubt if there could be any other way to implement std::complex<T>
than to have two data members of type T.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
--
Seungbeom Kim
== 2 of 5 ==
Date: Fri, Dec 13 2013 7:51 pm
From: "Alf P. Steinbach"
On 14.12.2013 00:47, Seungbeom Kim wrote:
> On 2013-12-11 13:23, �� Tiib wrote:
>> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>>
>>> It surprises me that the real and imaginary components are not
>>> public variables in the <complex> class template. Very unclear
>>> to me the value of making them private.
>>
>> It is nowhere said that 'std::complex<float>' must be implemented as
>> a class with two float members. The processor may have native support
>> for complex arithmetic and 'std::complex' may internally use it or
>> it may be is more efficient to implement it as array of two floats
>> internally for whatever reasons.
>
> That used to be true. However, with the adoption of LWG Issue #387[1],
> I doubt if there could be any other way to implement std::complex<T>
> than to have two data members of type T.
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
Thanks for that reference & info, and ... I think you mean, "two data
members or an array of two values of".
The `reinterpret_cast` in the LWG issue spec most naturally suggests an
array, which would have to be the first member in order to have an
implementation that only relies on standard C++ functionality
(reinterpret_cast to/from first member of suitably restricted class is
supported in general for C compatibility).
The lack of a specification of size means that low level / C language
access to arrays of complex values is still not supported. That's a big
surprise. I can't believe that that's intentional.
Cheers,
- Alf
== 3 of 5 ==
Date: Fri, Dec 13 2013 8:57 pm
From: Richard Damon
On 12/13/13, 10:51 PM, Alf P. Steinbach wrote:
> On 14.12.2013 00:47, Seungbeom Kim wrote:
>> On 2013-12-11 13:23, �� Tiib wrote:
>>> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>>>
>>>> It surprises me that the real and imaginary components are not
>>>> public variables in the <complex> class template. Very unclear
>>>> to me the value of making them private.
>>>
>>> It is nowhere said that 'std::complex<float>' must be implemented as
>>> a class with two float members. The processor may have native support
>>> for complex arithmetic and 'std::complex' may internally use it or
>>> it may be is more efficient to implement it as array of two floats
>>> internally for whatever reasons.
>>
>> That used to be true. However, with the adoption of LWG Issue #387[1],
>> I doubt if there could be any other way to implement std::complex<T>
>> than to have two data members of type T.
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
>
> Thanks for that reference & info, and ... I think you mean, "two data
> members or an array of two values of".
>
> The `reinterpret_cast` in the LWG issue spec most naturally suggests an
> array, which would have to be the first member in order to have an
> implementation that only relies on standard C++ functionality
> (reinterpret_cast to/from first member of suitably restricted class is
> supported in general for C compatibility).
>
> The lack of a specification of size means that low level / C language
> access to arrays of complex values is still not supported. That's a big
> surprise. I can't believe that that's intentional.
>
>
> Cheers,
>
> - Alf
>
The issue did say:
Moreover, if a is an expression of pointer type cv complex<T>* and the
expression a[i] is well-defined for an integer expression i then:
reinterpret_cast<cv T*>(a)[2*i] designates the real part of a[i]; and
reinterpret_cast<cv T*>(a)[2*i+1] designates the imaginary part of a[i].
which effectively requires sizeof(complex<T>) = 2*sizeof(T)
== 4 of 5 ==
Date: Sat, Dec 14 2013 1:28 am
From: "Alf P. Steinbach"
On 14.12.2013 05:57, Richard Damon wrote:
> On 12/13/13, 10:51 PM, Alf P. Steinbach wrote:
>> On 14.12.2013 00:47, Seungbeom Kim wrote:
>>> On 2013-12-11 13:23, �� Tiib wrote:
>>>> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>>>>
>>>>> It surprises me that the real and imaginary components are not
>>>>> public variables in the <complex> class template. Very unclear
>>>>> to me the value of making them private.
>>>>
>>>> It is nowhere said that 'std::complex<float>' must be implemented as
>>>> a class with two float members. The processor may have native support
>>>> for complex arithmetic and 'std::complex' may internally use it or
>>>> it may be is more efficient to implement it as array of two floats
>>>> internally for whatever reasons.
>>>
>>> That used to be true. However, with the adoption of LWG Issue #387[1],
>>> I doubt if there could be any other way to implement std::complex<T>
>>> than to have two data members of type T.
>>>
>>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
>>
>> Thanks for that reference & info, and ... I think you mean, "two data
>> members or an array of two values of".
>>
>> The `reinterpret_cast` in the LWG issue spec most naturally suggests an
>> array, which would have to be the first member in order to have an
>> implementation that only relies on standard C++ functionality
>> (reinterpret_cast to/from first member of suitably restricted class is
>> supported in general for C compatibility).
>>
>> The lack of a specification of size means that low level / C language
>> access to arrays of complex values is still not supported. That's a big
>> surprise. I can't believe that that's intentional.
>>
>>
>> Cheers,
>>
>> - Alf
>>
>
> The issue did say:
>
> Moreover, if a is an expression of pointer type cv complex<T>* and the
> expression a[i] is well-defined for an integer expression i then:
>
> reinterpret_cast<cv T*>(a)[2*i] designates the real part of a[i]; and
> reinterpret_cast<cv T*>(a)[2*i+1] designates the imaginary part of a[i].
>
> which effectively requires sizeof(complex<T>) = 2*sizeof(T)
>
Thanks, I didn't see the correct parenthesification.
Cheers,
- Alf
== 5 of 5 ==
Date: Sat, Dec 14 2013 11:04 pm
From: Seungbeom Kim
On 2013-12-13 19:51, Alf P. Steinbach wrote:
> On 14.12.2013 00:47, Seungbeom Kim wrote:
>>
>> That used to be true. However, with the adoption of LWG Issue #387[1],
>> I doubt if there could be any other way to implement std::complex<T>
>> than to have two data members of type T.
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
>
> Thanks for that reference & info, and ... I think you mean, "two data
> members or an array of two values of".
That's right. (I'm not sure if elements of a member array can officially
be considered as data members as well. :))
> The `reinterpret_cast` in the LWG issue spec most naturally suggests
> an array, [...]
Not necessarily, though an array is certainly possible. The standard
probably does not guarantee that two data members of the same type
declared consecutively without any intervening access specifiers are
allocated adjacently, but I believe many common implementations do it,
and an implementation can ensure that for std::complex (by any magic
if necessary) since it is part of the implementation anyway.
--
Seungbeom Kim
==============================================================================
TOPIC: Sort comparator function
http://groups.google.com/group/comp.lang.c++/t/c28f056fa89ab849?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Dec 14 2013 3:05 am
From: Fab
Dear All,
I am quite experienced with C++ but here's something I can't recall and
forgive me if I just don't recognize the (possible) simplicity of my
question.
I have the following code
// Custom comparator for pair,
// compares only by the first field
struct compare_first
{
template <typename T>
bool operator() (const T& a, const T& b)
{
return a.first < b.first;
}
};
which is later used in a sort like this
std::sort(cellid_particleid.begin(), cellid_particleid.end(), compare_first());
The sort orders a list of particles according to their cell ID. The
std::pair<unsigned int, unsigned int> contains cellID and particleID,
respectively.
Since the operator() is templated in the comparator, why does my code
still compile? I assume the struct hides the templation, but is this
taken care of in std::sort then?
Thanks + best
Fab
== 2 of 4 ==
Date: Sat, Dec 14 2013 6:56 am
From: "Alf P. Steinbach"
On 14.12.2013 12:05, Fab wrote:
>
> I am quite experienced with C++ but here's something I can't recall and
> forgive me if I just don't recognize the (possible) simplicity of my
> question.
>
> I have the following code
>
> // Custom comparator for pair,
> // compares only by the first field
> struct compare_first
> {
> template <typename T>
> bool operator() (const T& a, const T& b)
> {
> return a.first < b.first;
> }
> };
>
> which is later used in a sort like this
>
> std::sort(cellid_particleid.begin(), cellid_particleid.end(), compare_first());
>
> The sort orders a list of particles according to their cell ID. The
> std::pair<unsigned int, unsigned int> contains cellID and particleID,
> respectively.
>
> Since the operator() is templated in the comparator, why does my code
> still compile? I assume the struct hides the templation, but is this
> taken care of in std::sort then?
From the information given it's impossible to say what makes the code
compile.
See the FAQ item titled "How do I post a question about code that
doesn't work correctly?", currently available at (among others) <url:
http://www.parashift.com/c++-faq/posting-code.html), in particular the
three first bullet points.
It's often a good idea to take a look at the FAQ.
Cheers & hth.,
- Alf
== 3 of 4 ==
Date: Sat, Dec 14 2013 8:35 am
From: Mr Flibble
On 14/12/2013 11:05, Fab wrote:
> Dear All,
>
> I am quite experienced with C++ but here's something I can't recall and
> forgive me if I just don't recognize the (possible) simplicity of my
> question.
>
> I have the following code
>
> // Custom comparator for pair,
> // compares only by the first field
> struct compare_first
> {
> template <typename T>
> bool operator() (const T& a, const T& b)
> {
> return a.first < b.first;
> }
> };
>
> which is later used in a sort like this
>
> std::sort(cellid_particleid.begin(), cellid_particleid.end(), compare_first());
>
> The sort orders a list of particles according to their cell ID. The
> std::pair<unsigned int, unsigned int> contains cellID and particleID,
> respectively.
>
> Since the operator() is templated in the comparator, why does my code
> still compile? I assume the struct hides the templation, but is this
> taken care of in std::sort then?
It compiles because it is correct. The member function template will be
instantiated by std::sort.
The main reason why std::less takes its argument type as a class
template parameter is because it needs to pass it on to what it derives
from (std::binary_function).
As usual safely ignore Alf as he is talking crap again.
/Flibble
== 4 of 4 ==
Date: Sat, Dec 14 2013 11:46 am
From: Mr Flibble
On 14/12/2013 16:35, Mr Flibble wrote:
> On 14/12/2013 11:05, Fab wrote:
>> Dear All,
>>
>> I am quite experienced with C++ but here's something I can't recall and
>> forgive me if I just don't recognize the (possible) simplicity of my
>> question.
>>
>> I have the following code
>>
>> // Custom comparator for pair,
>> // compares only by the first field
>> struct compare_first
>> {
>> template <typename T>
>> bool operator() (const T& a, const T& b)
>> {
>> return a.first < b.first;
>> }
>> };
>>
>> which is later used in a sort like this
>>
>> std::sort(cellid_particleid.begin(), cellid_particleid.end(),
>> compare_first());
>>
>> The sort orders a list of particles according to their cell ID. The
>> std::pair<unsigned int, unsigned int> contains cellID and particleID,
>> respectively.
>>
>> Since the operator() is templated in the comparator, why does my code
>> still compile? I assume the struct hides the templation, but is this
>> taken care of in std::sort then?
>
> It compiles because it is correct. The member function template will be
> instantiated by std::sort.
>
> The main reason why std::less takes its argument type as a class
> template parameter is because it needs to pass it on to what it derives
> from (std::binary_function).
Obviously that is not the only reason; the ability to specify the
argument type explicitly is also sometimes needed to avoid ambiguity.
/Flibble
==============================================================================
TOPIC: Native Aspect-oriented programming in C++
http://groups.google.com/group/comp.lang.c++/t/27f28eff7b33632c?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 14 2013 3:48 am
From: Dombo
On 11-Dec-13 23:34, David Brown wrote:
> Whether the actions of Alf (or anyone else here) is libel or not
> depends, I think, on whether comments really harm anyone's reputation.
> In Norway, we don't go in for trivial lawsuits - I think Alf is entirely
> safe from any legal action, and I doubt if any judge or jury will
> consider that reputations to be seriously harmed.
The only reputation Alf is harming is his own*. Imagine a potential
employer googling his name. No doubt the postings he made here will turn
up. What kind of impression will his postings leave of him?
> For my own part, I am not worried about my reputation, or that anyone
> else will pay much attention to Alf's killfile. And it is his choice to
> decide which posts he reads, and which he ignores. But it certainly is
> not pleasant to see one's name in a list of so-called trolls.
If it is any consolation; if someone has openly fallen out with so many
people (most of which are valued contributors) and feels the need to
publish that repeatedly, it is quite clear that the problem is not with
those people.
> And of course it makes things difficult in threads in which both Alf and
> I (or other "trolls") are involved. (As Chris said earlier, there are
> no doubts about Alf's C++ experience, knowledge and willingness to help
> and advise, so his contributions to threads are valued.)
Alf is also sometimes wrong (just like me, you and everyone else). One
of the benefits of a medium like usenet is that one can be corrected by
others to the benefit of us all. Alf's extremely strong tendency to
resort to personal attacks rather than engaging in a civilized
discussion stands in the way of this, and that is IMHO detrimental to
this group.
*I'm assuming here he is posting using his own name, rather than someone
else using his name to destroy his reputation.
==============================================================================
TOPIC: Available C++ Libraries FAQ
http://groups.google.com/group/comp.lang.c++/t/22a557c7fec86af9?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 14 2013 3:23 pm
From: Nikki Locke
Available C++ Libraries FAQ
URL: http://www.trumphurst.com/cpplibs/
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
Maintainer: Nikki Locke cpplibs@trumphurst.com
==============================================================================
TOPIC: Want to debug this?
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Dec 15 2013 9:31 am
From: woodbrian77@gmail.com
On Saturday, December 7, 2013 4:49:37 PM UTC-6, woodb...@gmail.com wrote:
>
> This is kind of pushing me towards
> moving to a newer OS. I think I've been on this
> version of the OS for over 5 months.
I wound up going to an older version of Linux in Debian.
I rebuilt all three tiers on Debian and tested them on
Debian. I couldn't reproduce the problem when running
on Debian.
Then I copied the Debian-built files to a Fedora machine
where I had originally encountered the problem. The
problem still occurred on Fedora. The Fedora machine
has an alpha or beta version of Fedora on it and my
guess is it has a TCP related bug.
== 2 of 3 ==
Date: Sun, Dec 15 2013 10:20 am
From: Geoff
On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
>On Saturday, December 7, 2013 4:49:37 PM UTC-6, woodb...@gmail.com wrote:
>>
>> This is kind of pushing me towards
>> moving to a newer OS. I think I've been on this
>> version of the OS for over 5 months.
>
>I wound up going to an older version of Linux in Debian.
>
>I rebuilt all three tiers on Debian and tested them on
>Debian. I couldn't reproduce the problem when running
>on Debian.
>
>Then I copied the Debian-built files to a Fedora machine
>where I had originally encountered the problem. The
>problem still occurred on Fedora. The Fedora machine
>has an alpha or beta version of Fedora on it and my
>guess is it has a TCP related bug.
Generally speaking, it's a Bad Idea(tm) to copy binaries from one
edition of Linux (Debian) to another (Fedora). The results are
unpredictable since they may not share a common ABI. It can be done
successfully but doing so while trying to "debug" your stated problem
is just adding another kind of potential error into the scenario.
Instead, you should copy your sources over and build your projects on
each platform. This is why package management exists.
"Alpha or beta" version is meaningless in this context. The current
stable supported release of Fedora is 19. Fedora 20 is available in
alpha and beta releases but why would you introduce yet another set of
problems into the mix?
In your original problem statement you also say you're using clang and
gcc projects. Why? If they share libraries you are running the risk of
ABI incompatibility again. Choose a tool (clang) and bring your
gcc-compiled project up to date and compile all your related projects
with the same tools.
== 3 of 3 ==
Date: Sun, Dec 15 2013 12:57 pm
From: Jorgen Grahn
On Sun, 2013-12-15, Geoff wrote:
> On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
...
>>Then I copied the Debian-built files to a Fedora machine
>>where I had originally encountered the problem. The
>>problem still occurred on Fedora. The Fedora machine
>>has an alpha or beta version of Fedora on it and my
>>guess is it has a TCP related bug.
> Generally speaking, it's a Bad Idea(tm) to copy binaries from one
> edition of Linux (Debian) to another (Fedora). The results are
> unpredictable since they may not share a common ABI.
Are you reasonably sure about that? Any references?
The main burden of keeping things sane lies on the library writers.
When an incompatible version of e.g. the Gnu libc comes out, they must
step the .so file's revision number. (Somehow. The details are
unclear to me.) Then your program will fail to run unless the right
version of libc is available.
It's possible that Fedora takes libfoo version X from upstream and
modifies it so it's not compatible with the Debian build of libfoo
version X ... or modifies the compiler so that it generates such an
incompatibility. But that seems to me rather unlikely since it means
messing with the rather delicate upstream ABI decisions. If you're
Fedora, your can only switch ABIs when the upstream does it, and then
you're stuck with that decision until they release libfoo version X+1.
...
> Instead, you should copy your sources over and build your projects on
> each platform. This is why package management exists.
I agree that is the sane and normal way of doing it. And yes, that
also means I'm not sure you are wrong.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: Hope for your project - a little off topic.
http://groups.google.com/group/comp.lang.c++/t/e4b7c8315db7f411?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 15 2013 10:14 am
From: woodbrian77@gmail.com
On Friday, October 4, 2013 5:08:44 PM UTC-5, woodb...@gmail.com wrote:
> Also I'll pay someone $100 cash and give them a $200
> investment in my company if they help me find someone
> to work with. The company rewards investments to 3
> times their original amount. So you would receive
> anywhere from $0 to $600 on the investment part,
> depending on how things go for the company. I'll pay
> the $100 cash after working with whomever it is for 4
> months.
I'm happy to announce an increase here.
I'll pay $300 cash and give a $300 investment in my
company.
== 2 of 2 ==
Date: Sun, Dec 15 2013 10:39 am
From: Mr Flibble
On 15/12/2013 18:14, woodbrian77@gmail.com wrote:
> On Friday, October 4, 2013 5:08:44 PM UTC-5, woodb...@gmail.com wrote:
>> Also I'll pay someone $100 cash and give them a $200
>> investment in my company if they help me find someone
>> to work with. The company rewards investments to 3
>> times their original amount. So you would receive
>> anywhere from $0 to $600 on the investment part,
>> depending on how things go for the company. I'll pay
>> the $100 cash after working with whomever it is for 4
>> months.
>
> I'm happy to announce an increase here.
>
> I'll pay $300 cash and give a $300 investment in my
> company.
"Well that's a shit load of fucking bastard cunts" -- Paul Calf
http://www.youtube.com/watch?v=F-kfeyEzAT8
==============================================================================
TOPIC: My two string classes could be "templatized" into one, but for one
problem...
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Dec 15 2013 12:54 pm
From: DSF
On Mon, 09 Dec 2013 00:52:07 -0500, DSF <notavalid@address.here>
wrote:
Hello group! A group answer for the group of responders.
Sorry I'm late responding. It's due to a few sick days and the fact
that converting the FStringX classes into a template wasn't as simple
as I thought and I had to go do some more research on templates. The
FStringX classes contained code I'd never tried to put in a template.
Also, I wanted to be sure it actually worked before responding.
First, I'd like to thank Paavo Helde, Robert Wessel and Tobias
M�ller for what turned out to be the best answer. Overload the string
functions.
To my credit, I would like to say I created the code below before
reading Paavo's post on the 10th. I dropped the d and replaced it
with a capital F to visually fit in better with the FString class.
Also, and this will cover Robert Wessel's comment about exporting the
dstr* series to a C program, the dstr* series and other string
manipulators are in a C library I've written. Useable for both
languages. About 80% of the library is written in x86 assembly, so
some kind of wrapper was necessary. (I suppose one could figure out
the name mangling and export C++ names in assembly code, but wrappers
are easier, cost nothing, and are more likely to be portable between
compilers on the same platform.)
This means I couldn't use Paavo's code from the tenth, because it
would break the UNICODE-defined A and W in the string library header.
Come to think of it, I could just #undef dstrlen and any others after
the header is included, then Paavo's method would work. But I think
I'll leave it as it is. It separates the C nomenclature from the C++.
Under the d'oh! category: I don't know if I just forgot it a long
time ago or whatever, but it never occurred to me that non-member
functions could be overloaded, too. It hasn't come up in my
programming. But now...
inline size_t Fstrlen(const char *str){return ::dstrlenA(str);}
inline size_t Fstrlen(const wchar_t *str){return ::dstrlenW(str);}
etc.
... I get the correct version for free! (No overhead!) The compiler
picks the correct FStrlen by parameter type and, with inlining,
Fstrlen(some_string); assembles to a direct call to the proper
dstrlen, A or W.
Problem solved. But to be thorough, answers to other questions.
As to Paavo Helde's question regarding:
// FStr being the template class
typedef FStr<char> FStringA;
typedef FStr<wchar_t> FStringW;
#ifdef UNICODE
#define UCFLAG
#undef UNICODE
Wednesday, December 18, 2013
comp.lang.c++ - 24 new messages in 6 topics - digest
comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Want to debug this? - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
* Does anyone have a workaround for this gcc4.3 issue? - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/ec22c35f0ecf58cb?hl=en
* My two string classes could be "templatized" into one, but for one problem...
- 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
* Repost: Does anyone have a workaround for this gcc4.3 issue? - 8 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/796f654a46c76d68?hl=en
* Hope for your project - a little off topic. - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/e4b7c8315db7f411?hl=en
* How is it that this code seems to work? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/9561ec5e330ee93f?hl=en
==============================================================================
TOPIC: Want to debug this?
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
==============================================================================
== 1 of 6 ==
Date: Sun, Dec 15 2013 12:57 pm
From: Jorgen Grahn
On Sun, 2013-12-15, Geoff wrote:
> On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
...
>>Then I copied the Debian-built files to a Fedora machine
>>where I had originally encountered the problem. The
>>problem still occurred on Fedora. The Fedora machine
>>has an alpha or beta version of Fedora on it and my
>>guess is it has a TCP related bug.
> Generally speaking, it's a Bad Idea(tm) to copy binaries from one
> edition of Linux (Debian) to another (Fedora). The results are
> unpredictable since they may not share a common ABI.
Are you reasonably sure about that? Any references?
The main burden of keeping things sane lies on the library writers.
When an incompatible version of e.g. the Gnu libc comes out, they must
step the .so file's revision number. (Somehow. The details are
unclear to me.) Then your program will fail to run unless the right
version of libc is available.
It's possible that Fedora takes libfoo version X from upstream and
modifies it so it's not compatible with the Debian build of libfoo
version X ... or modifies the compiler so that it generates such an
incompatibility. But that seems to me rather unlikely since it means
messing with the rather delicate upstream ABI decisions. If you're
Fedora, your can only switch ABIs when the upstream does it, and then
you're stuck with that decision until they release libfoo version X+1.
...
> Instead, you should copy your sources over and build your projects on
> each platform. This is why package management exists.
I agree that is the sane and normal way of doing it. And yes, that
also means I'm not sure you are wrong.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 2 of 6 ==
Date: Sun, Dec 15 2013 3:42 pm
From: Chris Vine
On 15 Dec 2013 20:57:00 GMT
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Sun, 2013-12-15, Geoff wrote:
> > On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com
> > wrote:
> ...
> >>Then I copied the Debian-built files to a Fedora machine
> >>where I had originally encountered the problem. The
> >>problem still occurred on Fedora. The Fedora machine
> >>has an alpha or beta version of Fedora on it and my
> >>guess is it has a TCP related bug.
>
> > Generally speaking, it's a Bad Idea(tm) to copy binaries from one
> > edition of Linux (Debian) to another (Fedora). The results are
> > unpredictable since they may not share a common ABI.
>
> Are you reasonably sure about that? Any references?
>
> The main burden of keeping things sane lies on the library writers.
> When an incompatible version of e.g. the Gnu libc comes out, they must
> step the .so file's revision number. (Somehow. The details are
> unclear to me.) Then your program will fail to run unless the right
> version of libc is available.
libtool does all that for you, assuming the library concerned uses
libtool (as most do), in combination with the -version-info link flag.
> It's possible that Fedora takes libfoo version X from upstream and
> modifies it so it's not compatible with the Debian build of libfoo
> version X ... or modifies the compiler so that it generates such an
> incompatibility. But that seems to me rather unlikely since it means
> messing with the rather delicate upstream ABI decisions. If you're
> Fedora, your can only switch ABIs when the upstream does it, and then
> you're stuck with that decision until they release libfoo version X+1.
> > Instead, you should copy your sources over and build your projects
> > on each platform. This is why package management exists.
>
> I agree that is the sane and normal way of doing it. And yes, that
> also means I'm not sure you are wrong.
You are asking for trouble if you don't rebuild for different linux
distributions.
Not all libraries use libtool versioning and not all libraries are
adequately strict about keeping binary compatibility between versions
with the same libtool version number even where they do. With C++
libraries it can be extremely difficult to know when you are breaking
binary compatibility for a particular compiler, and breaking of the ODR
rule for inline C++ functions is commonplace - in most cases this
doesn't matter, but depending on the linker it might. (Every time you
modify an inline function in a library header you risk breaking the ODR
rule unless all code which includes the header is rebuilt: but in most
cases this breach is technical only and distributions will not rebuild
for this.)
Furthermore, even those projects which correctly maintain binary
compatibility between major releases only guarantee compatibility going
from lower to higher version numbers, and not the reverse (there is no
inhibition on adding adding new symbols with later versions - the
inhibition is on removing symbols). So if you try to use a binary
compiled with one distribution on another, and the other uses an
earlier version of a particular library, you might be stuffed for that
reason.
Not all distributions even use the same libc (fedora uses glibc, ubuntu
and debian use eglibc).
Distributions will rebuild when they need to, not when other
distributions need to. In addition, some distributions use patched
versions of libraries which might conceivably differ in binary
compatibilty from the unpatched upstream version (which is fine for the
distribution concerned).
You will minimise the risk of trouble of course if you do static
builds. However, not all libraries will build statically (the GTK+
tool chain found on ubuntu and fedora will not).
Chris
== 3 of 6 ==
Date: Sun, Dec 15 2013 4:17 pm
From: woodbrian77@gmail.com
On Sunday, December 15, 2013 12:20:58 PM UTC-6, Geoff wrote:
>
> Generally speaking, it's a Bad Idea(tm) to copy binaries from one
> edition of Linux (Debian) to another (Fedora). The results are
> unpredictable since they may not share a common ABI. It can be done
> successfully but doing so while trying to "debug" your stated problem
> is just adding another kind of potential error into the scenario.
>
>
> Instead, you should copy your sources over and build your projects on
> each platform. This is why package management exists.
I have one production machine and a couple of development
machines. As a security measure, I don't copy sources
for the back tier to the production machine. Up until
a few days ago both the production and development
machines had Fedora 20 installs on them. Anyway, I tend
to keep the development and production machines within
a release of each other and haven't encountered problems
from doing things that way.
I only introduced the Debian install in order to
investigate the problem.
>
> In your original problem statement you also say you're using clang and
> gcc projects. Why? If they share libraries you are running the risk of
> ABI incompatibility again. Choose a tool (clang) and bring your
> gcc-compiled project up to date and compile all your related projects
> with the same tools.
I haven't so far been able to make a decision between clang
and gcc. I've continued to use both in part to figure out
which one I thought was better. On Debian, the compilers
are clang 3.0-6.2 and gcc 4.7.2-5. My software only builds
with gcc on Debian, but on Fedora it builds with both
compilers.
== 4 of 6 ==
Date: Sun, Dec 15 2013 4:28 pm
From: Melzzzzz
On Sun, 15 Dec 2013 16:17:02 -0800 (PST)
woodbrian77@gmail.com wrote:
>
> I haven't so far been able to make a decision between clang
> and gcc.
Stick with gcc as it more mature (has less bugs).
I have bad experience with clang and FreeBSD 10...
--
There are more things in heaven and earth,
Horatio, than are dreamt of in your philosophy.
-- Wm. Shakespeare, "Hamlet"
== 5 of 6 ==
Date: Sun, Dec 15 2013 4:29 pm
From: woodbrian77@gmail.com
On Sunday, December 15, 2013 6:17:02 PM UTC-6, woodb...@gmail.com wrote:
>
> a few days ago both the production and development
> machines had Fedora 20 installs on them.
Oops, one of my machines has Fedora 19 on it.
== 6 of 6 ==
Date: Sun, Dec 15 2013 6:27 pm
From: Geoff
On 15 Dec 2013 20:57:00 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
wrote:
>On Sun, 2013-12-15, Geoff wrote:
>> On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
>...
>>>Then I copied the Debian-built files to a Fedora machine
>>>where I had originally encountered the problem. The
>>>problem still occurred on Fedora. The Fedora machine
>>>has an alpha or beta version of Fedora on it and my
>>>guess is it has a TCP related bug.
>
>> Generally speaking, it's a Bad Idea(tm) to copy binaries from one
>> edition of Linux (Debian) to another (Fedora). The results are
>> unpredictable since they may not share a common ABI.
>
>Are you reasonably sure about that? Any references?
>
>The main burden of keeping things sane lies on the library writers.
>When an incompatible version of e.g. the Gnu libc comes out, they must
>step the .so file's revision number. (Somehow. The details are
>unclear to me.) Then your program will fail to run unless the right
>version of libc is available.
>
>It's possible that Fedora takes libfoo version X from upstream and
>modifies it so it's not compatible with the Debian build of libfoo
>version X ... or modifies the compiler so that it generates such an
>incompatibility. But that seems to me rather unlikely since it means
>messing with the rather delicate upstream ABI decisions. If you're
>Fedora, your can only switch ABIs when the upstream does it, and then
>you're stuck with that decision until they release libfoo version X+1.
>
>...
>> Instead, you should copy your sources over and build your projects on
>> each platform. This is why package management exists.
>
>I agree that is the sane and normal way of doing it. And yes, that
>also means I'm not sure you are wrong.
>
That's OK. I'm not sure I'm right. :) I only know that if I'm
debugging a system, I don't go around transplanting it onto other
systems to see what else will break besides the problem I'm working on
already. That way lies madness...
==============================================================================
TOPIC: Does anyone have a workaround for this gcc4.3 issue?
http://groups.google.com/group/comp.lang.c++/t/ec22c35f0ecf58cb?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Dec 15 2013 12:57 pm
From: huili80@gmail.com
Code is as follows. It's legal c++ code, however doesn't compile with g++4.3.
Would really appreciate if anyone has a workaround!! Thanks!
-----------------------------------------------
template < typename T > T& obj();
template < typename T, typename=typeof(obj<T>().memfun()) >
struct test {};
template < typename T > test<T> f(int){}
template <typename> char f(...){}
struct X
{
void memfun(int){};
};
int main()
{
f<X>(0);
}
== 2 of 4 ==
Date: Sun, Dec 15 2013 1:56 pm
From: "Alf P. Steinbach"
On 15.12.2013 21:57, huili80@gmail.com wrote:
> Code is as follows. It's legal c++ code, however doesn't compile with g++4.3.
> Would really appreciate if anyone has a workaround!! Thanks!
>
> -----------------------------------------------
>
> template < typename T > T& obj();
>
> template < typename T, typename=typeof(obj<T>().memfun()) >
> struct test {};
>
> template < typename T > test<T> f(int){}
>
> template <typename> char f(...){}
>
> struct X
> {
> void memfun(int){};
> };
>
> int main()
> {
> f<X>(0);
> }
>
From the information given it's impossible to say what error g++ 4.3
produces.
See the FAQ item titled "How do I post a question about code that
doesn't work correctly?", currently available at (among others) <url:
http://www.parashift.com/c++-faq/posting-code.html), in particular the
three first bullet points.
It's often a good idea to take a look at the FAQ.
- - -
That said, the code isn't quite valid standard C++:
* In standard C++ there is no `typeof`. It's a g++ language extension.
C++11 does have a similar `decltype`.
* A non-void function must not return by the execution passing out of
the end of the function body, this is Undefined Behavior. Probably,
judging from the code, the functions are meant to be used in compile
time TMP machinery, and then just be unimplemented. But still.
Also, Visual C++ 12.0 refuses to accept the
"typename=typeof(obj<T>().memfun()", but as I recall it has a bug in
this area so it doesn't indicate any other problem than portability:
better rewrite if you want this to compile also with Visual C++.
- - -
Btw., what was the problem?
Can you re-post, according to the FAQ guidelines?
Cheers & hth.,
- Alf
== 3 of 4 ==
Date: Sun, Dec 15 2013 2:18 pm
From: huili80@gmail.com
Thanks Alf for looking at my post. Here is more information.
The problem is that this code compiles with gcc4.8 and above, as i've tested. however, unfortunately i do not currently have other compiler other than gcc4.3 (at work that is), and i hope to find a workaround for gcc4.3.
The non-compile appears to be a gcc4.3 issue (bug maybe?), where a substitution failure, i.e., the instantiation of test<X> when calling f<X>(0), is mistakenly being treated as an error.
As for the code itself, since i'm using gcc4.3 which doesn't have c++11, therefore no decltype, so i had to use the gcc extension typeof, which is really the only thing non-standard about it.
Thanks.
== 4 of 4 ==
Date: Sun, Dec 15 2013 2:26 pm
From: huili80@gmail.com
reposted.
==============================================================================
TOPIC: My two string classes could be "templatized" into one, but for one
problem...
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Dec 15 2013 1:03 pm
From: DSF
On Mon, 09 Dec 2013 21:49:55 -0500, DSF <notavalid@address.here>
wrote:
>On Mon, 09 Dec 2013 01:14:04 -0600, Paavo Helde
><myfirstname@osa.pri.ee> wrote:
>
>>DSF <notavalid@address.here> wrote in
>>news:t2kaa99judr3b7o96vj807qvc29g9il0mo@4ax.com:
>>
>>Actually I have another unrelated question: what use has the ANSI (in the
>>sense Windows is abusing this term) version nowadays anyway? I could
>>understand an ASCII version of strings (for speed) or UTF-8 (for
>>portability), but ANSI? What possible benefit does it have to support a
>>random and unknown small subset of non-ASCII characters on the user
>>computer? These ANSI interfaces in Windows are just an almost 20-year
>>legacy, all the Windows internals work in Unicode anyway, so why don't
>>you just have a couple of conversion functions for your class from-to
>>ANSI to interact with any old legacy client code expecting ANSI strings?
My answer (below) to this was WRONG, WRONG, WRONG! The "A" versions
use ANSI code pages. One exception is that they have included the use
of CP_UTF7 and CP_UTF8 as pseudo code pages, allowing 8-bit Unicode
use. There's also OEM charsets, but things are complicated enough
already!
> You answered your question within itself: "(in the sense Windows is
>abusing this term)". Their documentation defines A as ANSI and W as
>wide or UTF. As far as I'm concerned, A means 8-bit characters and W
>means 16-bit Unicode characters, as that's what M$ has decided are
>Windows' two character types. They could have started saying "A is
>for ASCII," but from their point of view, why bother to change every
>reference in the tons of documentation?
>
"'Later' is the beginning of what's not to be."
D.S. Fiscus
== 2 of 3 ==
Date: Sun, Dec 15 2013 1:41 pm
From: "Alf P. Steinbach"
On 15.12.2013 21:54, DSF wrote:
>
> inline size_t Fstrlen(const char *str){return ::dstrlenA(str);}
> inline size_t Fstrlen(const wchar_t *str){return ::dstrlenW(str);}
> etc.
>
> ... I get the correct version for free! (No overhead!) The compiler
> picks the correct FStrlen by parameter type and, with inlining,
> Fstrlen(some_string); assembles to a direct call to the proper
> dstrlen, A or W.
>
> Problem solved.
Consider the definition
#include <string.h>
inline size_t FStrlen( char const* str ) { return strlen( str ); }
inline size_t FStrlen( wchar_t const* str ) { return wcslen( str ); }
Here's roughly the same expressed using std::char_traits:
#include <string>
template< class Char >
size_t FStrlen( Char const* str ) { return
std::char_traits<Char>::length( str ); }
And if FStrlen only serves as an implementation helper for a templated
string class, then even this wrapping isn't necessary -- because with
known Char type one can just call char_traits<Char>::length directly.
Cheers,
- Alf
== 3 of 3 ==
Date: Sun, Dec 15 2013 1:55 pm
From: Paavo Helde
DSF <notavalid@address.here> wrote in
news:83vra99i3qbc6lqjvkmu3v8du1ggk7kf8a@4ax.com:
> One question. To save a lot of rewriting, I've typedef'd the
> strings as so:
>
> typedef FString<char> FStringA;
> typedef FString<wchar_t> FStringW;
>
> I don't see any problem there, but it's followed-up with this to
> handle the generic FString UNICODE switching:
>
> #ifdef UNICODE
> #define FString FStringW
> #else
> #define FString FStringA
>
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Want to debug this? - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
* Does anyone have a workaround for this gcc4.3 issue? - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/ec22c35f0ecf58cb?hl=en
* My two string classes could be "templatized" into one, but for one problem...
- 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
* Repost: Does anyone have a workaround for this gcc4.3 issue? - 8 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/796f654a46c76d68?hl=en
* Hope for your project - a little off topic. - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/e4b7c8315db7f411?hl=en
* How is it that this code seems to work? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/9561ec5e330ee93f?hl=en
==============================================================================
TOPIC: Want to debug this?
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
==============================================================================
== 1 of 6 ==
Date: Sun, Dec 15 2013 12:57 pm
From: Jorgen Grahn
On Sun, 2013-12-15, Geoff wrote:
> On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
...
>>Then I copied the Debian-built files to a Fedora machine
>>where I had originally encountered the problem. The
>>problem still occurred on Fedora. The Fedora machine
>>has an alpha or beta version of Fedora on it and my
>>guess is it has a TCP related bug.
> Generally speaking, it's a Bad Idea(tm) to copy binaries from one
> edition of Linux (Debian) to another (Fedora). The results are
> unpredictable since they may not share a common ABI.
Are you reasonably sure about that? Any references?
The main burden of keeping things sane lies on the library writers.
When an incompatible version of e.g. the Gnu libc comes out, they must
step the .so file's revision number. (Somehow. The details are
unclear to me.) Then your program will fail to run unless the right
version of libc is available.
It's possible that Fedora takes libfoo version X from upstream and
modifies it so it's not compatible with the Debian build of libfoo
version X ... or modifies the compiler so that it generates such an
incompatibility. But that seems to me rather unlikely since it means
messing with the rather delicate upstream ABI decisions. If you're
Fedora, your can only switch ABIs when the upstream does it, and then
you're stuck with that decision until they release libfoo version X+1.
...
> Instead, you should copy your sources over and build your projects on
> each platform. This is why package management exists.
I agree that is the sane and normal way of doing it. And yes, that
also means I'm not sure you are wrong.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 2 of 6 ==
Date: Sun, Dec 15 2013 3:42 pm
From: Chris Vine
On 15 Dec 2013 20:57:00 GMT
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Sun, 2013-12-15, Geoff wrote:
> > On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com
> > wrote:
> ...
> >>Then I copied the Debian-built files to a Fedora machine
> >>where I had originally encountered the problem. The
> >>problem still occurred on Fedora. The Fedora machine
> >>has an alpha or beta version of Fedora on it and my
> >>guess is it has a TCP related bug.
>
> > Generally speaking, it's a Bad Idea(tm) to copy binaries from one
> > edition of Linux (Debian) to another (Fedora). The results are
> > unpredictable since they may not share a common ABI.
>
> Are you reasonably sure about that? Any references?
>
> The main burden of keeping things sane lies on the library writers.
> When an incompatible version of e.g. the Gnu libc comes out, they must
> step the .so file's revision number. (Somehow. The details are
> unclear to me.) Then your program will fail to run unless the right
> version of libc is available.
libtool does all that for you, assuming the library concerned uses
libtool (as most do), in combination with the -version-info link flag.
> It's possible that Fedora takes libfoo version X from upstream and
> modifies it so it's not compatible with the Debian build of libfoo
> version X ... or modifies the compiler so that it generates such an
> incompatibility. But that seems to me rather unlikely since it means
> messing with the rather delicate upstream ABI decisions. If you're
> Fedora, your can only switch ABIs when the upstream does it, and then
> you're stuck with that decision until they release libfoo version X+1.
> > Instead, you should copy your sources over and build your projects
> > on each platform. This is why package management exists.
>
> I agree that is the sane and normal way of doing it. And yes, that
> also means I'm not sure you are wrong.
You are asking for trouble if you don't rebuild for different linux
distributions.
Not all libraries use libtool versioning and not all libraries are
adequately strict about keeping binary compatibility between versions
with the same libtool version number even where they do. With C++
libraries it can be extremely difficult to know when you are breaking
binary compatibility for a particular compiler, and breaking of the ODR
rule for inline C++ functions is commonplace - in most cases this
doesn't matter, but depending on the linker it might. (Every time you
modify an inline function in a library header you risk breaking the ODR
rule unless all code which includes the header is rebuilt: but in most
cases this breach is technical only and distributions will not rebuild
for this.)
Furthermore, even those projects which correctly maintain binary
compatibility between major releases only guarantee compatibility going
from lower to higher version numbers, and not the reverse (there is no
inhibition on adding adding new symbols with later versions - the
inhibition is on removing symbols). So if you try to use a binary
compiled with one distribution on another, and the other uses an
earlier version of a particular library, you might be stuffed for that
reason.
Not all distributions even use the same libc (fedora uses glibc, ubuntu
and debian use eglibc).
Distributions will rebuild when they need to, not when other
distributions need to. In addition, some distributions use patched
versions of libraries which might conceivably differ in binary
compatibilty from the unpatched upstream version (which is fine for the
distribution concerned).
You will minimise the risk of trouble of course if you do static
builds. However, not all libraries will build statically (the GTK+
tool chain found on ubuntu and fedora will not).
Chris
== 3 of 6 ==
Date: Sun, Dec 15 2013 4:17 pm
From: woodbrian77@gmail.com
On Sunday, December 15, 2013 12:20:58 PM UTC-6, Geoff wrote:
>
> Generally speaking, it's a Bad Idea(tm) to copy binaries from one
> edition of Linux (Debian) to another (Fedora). The results are
> unpredictable since they may not share a common ABI. It can be done
> successfully but doing so while trying to "debug" your stated problem
> is just adding another kind of potential error into the scenario.
>
>
> Instead, you should copy your sources over and build your projects on
> each platform. This is why package management exists.
I have one production machine and a couple of development
machines. As a security measure, I don't copy sources
for the back tier to the production machine. Up until
a few days ago both the production and development
machines had Fedora 20 installs on them. Anyway, I tend
to keep the development and production machines within
a release of each other and haven't encountered problems
from doing things that way.
I only introduced the Debian install in order to
investigate the problem.
>
> In your original problem statement you also say you're using clang and
> gcc projects. Why? If they share libraries you are running the risk of
> ABI incompatibility again. Choose a tool (clang) and bring your
> gcc-compiled project up to date and compile all your related projects
> with the same tools.
I haven't so far been able to make a decision between clang
and gcc. I've continued to use both in part to figure out
which one I thought was better. On Debian, the compilers
are clang 3.0-6.2 and gcc 4.7.2-5. My software only builds
with gcc on Debian, but on Fedora it builds with both
compilers.
== 4 of 6 ==
Date: Sun, Dec 15 2013 4:28 pm
From: Melzzzzz
On Sun, 15 Dec 2013 16:17:02 -0800 (PST)
woodbrian77@gmail.com wrote:
>
> I haven't so far been able to make a decision between clang
> and gcc.
Stick with gcc as it more mature (has less bugs).
I have bad experience with clang and FreeBSD 10...
--
There are more things in heaven and earth,
Horatio, than are dreamt of in your philosophy.
-- Wm. Shakespeare, "Hamlet"
== 5 of 6 ==
Date: Sun, Dec 15 2013 4:29 pm
From: woodbrian77@gmail.com
On Sunday, December 15, 2013 6:17:02 PM UTC-6, woodb...@gmail.com wrote:
>
> a few days ago both the production and development
> machines had Fedora 20 installs on them.
Oops, one of my machines has Fedora 19 on it.
== 6 of 6 ==
Date: Sun, Dec 15 2013 6:27 pm
From: Geoff
On 15 Dec 2013 20:57:00 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
wrote:
>On Sun, 2013-12-15, Geoff wrote:
>> On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
>...
>>>Then I copied the Debian-built files to a Fedora machine
>>>where I had originally encountered the problem. The
>>>problem still occurred on Fedora. The Fedora machine
>>>has an alpha or beta version of Fedora on it and my
>>>guess is it has a TCP related bug.
>
>> Generally speaking, it's a Bad Idea(tm) to copy binaries from one
>> edition of Linux (Debian) to another (Fedora). The results are
>> unpredictable since they may not share a common ABI.
>
>Are you reasonably sure about that? Any references?
>
>The main burden of keeping things sane lies on the library writers.
>When an incompatible version of e.g. the Gnu libc comes out, they must
>step the .so file's revision number. (Somehow. The details are
>unclear to me.) Then your program will fail to run unless the right
>version of libc is available.
>
>It's possible that Fedora takes libfoo version X from upstream and
>modifies it so it's not compatible with the Debian build of libfoo
>version X ... or modifies the compiler so that it generates such an
>incompatibility. But that seems to me rather unlikely since it means
>messing with the rather delicate upstream ABI decisions. If you're
>Fedora, your can only switch ABIs when the upstream does it, and then
>you're stuck with that decision until they release libfoo version X+1.
>
>...
>> Instead, you should copy your sources over and build your projects on
>> each platform. This is why package management exists.
>
>I agree that is the sane and normal way of doing it. And yes, that
>also means I'm not sure you are wrong.
>
That's OK. I'm not sure I'm right. :) I only know that if I'm
debugging a system, I don't go around transplanting it onto other
systems to see what else will break besides the problem I'm working on
already. That way lies madness...
==============================================================================
TOPIC: Does anyone have a workaround for this gcc4.3 issue?
http://groups.google.com/group/comp.lang.c++/t/ec22c35f0ecf58cb?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Dec 15 2013 12:57 pm
From: huili80@gmail.com
Code is as follows. It's legal c++ code, however doesn't compile with g++4.3.
Would really appreciate if anyone has a workaround!! Thanks!
-----------------------------------------------
template < typename T > T& obj();
template < typename T, typename=typeof(obj<T>().memfun()) >
struct test {};
template < typename T > test<T> f(int){}
template <typename> char f(...){}
struct X
{
void memfun(int){};
};
int main()
{
f<X>(0);
}
== 2 of 4 ==
Date: Sun, Dec 15 2013 1:56 pm
From: "Alf P. Steinbach"
On 15.12.2013 21:57, huili80@gmail.com wrote:
> Code is as follows. It's legal c++ code, however doesn't compile with g++4.3.
> Would really appreciate if anyone has a workaround!! Thanks!
>
> -----------------------------------------------
>
> template < typename T > T& obj();
>
> template < typename T, typename=typeof(obj<T>().memfun()) >
> struct test {};
>
> template < typename T > test<T> f(int){}
>
> template <typename> char f(...){}
>
> struct X
> {
> void memfun(int){};
> };
>
> int main()
> {
> f<X>(0);
> }
>
From the information given it's impossible to say what error g++ 4.3
produces.
See the FAQ item titled "How do I post a question about code that
doesn't work correctly?", currently available at (among others) <url:
http://www.parashift.com/c++-faq/posting-code.html), in particular the
three first bullet points.
It's often a good idea to take a look at the FAQ.
- - -
That said, the code isn't quite valid standard C++:
* In standard C++ there is no `typeof`. It's a g++ language extension.
C++11 does have a similar `decltype`.
* A non-void function must not return by the execution passing out of
the end of the function body, this is Undefined Behavior. Probably,
judging from the code, the functions are meant to be used in compile
time TMP machinery, and then just be unimplemented. But still.
Also, Visual C++ 12.0 refuses to accept the
"typename=typeof(obj<T>().memfun()", but as I recall it has a bug in
this area so it doesn't indicate any other problem than portability:
better rewrite if you want this to compile also with Visual C++.
- - -
Btw., what was the problem?
Can you re-post, according to the FAQ guidelines?
Cheers & hth.,
- Alf
== 3 of 4 ==
Date: Sun, Dec 15 2013 2:18 pm
From: huili80@gmail.com
Thanks Alf for looking at my post. Here is more information.
The problem is that this code compiles with gcc4.8 and above, as i've tested. however, unfortunately i do not currently have other compiler other than gcc4.3 (at work that is), and i hope to find a workaround for gcc4.3.
The non-compile appears to be a gcc4.3 issue (bug maybe?), where a substitution failure, i.e., the instantiation of test<X> when calling f<X>(0), is mistakenly being treated as an error.
As for the code itself, since i'm using gcc4.3 which doesn't have c++11, therefore no decltype, so i had to use the gcc extension typeof, which is really the only thing non-standard about it.
Thanks.
== 4 of 4 ==
Date: Sun, Dec 15 2013 2:26 pm
From: huili80@gmail.com
reposted.
==============================================================================
TOPIC: My two string classes could be "templatized" into one, but for one
problem...
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Dec 15 2013 1:03 pm
From: DSF
On Mon, 09 Dec 2013 21:49:55 -0500, DSF <notavalid@address.here>
wrote:
>On Mon, 09 Dec 2013 01:14:04 -0600, Paavo Helde
><myfirstname@osa.pri.ee> wrote:
>
>>DSF <notavalid@address.here> wrote in
>>news:t2kaa99judr3b7o96vj807qvc29g9il0mo@4ax.com:
>>
>>Actually I have another unrelated question: what use has the ANSI (in the
>>sense Windows is abusing this term) version nowadays anyway? I could
>>understand an ASCII version of strings (for speed) or UTF-8 (for
>>portability), but ANSI? What possible benefit does it have to support a
>>random and unknown small subset of non-ASCII characters on the user
>>computer? These ANSI interfaces in Windows are just an almost 20-year
>>legacy, all the Windows internals work in Unicode anyway, so why don't
>>you just have a couple of conversion functions for your class from-to
>>ANSI to interact with any old legacy client code expecting ANSI strings?
My answer (below) to this was WRONG, WRONG, WRONG! The "A" versions
use ANSI code pages. One exception is that they have included the use
of CP_UTF7 and CP_UTF8 as pseudo code pages, allowing 8-bit Unicode
use. There's also OEM charsets, but things are complicated enough
already!
> You answered your question within itself: "(in the sense Windows is
>abusing this term)". Their documentation defines A as ANSI and W as
>wide or UTF. As far as I'm concerned, A means 8-bit characters and W
>means 16-bit Unicode characters, as that's what M$ has decided are
>Windows' two character types. They could have started saying "A is
>for ASCII," but from their point of view, why bother to change every
>reference in the tons of documentation?
>
"'Later' is the beginning of what's not to be."
D.S. Fiscus
== 2 of 3 ==
Date: Sun, Dec 15 2013 1:41 pm
From: "Alf P. Steinbach"
On 15.12.2013 21:54, DSF wrote:
>
> inline size_t Fstrlen(const char *str){return ::dstrlenA(str);}
> inline size_t Fstrlen(const wchar_t *str){return ::dstrlenW(str);}
> etc.
>
> ... I get the correct version for free! (No overhead!) The compiler
> picks the correct FStrlen by parameter type and, with inlining,
> Fstrlen(some_string); assembles to a direct call to the proper
> dstrlen, A or W.
>
> Problem solved.
Consider the definition
#include <string.h>
inline size_t FStrlen( char const* str ) { return strlen( str ); }
inline size_t FStrlen( wchar_t const* str ) { return wcslen( str ); }
Here's roughly the same expressed using std::char_traits:
#include <string>
template< class Char >
size_t FStrlen( Char const* str ) { return
std::char_traits<Char>::length( str ); }
And if FStrlen only serves as an implementation helper for a templated
string class, then even this wrapping isn't necessary -- because with
known Char type one can just call char_traits<Char>::length directly.
Cheers,
- Alf
== 3 of 3 ==
Date: Sun, Dec 15 2013 1:55 pm
From: Paavo Helde
DSF <notavalid@address.here> wrote in
news:83vra99i3qbc6lqjvkmu3v8du1ggk7kf8a@4ax.com:
> One question. To save a lot of rewriting, I've typedef'd the
> strings as so:
>
> typedef FString<char> FStringA;
> typedef FString<wchar_t> FStringW;
>
> I don't see any problem there, but it's followed-up with this to
> handle the generic FString UNICODE switching:
>
> #ifdef UNICODE
> #define FString FStringW
> #else
> #define FString FStringA
>
comp.lang.c++ - 26 new messages in 9 topics - digest
comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* How is it that this code seems to work? - 6 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/9561ec5e330ee93f?hl=en
* Islam is the fastest growing religion in the world especially since sept. 11.
- 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/c16b2698bcfe93c5?hl=en
* public member variable vs. get/set functions - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/92f780d94e30f6f6?hl=en
* Sort comparator function - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/c28f056fa89ab849?hl=en
* Native Aspect-oriented programming in C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/27f28eff7b33632c?hl=en
* Available C++ Libraries FAQ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/22a557c7fec86af9?hl=en
* Want to debug this? - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
* Hope for your project - a little off topic. - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/e4b7c8315db7f411?hl=en
* My two string classes could be "templatized" into one, but for one problem...
- 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
==============================================================================
TOPIC: How is it that this code seems to work?
http://groups.google.com/group/comp.lang.c++/t/9561ec5e330ee93f?hl=en
==============================================================================
== 1 of 6 ==
Date: Fri, Dec 13 2013 1:49 pm
From: Paavo Helde
Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
> On 13/12/2013 17:50, Scott Lurndal wrote:
>> $ cat /tmp/a.cpp
>> #include <stdlib.h>
>> #include <string.h>
>>
>> bool bar(void) { return strcasecmp(getenv("FRED"), "joe") == 0; }
>> bool baz(void) { return strcasecmp(getenv("HOME"), "/home/fred")==0;
>> }
>>
>> extern void wibble(void);
>>
>> bool foo(void) { if (bar()) return baz(); wibble(); }
>> $ g++ -Wall -c -o /tmp/a /tmp/a.cpp
>> /tmp/a.cpp: In function 'bool foo()':
>> /tmp/a.cpp:9:54: warning: control reaches end of non-void function
>> [-Wreturn-type]
>
> Well that warning is clearly a bag of shite, what were they thinking?
> The salient point here though is that it is only a warning and not an
> error which has to be the case.
This cannot be a compile-time error. The standard clearly states:
"Flowing off the end of a function is equivalent to a return with no
value; this results in undefined behavior in a value-returning function."
So this is undefined behavior at run-time (not ill-formed code); there is
no way it could be undefined behavior at run-time if compilers refused to
compile the code in the first place. Ergo: a conforming compiler may not
refuse to compile the code, and the compiled code must actually run
normally as far as the "flowing off the end of a function" UB does not
actually happen.
Cheers
Paavo
== 2 of 6 ==
Date: Fri, Dec 13 2013 2:25 pm
From: Mr Flibble
On 13/12/2013 21:49, Paavo Helde wrote:
> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
> news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
>
>> On 13/12/2013 17:50, Scott Lurndal wrote:
>>> $ cat /tmp/a.cpp
>>> #include <stdlib.h>
>>> #include <string.h>
>>>
>>> bool bar(void) { return strcasecmp(getenv("FRED"), "joe") == 0; }
>>> bool baz(void) { return strcasecmp(getenv("HOME"), "/home/fred")==0;
>>> }
>>>
>>> extern void wibble(void);
>>>
>>> bool foo(void) { if (bar()) return baz(); wibble(); }
>>> $ g++ -Wall -c -o /tmp/a /tmp/a.cpp
>>> /tmp/a.cpp: In function 'bool foo()':
>>> /tmp/a.cpp:9:54: warning: control reaches end of non-void function
>>> [-Wreturn-type]
>>
>> Well that warning is clearly a bag of shite, what were they thinking?
>> The salient point here though is that it is only a warning and not an
>> error which has to be the case.
>
> This cannot be a compile-time error. The standard clearly states:
>
> "Flowing off the end of a function is equivalent to a return with no
> value; this results in undefined behavior in a value-returning function."
>
> So this is undefined behavior at run-time (not ill-formed code); there is
> no way it could be undefined behavior at run-time if compilers refused to
> compile the code in the first place. Ergo: a conforming compiler may not
> refuse to compile the code, and the compiled code must actually run
> normally as far as the "flowing off the end of a function" UB does not
> actually happen.
I said that already, did you misunderstand me? I said it has to be the
case that it cannot be an error.
/Flibble
== 3 of 6 ==
Date: Fri, Dec 13 2013 3:11 pm
From: Paavo Helde
Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
news:wq-dnY52RO-iFDbPnZ2dnUVZ8g-dnZ2d@giganews.com:
> On 13/12/2013 21:49, Paavo Helde wrote:
>> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
>> news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
>>> Well that warning is clearly a bag of shite, what were they
>>> thinking? The salient point here though is that it is only a warning
>>> and not an error which has to be the case.
>>
>> This cannot be a compile-time error. The standard clearly states:
>
> I said that already, did you misunderstand me? I said it has to be the
> case that it cannot be an error.
On second reading, it might be indeed that your claim can be interpreted
also in the way where "which" applies to "salient point", not to "error".
However, in such interpretation it is unclear why do you think the warning
is "a big of "shite"".
Cheers
Paavo
== 4 of 6 ==
Date: Fri, Dec 13 2013 3:35 pm
From: Mr Flibble
On 13/12/2013 23:11, Paavo Helde wrote:
> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
> news:wq-dnY52RO-iFDbPnZ2dnUVZ8g-dnZ2d@giganews.com:
>
>> On 13/12/2013 21:49, Paavo Helde wrote:
>>> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
>>> news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
>
>>>> Well that warning is clearly a bag of shite, what were they
>>>> thinking? The salient point here though is that it is only a warning
>>>> and not an error which has to be the case.
>>>
>>> This cannot be a compile-time error. The standard clearly states:
>>
>> I said that already, did you misunderstand me? I said it has to be the
>> case that it cannot be an error.
>
> On second reading, it might be indeed that your claim can be interpreted
> also in the way where "which" applies to "salient point", not to "error".
> However, in such interpretation it is unclear why do you think the warning
> is "a big of "shite"".
It is a bag of shite as the warning will likely be a false positive
unless the compiler can determine that control will indeed always flow
off the end.
"Bag of shite" is a catchphrase of Paul Calf:
http://www.youtube.com/watch?v=F-kfeyEzAT8
/Leigh
== 5 of 6 ==
Date: Fri, Dec 13 2013 7:54 pm
From: woodbrian77@gmail.com
On Friday, December 13, 2013 5:35:08 PM UTC-6, Mr Flibble wrote:
Please don't swear here.
== 6 of 6 ==
Date: Sat, Dec 14 2013 8:21 am
From: Mr Flibble
On 14/12/2013 03:54, woodbrian77@gmail.com wrote:
> On Friday, December 13, 2013 5:35:08 PM UTC-6, Mr Flibble wrote:
>
> Please don't swear here.
"Well that's a shit load of fucking bastard cunts" -- Paul Calf
http://www.youtube.com/watch?v=F-kfeyEzAT8
==============================================================================
TOPIC: Islam is the fastest growing religion in the world especially since
sept. 11.
http://groups.google.com/group/comp.lang.c++/t/c16b2698bcfe93c5?hl=en
==============================================================================
== 1 of 3 ==
Date: Fri, Dec 13 2013 2:12 pm
From: Paavo Helde
Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in news:AKCdna-
POcmy7TbPnZ2dnUVZ8o6dnZ2d@giganews.com:
[OT content deleted]
Dear Mr Flibble - please do not feed the troll!
Thanks
Paavo
== 2 of 3 ==
Date: Fri, Dec 13 2013 2:20 pm
From: Melzzzzz
On Fri, 13 Dec 2013 16:12:06 -0600
Paavo Helde <myfirstname@osa.pri.ee> wrote:
> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in news:AKCdna-
> POcmy7TbPnZ2dnUVZ8o6dnZ2d@giganews.com:
>
> [OT content deleted]
>
> Dear Mr Flibble - please do not feed the troll!
>
> Thanks
> Paavo
I can't see OP and Mr Fibble, seems they are known to usenet server
I'm using and filtered automatically.
--
Your aim is high and to the right.
== 3 of 3 ==
Date: Fri, Dec 13 2013 3:38 pm
From: Mr Flibble
On 13/12/2013 20:50, woodbrian77@gmail.com wrote:
> On Friday, December 13, 2013 2:38:06 PM UTC-6, Mr Flibble wrote:
>>
>
> Please don't swear here.
"Well that's a shit load of fucking bastard cunts" -- Paul Calf
http://www.youtube.com/watch?v=F-kfeyEzAT8
==============================================================================
TOPIC: public member variable vs. get/set functions
http://groups.google.com/group/comp.lang.c++/t/92f780d94e30f6f6?hl=en
==============================================================================
== 1 of 5 ==
Date: Fri, Dec 13 2013 3:47 pm
From: Seungbeom Kim
On 2013-12-11 13:23, �� Tiib wrote:
> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>
>> It surprises me that the real and imaginary components are not
>> public variables in the <complex> class template. Very unclear
>> to me the value of making them private.
>
> It is nowhere said that 'std::complex<float>' must be implemented as
> a class with two float members. The processor may have native support
> for complex arithmetic and 'std::complex' may internally use it or
> it may be is more efficient to implement it as array of two floats
> internally for whatever reasons.
That used to be true. However, with the adoption of LWG Issue #387[1],
I doubt if there could be any other way to implement std::complex<T>
than to have two data members of type T.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
--
Seungbeom Kim
== 2 of 5 ==
Date: Fri, Dec 13 2013 7:51 pm
From: "Alf P. Steinbach"
On 14.12.2013 00:47, Seungbeom Kim wrote:
> On 2013-12-11 13:23, �� Tiib wrote:
>> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>>
>>> It surprises me that the real and imaginary components are not
>>> public variables in the <complex> class template. Very unclear
>>> to me the value of making them private.
>>
>> It is nowhere said that 'std::complex<float>' must be implemented as
>> a class with two float members. The processor may have native support
>> for complex arithmetic and 'std::complex' may internally use it or
>> it may be is more efficient to implement it as array of two floats
>> internally for whatever reasons.
>
> That used to be true. However, with the adoption of LWG Issue #387[1],
> I doubt if there could be any other way to implement std::complex<T>
> than to have two data members of type T.
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
Thanks for that reference & info, and ... I think you mean, "two data
members or an array of two values of".
The `reinterpret_cast` in the LWG issue spec most naturally suggests an
array, which would have to be the first member in order to have an
implementation that only relies on standard C++ functionality
(reinterpret_cast to/from first member of suitably restricted class is
supported in general for C compatibility).
The lack of a specification of size means that low level / C language
access to arrays of complex values is still not supported. That's a big
surprise. I can't believe that that's intentional.
Cheers,
- Alf
== 3 of 5 ==
Date: Fri, Dec 13 2013 8:57 pm
From: Richard Damon
On 12/13/13, 10:51 PM, Alf P. Steinbach wrote:
> On 14.12.2013 00:47, Seungbeom Kim wrote:
>> On 2013-12-11 13:23, �� Tiib wrote:
>>> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>>>
>>>> It surprises me that the real and imaginary components are not
>>>> public variables in the <complex> class template. Very unclear
>>>> to me the value of making them private.
>>>
>>> It is nowhere said that 'std::complex<float>' must be implemented as
>>> a class with two float members. The processor may have native support
>>> for complex arithmetic and 'std::complex' may internally use it or
>>> it may be is more efficient to implement it as array of two floats
>>> internally for whatever reasons.
>>
>> That used to be true. However, with the adoption of LWG Issue #387[1],
>> I doubt if there could be any other way to implement std::complex<T>
>> than to have two data members of type T.
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
>
> Thanks for that reference & info, and ... I think you mean, "two data
> members or an array of two values of".
>
> The `reinterpret_cast` in the LWG issue spec most naturally suggests an
> array, which would have to be the first member in order to have an
> implementation that only relies on standard C++ functionality
> (reinterpret_cast to/from first member of suitably restricted class is
> supported in general for C compatibility).
>
> The lack of a specification of size means that low level / C language
> access to arrays of complex values is still not supported. That's a big
> surprise. I can't believe that that's intentional.
>
>
> Cheers,
>
> - Alf
>
The issue did say:
Moreover, if a is an expression of pointer type cv complex<T>* and the
expression a[i] is well-defined for an integer expression i then:
reinterpret_cast<cv T*>(a)[2*i] designates the real part of a[i]; and
reinterpret_cast<cv T*>(a)[2*i+1] designates the imaginary part of a[i].
which effectively requires sizeof(complex<T>) = 2*sizeof(T)
== 4 of 5 ==
Date: Sat, Dec 14 2013 1:28 am
From: "Alf P. Steinbach"
On 14.12.2013 05:57, Richard Damon wrote:
> On 12/13/13, 10:51 PM, Alf P. Steinbach wrote:
>> On 14.12.2013 00:47, Seungbeom Kim wrote:
>>> On 2013-12-11 13:23, �� Tiib wrote:
>>>> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>>>>
>>>>> It surprises me that the real and imaginary components are not
>>>>> public variables in the <complex> class template. Very unclear
>>>>> to me the value of making them private.
>>>>
>>>> It is nowhere said that 'std::complex<float>' must be implemented as
>>>> a class with two float members. The processor may have native support
>>>> for complex arithmetic and 'std::complex' may internally use it or
>>>> it may be is more efficient to implement it as array of two floats
>>>> internally for whatever reasons.
>>>
>>> That used to be true. However, with the adoption of LWG Issue #387[1],
>>> I doubt if there could be any other way to implement std::complex<T>
>>> than to have two data members of type T.
>>>
>>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
>>
>> Thanks for that reference & info, and ... I think you mean, "two data
>> members or an array of two values of".
>>
>> The `reinterpret_cast` in the LWG issue spec most naturally suggests an
>> array, which would have to be the first member in order to have an
>> implementation that only relies on standard C++ functionality
>> (reinterpret_cast to/from first member of suitably restricted class is
>> supported in general for C compatibility).
>>
>> The lack of a specification of size means that low level / C language
>> access to arrays of complex values is still not supported. That's a big
>> surprise. I can't believe that that's intentional.
>>
>>
>> Cheers,
>>
>> - Alf
>>
>
> The issue did say:
>
> Moreover, if a is an expression of pointer type cv complex<T>* and the
> expression a[i] is well-defined for an integer expression i then:
>
> reinterpret_cast<cv T*>(a)[2*i] designates the real part of a[i]; and
> reinterpret_cast<cv T*>(a)[2*i+1] designates the imaginary part of a[i].
>
> which effectively requires sizeof(complex<T>) = 2*sizeof(T)
>
Thanks, I didn't see the correct parenthesification.
Cheers,
- Alf
== 5 of 5 ==
Date: Sat, Dec 14 2013 11:04 pm
From: Seungbeom Kim
On 2013-12-13 19:51, Alf P. Steinbach wrote:
> On 14.12.2013 00:47, Seungbeom Kim wrote:
>>
>> That used to be true. However, with the adoption of LWG Issue #387[1],
>> I doubt if there could be any other way to implement std::complex<T>
>> than to have two data members of type T.
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
>
> Thanks for that reference & info, and ... I think you mean, "two data
> members or an array of two values of".
That's right. (I'm not sure if elements of a member array can officially
be considered as data members as well. :))
> The `reinterpret_cast` in the LWG issue spec most naturally suggests
> an array, [...]
Not necessarily, though an array is certainly possible. The standard
probably does not guarantee that two data members of the same type
declared consecutively without any intervening access specifiers are
allocated adjacently, but I believe many common implementations do it,
and an implementation can ensure that for std::complex (by any magic
if necessary) since it is part of the implementation anyway.
--
Seungbeom Kim
==============================================================================
TOPIC: Sort comparator function
http://groups.google.com/group/comp.lang.c++/t/c28f056fa89ab849?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Dec 14 2013 3:05 am
From: Fab
Dear All,
I am quite experienced with C++ but here's something I can't recall and
forgive me if I just don't recognize the (possible) simplicity of my
question.
I have the following code
// Custom comparator for pair,
// compares only by the first field
struct compare_first
{
template <typename T>
bool operator() (const T& a, const T& b)
{
return a.first < b.first;
}
};
which is later used in a sort like this
std::sort(cellid_particleid.begin(), cellid_particleid.end(), compare_first());
The sort orders a list of particles according to their cell ID. The
std::pair<unsigned int, unsigned int> contains cellID and particleID,
respectively.
Since the operator() is templated in the comparator, why does my code
still compile? I assume the struct hides the templation, but is this
taken care of in std::sort then?
Thanks + best
Fab
== 2 of 4 ==
Date: Sat, Dec 14 2013 6:56 am
From: "Alf P. Steinbach"
On 14.12.2013 12:05, Fab wrote:
>
> I am quite experienced with C++ but here's something I can't recall and
> forgive me if I just don't recognize the (possible) simplicity of my
> question.
>
> I have the following code
>
> // Custom comparator for pair,
> // compares only by the first field
> struct compare_first
> {
> template <typename T>
> bool operator() (const T& a, const T& b)
> {
> return a.first < b.first;
> }
> };
>
> which is later used in a sort like this
>
> std::sort(cellid_particleid.begin(), cellid_particleid.end(), compare_first());
>
> The sort orders a list of particles according to their cell ID. The
> std::pair<unsigned int, unsigned int> contains cellID and particleID,
> respectively.
>
> Since the operator() is templated in the comparator, why does my code
> still compile? I assume the struct hides the templation, but is this
> taken care of in std::sort then?
From the information given it's impossible to say what makes the code
compile.
See the FAQ item titled "How do I post a question about code that
doesn't work correctly?", currently available at (among others) <url:
http://www.parashift.com/c++-faq/posting-code.html), in particular the
three first bullet points.
It's often a good idea to take a look at the FAQ.
Cheers & hth.,
- Alf
== 3 of 4 ==
Date: Sat, Dec 14 2013 8:35 am
From: Mr Flibble
On 14/12/2013 11:05, Fab wrote:
> Dear All,
>
> I am quite experienced with C++ but here's something I can't recall and
> forgive me if I just don't recognize the (possible) simplicity of my
> question.
>
> I have the following code
>
> // Custom comparator for pair,
> // compares only by the first field
> struct compare_first
> {
> template <typename T>
> bool operator() (const T& a, const T& b)
> {
> return a.first < b.first;
> }
> };
>
> which is later used in a sort like this
>
> std::sort(cellid_particleid.begin(), cellid_particleid.end(), compare_first());
>
> The sort orders a list of particles according to their cell ID. The
> std::pair<unsigned int, unsigned int> contains cellID and particleID,
> respectively.
>
> Since the operator() is templated in the comparator, why does my code
> still compile? I assume the struct hides the templation, but is this
> taken care of in std::sort then?
It compiles because it is correct. The member function template will be
instantiated by std::sort.
The main reason why std::less takes its argument type as a class
template parameter is because it needs to pass it on to what it derives
from (std::binary_function).
As usual safely ignore Alf as he is talking crap again.
/Flibble
== 4 of 4 ==
Date: Sat, Dec 14 2013 11:46 am
From: Mr Flibble
On 14/12/2013 16:35, Mr Flibble wrote:
> On 14/12/2013 11:05, Fab wrote:
>> Dear All,
>>
>> I am quite experienced with C++ but here's something I can't recall and
>> forgive me if I just don't recognize the (possible) simplicity of my
>> question.
>>
>> I have the following code
>>
>> // Custom comparator for pair,
>> // compares only by the first field
>> struct compare_first
>> {
>> template <typename T>
>> bool operator() (const T& a, const T& b)
>> {
>> return a.first < b.first;
>> }
>> };
>>
>> which is later used in a sort like this
>>
>> std::sort(cellid_particleid.begin(), cellid_particleid.end(),
>> compare_first());
>>
>> The sort orders a list of particles according to their cell ID. The
>> std::pair<unsigned int, unsigned int> contains cellID and particleID,
>> respectively.
>>
>> Since the operator() is templated in the comparator, why does my code
>> still compile? I assume the struct hides the templation, but is this
>> taken care of in std::sort then?
>
> It compiles because it is correct. The member function template will be
> instantiated by std::sort.
>
> The main reason why std::less takes its argument type as a class
> template parameter is because it needs to pass it on to what it derives
> from (std::binary_function).
Obviously that is not the only reason; the ability to specify the
argument type explicitly is also sometimes needed to avoid ambiguity.
/Flibble
==============================================================================
TOPIC: Native Aspect-oriented programming in C++
http://groups.google.com/group/comp.lang.c++/t/27f28eff7b33632c?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 14 2013 3:48 am
From: Dombo
On 11-Dec-13 23:34, David Brown wrote:
> Whether the actions of Alf (or anyone else here) is libel or not
> depends, I think, on whether comments really harm anyone's reputation.
> In Norway, we don't go in for trivial lawsuits - I think Alf is entirely
> safe from any legal action, and I doubt if any judge or jury will
> consider that reputations to be seriously harmed.
The only reputation Alf is harming is his own*. Imagine a potential
employer googling his name. No doubt the postings he made here will turn
up. What kind of impression will his postings leave of him?
> For my own part, I am not worried about my reputation, or that anyone
> else will pay much attention to Alf's killfile. And it is his choice to
> decide which posts he reads, and which he ignores. But it certainly is
> not pleasant to see one's name in a list of so-called trolls.
If it is any consolation; if someone has openly fallen out with so many
people (most of which are valued contributors) and feels the need to
publish that repeatedly, it is quite clear that the problem is not with
those people.
> And of course it makes things difficult in threads in which both Alf and
> I (or other "trolls") are involved. (As Chris said earlier, there are
> no doubts about Alf's C++ experience, knowledge and willingness to help
> and advise, so his contributions to threads are valued.)
Alf is also sometimes wrong (just like me, you and everyone else). One
of the benefits of a medium like usenet is that one can be corrected by
others to the benefit of us all. Alf's extremely strong tendency to
resort to personal attacks rather than engaging in a civilized
discussion stands in the way of this, and that is IMHO detrimental to
this group.
*I'm assuming here he is posting using his own name, rather than someone
else using his name to destroy his reputation.
==============================================================================
TOPIC: Available C++ Libraries FAQ
http://groups.google.com/group/comp.lang.c++/t/22a557c7fec86af9?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 14 2013 3:23 pm
From: Nikki Locke
Available C++ Libraries FAQ
URL: http://www.trumphurst.com/cpplibs/
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
Maintainer: Nikki Locke cpplibs@trumphurst.com
==============================================================================
TOPIC: Want to debug this?
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Dec 15 2013 9:31 am
From: woodbrian77@gmail.com
On Saturday, December 7, 2013 4:49:37 PM UTC-6, woodb...@gmail.com wrote:
>
> This is kind of pushing me towards
> moving to a newer OS. I think I've been on this
> version of the OS for over 5 months.
I wound up going to an older version of Linux in Debian.
I rebuilt all three tiers on Debian and tested them on
Debian. I couldn't reproduce the problem when running
on Debian.
Then I copied the Debian-built files to a Fedora machine
where I had originally encountered the problem. The
problem still occurred on Fedora. The Fedora machine
has an alpha or beta version of Fedora on it and my
guess is it has a TCP related bug.
== 2 of 3 ==
Date: Sun, Dec 15 2013 10:20 am
From: Geoff
On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
>On Saturday, December 7, 2013 4:49:37 PM UTC-6, woodb...@gmail.com wrote:
>>
>> This is kind of pushing me towards
>> moving to a newer OS. I think I've been on this
>> version of the OS for over 5 months.
>
>I wound up going to an older version of Linux in Debian.
>
>I rebuilt all three tiers on Debian and tested them on
>Debian. I couldn't reproduce the problem when running
>on Debian.
>
>Then I copied the Debian-built files to a Fedora machine
>where I had originally encountered the problem. The
>problem still occurred on Fedora. The Fedora machine
>has an alpha or beta version of Fedora on it and my
>guess is it has a TCP related bug.
Generally speaking, it's a Bad Idea(tm) to copy binaries from one
edition of Linux (Debian) to another (Fedora). The results are
unpredictable since they may not share a common ABI. It can be done
successfully but doing so while trying to "debug" your stated problem
is just adding another kind of potential error into the scenario.
Instead, you should copy your sources over and build your projects on
each platform. This is why package management exists.
"Alpha or beta" version is meaningless in this context. The current
stable supported release of Fedora is 19. Fedora 20 is available in
alpha and beta releases but why would you introduce yet another set of
problems into the mix?
In your original problem statement you also say you're using clang and
gcc projects. Why? If they share libraries you are running the risk of
ABI incompatibility again. Choose a tool (clang) and bring your
gcc-compiled project up to date and compile all your related projects
with the same tools.
== 3 of 3 ==
Date: Sun, Dec 15 2013 12:57 pm
From: Jorgen Grahn
On Sun, 2013-12-15, Geoff wrote:
> On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
...
>>Then I copied the Debian-built files to a Fedora machine
>>where I had originally encountered the problem. The
>>problem still occurred on Fedora. The Fedora machine
>>has an alpha or beta version of Fedora on it and my
>>guess is it has a TCP related bug.
> Generally speaking, it's a Bad Idea(tm) to copy binaries from one
> edition of Linux (Debian) to another (Fedora). The results are
> unpredictable since they may not share a common ABI.
Are you reasonably sure about that? Any references?
The main burden of keeping things sane lies on the library writers.
When an incompatible version of e.g. the Gnu libc comes out, they must
step the .so file's revision number. (Somehow. The details are
unclear to me.) Then your program will fail to run unless the right
version of libc is available.
It's possible that Fedora takes libfoo version X from upstream and
modifies it so it's not compatible with the Debian build of libfoo
version X ... or modifies the compiler so that it generates such an
incompatibility. But that seems to me rather unlikely since it means
messing with the rather delicate upstream ABI decisions. If you're
Fedora, your can only switch ABIs when the upstream does it, and then
you're stuck with that decision until they release libfoo version X+1.
...
> Instead, you should copy your sources over and build your projects on
> each platform. This is why package management exists.
I agree that is the sane and normal way of doing it. And yes, that
also means I'm not sure you are wrong.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: Hope for your project - a little off topic.
http://groups.google.com/group/comp.lang.c++/t/e4b7c8315db7f411?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 15 2013 10:14 am
From: woodbrian77@gmail.com
On Friday, October 4, 2013 5:08:44 PM UTC-5, woodb...@gmail.com wrote:
> Also I'll pay someone $100 cash and give them a $200
> investment in my company if they help me find someone
> to work with. The company rewards investments to 3
> times their original amount. So you would receive
> anywhere from $0 to $600 on the investment part,
> depending on how things go for the company. I'll pay
> the $100 cash after working with whomever it is for 4
> months.
I'm happy to announce an increase here.
I'll pay $300 cash and give a $300 investment in my
company.
== 2 of 2 ==
Date: Sun, Dec 15 2013 10:39 am
From: Mr Flibble
On 15/12/2013 18:14, woodbrian77@gmail.com wrote:
> On Friday, October 4, 2013 5:08:44 PM UTC-5, woodb...@gmail.com wrote:
>> Also I'll pay someone $100 cash and give them a $200
>> investment in my company if they help me find someone
>> to work with. The company rewards investments to 3
>> times their original amount. So you would receive
>> anywhere from $0 to $600 on the investment part,
>> depending on how things go for the company. I'll pay
>> the $100 cash after working with whomever it is for 4
>> months.
>
> I'm happy to announce an increase here.
>
> I'll pay $300 cash and give a $300 investment in my
> company.
"Well that's a shit load of fucking bastard cunts" -- Paul Calf
http://www.youtube.com/watch?v=F-kfeyEzAT8
==============================================================================
TOPIC: My two string classes could be "templatized" into one, but for one
problem...
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 15 2013 12:54 pm
From: DSF
On Mon, 09 Dec 2013 00:52:07 -0500, DSF <notavalid@address.here>
wrote:
Hello group! A group answer for the group of responders.
Sorry I'm late responding. It's due to a few sick days and the fact
that converting the FStringX classes into a template wasn't as simple
as I thought and I had to go do some more research on templates. The
FStringX classes contained code I'd never tried to put in a template.
Also, I wanted to be sure it actually worked before responding.
First, I'd like to thank Paavo Helde, Robert Wessel and Tobias
M�ller for what turned out to be the best answer. Overload the string
functions.
To my credit, I would like to say I created the code below before
reading Paavo's post on the 10th. I dropped the d and replaced it
with a capital F to visually fit in better with the FString class.
Also, and this will cover Robert Wessel's comment about exporting the
dstr* series to a C program, the dstr* series and other string
manipulators are in a C library I've written. Useable for both
languages. About 80% of the library is written in x86 assembly, so
some kind of wrapper was necessary. (I suppose one could figure out
the name mangling and export C++ names in assembly code, but wrappers
are easier, cost nothing, and are more likely to be portable between
compilers on the same platform.)
This means I couldn't use Paavo's code from the tenth, because it
would break the UNICODE-defined A and W in the string library header.
Come to think of it, I could just #undef dstrlen and any others after
the header is included, then Paavo's method would work. But I think
I'll leave it as it is. It separates the C nomenclature from the C++.
Under the d'oh! category: I don't know if I just forgot it a long
time ago or whatever, but it never occurred to me that non-member
functions could be overloaded, too. It hasn't come up in my
programming. But now...
inline size_t Fstrlen(const char *str){return ::dstrlenA(str);}
inline size_t Fstrlen(const wchar_t *str){return ::dstrlenW(str);}
etc.
... I get the correct version for free! (No overhead!) The compiler
picks the correct FStrlen by parameter type and, with inlining,
Fstrlen(some_string); assembles to a direct call to the proper
dstrlen, A or W.
Problem solved. But to be thorough, answers to other questions.
As to Paavo Helde's question regarding:
// FStr being the template class
typedef FStr<char> FStringA;
typedef FStr<wchar_t> FStringW;
#ifdef UNICODE
#define UCFLAG
#undef UNICODE
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* How is it that this code seems to work? - 6 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/9561ec5e330ee93f?hl=en
* Islam is the fastest growing religion in the world especially since sept. 11.
- 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/c16b2698bcfe93c5?hl=en
* public member variable vs. get/set functions - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/92f780d94e30f6f6?hl=en
* Sort comparator function - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/c28f056fa89ab849?hl=en
* Native Aspect-oriented programming in C++ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/27f28eff7b33632c?hl=en
* Available C++ Libraries FAQ - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/22a557c7fec86af9?hl=en
* Want to debug this? - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
* Hope for your project - a little off topic. - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/e4b7c8315db7f411?hl=en
* My two string classes could be "templatized" into one, but for one problem...
- 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
==============================================================================
TOPIC: How is it that this code seems to work?
http://groups.google.com/group/comp.lang.c++/t/9561ec5e330ee93f?hl=en
==============================================================================
== 1 of 6 ==
Date: Fri, Dec 13 2013 1:49 pm
From: Paavo Helde
Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
> On 13/12/2013 17:50, Scott Lurndal wrote:
>> $ cat /tmp/a.cpp
>> #include <stdlib.h>
>> #include <string.h>
>>
>> bool bar(void) { return strcasecmp(getenv("FRED"), "joe") == 0; }
>> bool baz(void) { return strcasecmp(getenv("HOME"), "/home/fred")==0;
>> }
>>
>> extern void wibble(void);
>>
>> bool foo(void) { if (bar()) return baz(); wibble(); }
>> $ g++ -Wall -c -o /tmp/a /tmp/a.cpp
>> /tmp/a.cpp: In function 'bool foo()':
>> /tmp/a.cpp:9:54: warning: control reaches end of non-void function
>> [-Wreturn-type]
>
> Well that warning is clearly a bag of shite, what were they thinking?
> The salient point here though is that it is only a warning and not an
> error which has to be the case.
This cannot be a compile-time error. The standard clearly states:
"Flowing off the end of a function is equivalent to a return with no
value; this results in undefined behavior in a value-returning function."
So this is undefined behavior at run-time (not ill-formed code); there is
no way it could be undefined behavior at run-time if compilers refused to
compile the code in the first place. Ergo: a conforming compiler may not
refuse to compile the code, and the compiled code must actually run
normally as far as the "flowing off the end of a function" UB does not
actually happen.
Cheers
Paavo
== 2 of 6 ==
Date: Fri, Dec 13 2013 2:25 pm
From: Mr Flibble
On 13/12/2013 21:49, Paavo Helde wrote:
> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
> news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
>
>> On 13/12/2013 17:50, Scott Lurndal wrote:
>>> $ cat /tmp/a.cpp
>>> #include <stdlib.h>
>>> #include <string.h>
>>>
>>> bool bar(void) { return strcasecmp(getenv("FRED"), "joe") == 0; }
>>> bool baz(void) { return strcasecmp(getenv("HOME"), "/home/fred")==0;
>>> }
>>>
>>> extern void wibble(void);
>>>
>>> bool foo(void) { if (bar()) return baz(); wibble(); }
>>> $ g++ -Wall -c -o /tmp/a /tmp/a.cpp
>>> /tmp/a.cpp: In function 'bool foo()':
>>> /tmp/a.cpp:9:54: warning: control reaches end of non-void function
>>> [-Wreturn-type]
>>
>> Well that warning is clearly a bag of shite, what were they thinking?
>> The salient point here though is that it is only a warning and not an
>> error which has to be the case.
>
> This cannot be a compile-time error. The standard clearly states:
>
> "Flowing off the end of a function is equivalent to a return with no
> value; this results in undefined behavior in a value-returning function."
>
> So this is undefined behavior at run-time (not ill-formed code); there is
> no way it could be undefined behavior at run-time if compilers refused to
> compile the code in the first place. Ergo: a conforming compiler may not
> refuse to compile the code, and the compiled code must actually run
> normally as far as the "flowing off the end of a function" UB does not
> actually happen.
I said that already, did you misunderstand me? I said it has to be the
case that it cannot be an error.
/Flibble
== 3 of 6 ==
Date: Fri, Dec 13 2013 3:11 pm
From: Paavo Helde
Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
news:wq-dnY52RO-iFDbPnZ2dnUVZ8g-dnZ2d@giganews.com:
> On 13/12/2013 21:49, Paavo Helde wrote:
>> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
>> news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
>>> Well that warning is clearly a bag of shite, what were they
>>> thinking? The salient point here though is that it is only a warning
>>> and not an error which has to be the case.
>>
>> This cannot be a compile-time error. The standard clearly states:
>
> I said that already, did you misunderstand me? I said it has to be the
> case that it cannot be an error.
On second reading, it might be indeed that your claim can be interpreted
also in the way where "which" applies to "salient point", not to "error".
However, in such interpretation it is unclear why do you think the warning
is "a big of "shite"".
Cheers
Paavo
== 4 of 6 ==
Date: Fri, Dec 13 2013 3:35 pm
From: Mr Flibble
On 13/12/2013 23:11, Paavo Helde wrote:
> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
> news:wq-dnY52RO-iFDbPnZ2dnUVZ8g-dnZ2d@giganews.com:
>
>> On 13/12/2013 21:49, Paavo Helde wrote:
>>> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in
>>> news:TZOdnbwzKujA0DbPnZ2dnUVZ8i4AAAAA@giganews.com:
>
>>>> Well that warning is clearly a bag of shite, what were they
>>>> thinking? The salient point here though is that it is only a warning
>>>> and not an error which has to be the case.
>>>
>>> This cannot be a compile-time error. The standard clearly states:
>>
>> I said that already, did you misunderstand me? I said it has to be the
>> case that it cannot be an error.
>
> On second reading, it might be indeed that your claim can be interpreted
> also in the way where "which" applies to "salient point", not to "error".
> However, in such interpretation it is unclear why do you think the warning
> is "a big of "shite"".
It is a bag of shite as the warning will likely be a false positive
unless the compiler can determine that control will indeed always flow
off the end.
"Bag of shite" is a catchphrase of Paul Calf:
http://www.youtube.com/watch?v=F-kfeyEzAT8
/Leigh
== 5 of 6 ==
Date: Fri, Dec 13 2013 7:54 pm
From: woodbrian77@gmail.com
On Friday, December 13, 2013 5:35:08 PM UTC-6, Mr Flibble wrote:
Please don't swear here.
== 6 of 6 ==
Date: Sat, Dec 14 2013 8:21 am
From: Mr Flibble
On 14/12/2013 03:54, woodbrian77@gmail.com wrote:
> On Friday, December 13, 2013 5:35:08 PM UTC-6, Mr Flibble wrote:
>
> Please don't swear here.
"Well that's a shit load of fucking bastard cunts" -- Paul Calf
http://www.youtube.com/watch?v=F-kfeyEzAT8
==============================================================================
TOPIC: Islam is the fastest growing religion in the world especially since
sept. 11.
http://groups.google.com/group/comp.lang.c++/t/c16b2698bcfe93c5?hl=en
==============================================================================
== 1 of 3 ==
Date: Fri, Dec 13 2013 2:12 pm
From: Paavo Helde
Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in news:AKCdna-
POcmy7TbPnZ2dnUVZ8o6dnZ2d@giganews.com:
[OT content deleted]
Dear Mr Flibble - please do not feed the troll!
Thanks
Paavo
== 2 of 3 ==
Date: Fri, Dec 13 2013 2:20 pm
From: Melzzzzz
On Fri, 13 Dec 2013 16:12:06 -0600
Paavo Helde <myfirstname@osa.pri.ee> wrote:
> Mr Flibble <flibbleREMOVE_THIS@i42.co.uk> wrote in news:AKCdna-
> POcmy7TbPnZ2dnUVZ8o6dnZ2d@giganews.com:
>
> [OT content deleted]
>
> Dear Mr Flibble - please do not feed the troll!
>
> Thanks
> Paavo
I can't see OP and Mr Fibble, seems they are known to usenet server
I'm using and filtered automatically.
--
Your aim is high and to the right.
== 3 of 3 ==
Date: Fri, Dec 13 2013 3:38 pm
From: Mr Flibble
On 13/12/2013 20:50, woodbrian77@gmail.com wrote:
> On Friday, December 13, 2013 2:38:06 PM UTC-6, Mr Flibble wrote:
>>
>
> Please don't swear here.
"Well that's a shit load of fucking bastard cunts" -- Paul Calf
http://www.youtube.com/watch?v=F-kfeyEzAT8
==============================================================================
TOPIC: public member variable vs. get/set functions
http://groups.google.com/group/comp.lang.c++/t/92f780d94e30f6f6?hl=en
==============================================================================
== 1 of 5 ==
Date: Fri, Dec 13 2013 3:47 pm
From: Seungbeom Kim
On 2013-12-11 13:23, �� Tiib wrote:
> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>
>> It surprises me that the real and imaginary components are not
>> public variables in the <complex> class template. Very unclear
>> to me the value of making them private.
>
> It is nowhere said that 'std::complex<float>' must be implemented as
> a class with two float members. The processor may have native support
> for complex arithmetic and 'std::complex' may internally use it or
> it may be is more efficient to implement it as array of two floats
> internally for whatever reasons.
That used to be true. However, with the adoption of LWG Issue #387[1],
I doubt if there could be any other way to implement std::complex<T>
than to have two data members of type T.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
--
Seungbeom Kim
== 2 of 5 ==
Date: Fri, Dec 13 2013 7:51 pm
From: "Alf P. Steinbach"
On 14.12.2013 00:47, Seungbeom Kim wrote:
> On 2013-12-11 13:23, �� Tiib wrote:
>> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>>
>>> It surprises me that the real and imaginary components are not
>>> public variables in the <complex> class template. Very unclear
>>> to me the value of making them private.
>>
>> It is nowhere said that 'std::complex<float>' must be implemented as
>> a class with two float members. The processor may have native support
>> for complex arithmetic and 'std::complex' may internally use it or
>> it may be is more efficient to implement it as array of two floats
>> internally for whatever reasons.
>
> That used to be true. However, with the adoption of LWG Issue #387[1],
> I doubt if there could be any other way to implement std::complex<T>
> than to have two data members of type T.
>
> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
Thanks for that reference & info, and ... I think you mean, "two data
members or an array of two values of".
The `reinterpret_cast` in the LWG issue spec most naturally suggests an
array, which would have to be the first member in order to have an
implementation that only relies on standard C++ functionality
(reinterpret_cast to/from first member of suitably restricted class is
supported in general for C compatibility).
The lack of a specification of size means that low level / C language
access to arrays of complex values is still not supported. That's a big
surprise. I can't believe that that's intentional.
Cheers,
- Alf
== 3 of 5 ==
Date: Fri, Dec 13 2013 8:57 pm
From: Richard Damon
On 12/13/13, 10:51 PM, Alf P. Steinbach wrote:
> On 14.12.2013 00:47, Seungbeom Kim wrote:
>> On 2013-12-11 13:23, �� Tiib wrote:
>>> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>>>
>>>> It surprises me that the real and imaginary components are not
>>>> public variables in the <complex> class template. Very unclear
>>>> to me the value of making them private.
>>>
>>> It is nowhere said that 'std::complex<float>' must be implemented as
>>> a class with two float members. The processor may have native support
>>> for complex arithmetic and 'std::complex' may internally use it or
>>> it may be is more efficient to implement it as array of two floats
>>> internally for whatever reasons.
>>
>> That used to be true. However, with the adoption of LWG Issue #387[1],
>> I doubt if there could be any other way to implement std::complex<T>
>> than to have two data members of type T.
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
>
> Thanks for that reference & info, and ... I think you mean, "two data
> members or an array of two values of".
>
> The `reinterpret_cast` in the LWG issue spec most naturally suggests an
> array, which would have to be the first member in order to have an
> implementation that only relies on standard C++ functionality
> (reinterpret_cast to/from first member of suitably restricted class is
> supported in general for C compatibility).
>
> The lack of a specification of size means that low level / C language
> access to arrays of complex values is still not supported. That's a big
> surprise. I can't believe that that's intentional.
>
>
> Cheers,
>
> - Alf
>
The issue did say:
Moreover, if a is an expression of pointer type cv complex<T>* and the
expression a[i] is well-defined for an integer expression i then:
reinterpret_cast<cv T*>(a)[2*i] designates the real part of a[i]; and
reinterpret_cast<cv T*>(a)[2*i+1] designates the imaginary part of a[i].
which effectively requires sizeof(complex<T>) = 2*sizeof(T)
== 4 of 5 ==
Date: Sat, Dec 14 2013 1:28 am
From: "Alf P. Steinbach"
On 14.12.2013 05:57, Richard Damon wrote:
> On 12/13/13, 10:51 PM, Alf P. Steinbach wrote:
>> On 14.12.2013 00:47, Seungbeom Kim wrote:
>>> On 2013-12-11 13:23, �� Tiib wrote:
>>>> On Wednesday, 11 December 2013 22:37:21 UTC+2, W Karas wrote:
>>>>>
>>>>> It surprises me that the real and imaginary components are not
>>>>> public variables in the <complex> class template. Very unclear
>>>>> to me the value of making them private.
>>>>
>>>> It is nowhere said that 'std::complex<float>' must be implemented as
>>>> a class with two float members. The processor may have native support
>>>> for complex arithmetic and 'std::complex' may internally use it or
>>>> it may be is more efficient to implement it as array of two floats
>>>> internally for whatever reasons.
>>>
>>> That used to be true. However, with the adoption of LWG Issue #387[1],
>>> I doubt if there could be any other way to implement std::complex<T>
>>> than to have two data members of type T.
>>>
>>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
>>
>> Thanks for that reference & info, and ... I think you mean, "two data
>> members or an array of two values of".
>>
>> The `reinterpret_cast` in the LWG issue spec most naturally suggests an
>> array, which would have to be the first member in order to have an
>> implementation that only relies on standard C++ functionality
>> (reinterpret_cast to/from first member of suitably restricted class is
>> supported in general for C compatibility).
>>
>> The lack of a specification of size means that low level / C language
>> access to arrays of complex values is still not supported. That's a big
>> surprise. I can't believe that that's intentional.
>>
>>
>> Cheers,
>>
>> - Alf
>>
>
> The issue did say:
>
> Moreover, if a is an expression of pointer type cv complex<T>* and the
> expression a[i] is well-defined for an integer expression i then:
>
> reinterpret_cast<cv T*>(a)[2*i] designates the real part of a[i]; and
> reinterpret_cast<cv T*>(a)[2*i+1] designates the imaginary part of a[i].
>
> which effectively requires sizeof(complex<T>) = 2*sizeof(T)
>
Thanks, I didn't see the correct parenthesification.
Cheers,
- Alf
== 5 of 5 ==
Date: Sat, Dec 14 2013 11:04 pm
From: Seungbeom Kim
On 2013-12-13 19:51, Alf P. Steinbach wrote:
> On 14.12.2013 00:47, Seungbeom Kim wrote:
>>
>> That used to be true. However, with the adoption of LWG Issue #387[1],
>> I doubt if there could be any other way to implement std::complex<T>
>> than to have two data members of type T.
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387
>
> Thanks for that reference & info, and ... I think you mean, "two data
> members or an array of two values of".
That's right. (I'm not sure if elements of a member array can officially
be considered as data members as well. :))
> The `reinterpret_cast` in the LWG issue spec most naturally suggests
> an array, [...]
Not necessarily, though an array is certainly possible. The standard
probably does not guarantee that two data members of the same type
declared consecutively without any intervening access specifiers are
allocated adjacently, but I believe many common implementations do it,
and an implementation can ensure that for std::complex (by any magic
if necessary) since it is part of the implementation anyway.
--
Seungbeom Kim
==============================================================================
TOPIC: Sort comparator function
http://groups.google.com/group/comp.lang.c++/t/c28f056fa89ab849?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Dec 14 2013 3:05 am
From: Fab
Dear All,
I am quite experienced with C++ but here's something I can't recall and
forgive me if I just don't recognize the (possible) simplicity of my
question.
I have the following code
// Custom comparator for pair,
// compares only by the first field
struct compare_first
{
template <typename T>
bool operator() (const T& a, const T& b)
{
return a.first < b.first;
}
};
which is later used in a sort like this
std::sort(cellid_particleid.begin(), cellid_particleid.end(), compare_first());
The sort orders a list of particles according to their cell ID. The
std::pair<unsigned int, unsigned int> contains cellID and particleID,
respectively.
Since the operator() is templated in the comparator, why does my code
still compile? I assume the struct hides the templation, but is this
taken care of in std::sort then?
Thanks + best
Fab
== 2 of 4 ==
Date: Sat, Dec 14 2013 6:56 am
From: "Alf P. Steinbach"
On 14.12.2013 12:05, Fab wrote:
>
> I am quite experienced with C++ but here's something I can't recall and
> forgive me if I just don't recognize the (possible) simplicity of my
> question.
>
> I have the following code
>
> // Custom comparator for pair,
> // compares only by the first field
> struct compare_first
> {
> template <typename T>
> bool operator() (const T& a, const T& b)
> {
> return a.first < b.first;
> }
> };
>
> which is later used in a sort like this
>
> std::sort(cellid_particleid.begin(), cellid_particleid.end(), compare_first());
>
> The sort orders a list of particles according to their cell ID. The
> std::pair<unsigned int, unsigned int> contains cellID and particleID,
> respectively.
>
> Since the operator() is templated in the comparator, why does my code
> still compile? I assume the struct hides the templation, but is this
> taken care of in std::sort then?
From the information given it's impossible to say what makes the code
compile.
See the FAQ item titled "How do I post a question about code that
doesn't work correctly?", currently available at (among others) <url:
http://www.parashift.com/c++-faq/posting-code.html), in particular the
three first bullet points.
It's often a good idea to take a look at the FAQ.
Cheers & hth.,
- Alf
== 3 of 4 ==
Date: Sat, Dec 14 2013 8:35 am
From: Mr Flibble
On 14/12/2013 11:05, Fab wrote:
> Dear All,
>
> I am quite experienced with C++ but here's something I can't recall and
> forgive me if I just don't recognize the (possible) simplicity of my
> question.
>
> I have the following code
>
> // Custom comparator for pair,
> // compares only by the first field
> struct compare_first
> {
> template <typename T>
> bool operator() (const T& a, const T& b)
> {
> return a.first < b.first;
> }
> };
>
> which is later used in a sort like this
>
> std::sort(cellid_particleid.begin(), cellid_particleid.end(), compare_first());
>
> The sort orders a list of particles according to their cell ID. The
> std::pair<unsigned int, unsigned int> contains cellID and particleID,
> respectively.
>
> Since the operator() is templated in the comparator, why does my code
> still compile? I assume the struct hides the templation, but is this
> taken care of in std::sort then?
It compiles because it is correct. The member function template will be
instantiated by std::sort.
The main reason why std::less takes its argument type as a class
template parameter is because it needs to pass it on to what it derives
from (std::binary_function).
As usual safely ignore Alf as he is talking crap again.
/Flibble
== 4 of 4 ==
Date: Sat, Dec 14 2013 11:46 am
From: Mr Flibble
On 14/12/2013 16:35, Mr Flibble wrote:
> On 14/12/2013 11:05, Fab wrote:
>> Dear All,
>>
>> I am quite experienced with C++ but here's something I can't recall and
>> forgive me if I just don't recognize the (possible) simplicity of my
>> question.
>>
>> I have the following code
>>
>> // Custom comparator for pair,
>> // compares only by the first field
>> struct compare_first
>> {
>> template <typename T>
>> bool operator() (const T& a, const T& b)
>> {
>> return a.first < b.first;
>> }
>> };
>>
>> which is later used in a sort like this
>>
>> std::sort(cellid_particleid.begin(), cellid_particleid.end(),
>> compare_first());
>>
>> The sort orders a list of particles according to their cell ID. The
>> std::pair<unsigned int, unsigned int> contains cellID and particleID,
>> respectively.
>>
>> Since the operator() is templated in the comparator, why does my code
>> still compile? I assume the struct hides the templation, but is this
>> taken care of in std::sort then?
>
> It compiles because it is correct. The member function template will be
> instantiated by std::sort.
>
> The main reason why std::less takes its argument type as a class
> template parameter is because it needs to pass it on to what it derives
> from (std::binary_function).
Obviously that is not the only reason; the ability to specify the
argument type explicitly is also sometimes needed to avoid ambiguity.
/Flibble
==============================================================================
TOPIC: Native Aspect-oriented programming in C++
http://groups.google.com/group/comp.lang.c++/t/27f28eff7b33632c?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 14 2013 3:48 am
From: Dombo
On 11-Dec-13 23:34, David Brown wrote:
> Whether the actions of Alf (or anyone else here) is libel or not
> depends, I think, on whether comments really harm anyone's reputation.
> In Norway, we don't go in for trivial lawsuits - I think Alf is entirely
> safe from any legal action, and I doubt if any judge or jury will
> consider that reputations to be seriously harmed.
The only reputation Alf is harming is his own*. Imagine a potential
employer googling his name. No doubt the postings he made here will turn
up. What kind of impression will his postings leave of him?
> For my own part, I am not worried about my reputation, or that anyone
> else will pay much attention to Alf's killfile. And it is his choice to
> decide which posts he reads, and which he ignores. But it certainly is
> not pleasant to see one's name in a list of so-called trolls.
If it is any consolation; if someone has openly fallen out with so many
people (most of which are valued contributors) and feels the need to
publish that repeatedly, it is quite clear that the problem is not with
those people.
> And of course it makes things difficult in threads in which both Alf and
> I (or other "trolls") are involved. (As Chris said earlier, there are
> no doubts about Alf's C++ experience, knowledge and willingness to help
> and advise, so his contributions to threads are valued.)
Alf is also sometimes wrong (just like me, you and everyone else). One
of the benefits of a medium like usenet is that one can be corrected by
others to the benefit of us all. Alf's extremely strong tendency to
resort to personal attacks rather than engaging in a civilized
discussion stands in the way of this, and that is IMHO detrimental to
this group.
*I'm assuming here he is posting using his own name, rather than someone
else using his name to destroy his reputation.
==============================================================================
TOPIC: Available C++ Libraries FAQ
http://groups.google.com/group/comp.lang.c++/t/22a557c7fec86af9?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 14 2013 3:23 pm
From: Nikki Locke
Available C++ Libraries FAQ
URL: http://www.trumphurst.com/cpplibs/
This is a searchable list of libraries and utilities (both free
and commercial) available to C++ programmers.
If you know of a library which is not in the list, why not fill
in the form at http://www.trumphurst.com/cpplibs/cppsub.php
Maintainer: Nikki Locke cpplibs@trumphurst.com
==============================================================================
TOPIC: Want to debug this?
http://groups.google.com/group/comp.lang.c++/t/f3edd1f22042ccd4?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Dec 15 2013 9:31 am
From: woodbrian77@gmail.com
On Saturday, December 7, 2013 4:49:37 PM UTC-6, woodb...@gmail.com wrote:
>
> This is kind of pushing me towards
> moving to a newer OS. I think I've been on this
> version of the OS for over 5 months.
I wound up going to an older version of Linux in Debian.
I rebuilt all three tiers on Debian and tested them on
Debian. I couldn't reproduce the problem when running
on Debian.
Then I copied the Debian-built files to a Fedora machine
where I had originally encountered the problem. The
problem still occurred on Fedora. The Fedora machine
has an alpha or beta version of Fedora on it and my
guess is it has a TCP related bug.
== 2 of 3 ==
Date: Sun, Dec 15 2013 10:20 am
From: Geoff
On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
>On Saturday, December 7, 2013 4:49:37 PM UTC-6, woodb...@gmail.com wrote:
>>
>> This is kind of pushing me towards
>> moving to a newer OS. I think I've been on this
>> version of the OS for over 5 months.
>
>I wound up going to an older version of Linux in Debian.
>
>I rebuilt all three tiers on Debian and tested them on
>Debian. I couldn't reproduce the problem when running
>on Debian.
>
>Then I copied the Debian-built files to a Fedora machine
>where I had originally encountered the problem. The
>problem still occurred on Fedora. The Fedora machine
>has an alpha or beta version of Fedora on it and my
>guess is it has a TCP related bug.
Generally speaking, it's a Bad Idea(tm) to copy binaries from one
edition of Linux (Debian) to another (Fedora). The results are
unpredictable since they may not share a common ABI. It can be done
successfully but doing so while trying to "debug" your stated problem
is just adding another kind of potential error into the scenario.
Instead, you should copy your sources over and build your projects on
each platform. This is why package management exists.
"Alpha or beta" version is meaningless in this context. The current
stable supported release of Fedora is 19. Fedora 20 is available in
alpha and beta releases but why would you introduce yet another set of
problems into the mix?
In your original problem statement you also say you're using clang and
gcc projects. Why? If they share libraries you are running the risk of
ABI incompatibility again. Choose a tool (clang) and bring your
gcc-compiled project up to date and compile all your related projects
with the same tools.
== 3 of 3 ==
Date: Sun, Dec 15 2013 12:57 pm
From: Jorgen Grahn
On Sun, 2013-12-15, Geoff wrote:
> On Sun, 15 Dec 2013 09:31:17 -0800 (PST), woodbrian77@gmail.com wrote:
...
>>Then I copied the Debian-built files to a Fedora machine
>>where I had originally encountered the problem. The
>>problem still occurred on Fedora. The Fedora machine
>>has an alpha or beta version of Fedora on it and my
>>guess is it has a TCP related bug.
> Generally speaking, it's a Bad Idea(tm) to copy binaries from one
> edition of Linux (Debian) to another (Fedora). The results are
> unpredictable since they may not share a common ABI.
Are you reasonably sure about that? Any references?
The main burden of keeping things sane lies on the library writers.
When an incompatible version of e.g. the Gnu libc comes out, they must
step the .so file's revision number. (Somehow. The details are
unclear to me.) Then your program will fail to run unless the right
version of libc is available.
It's possible that Fedora takes libfoo version X from upstream and
modifies it so it's not compatible with the Debian build of libfoo
version X ... or modifies the compiler so that it generates such an
incompatibility. But that seems to me rather unlikely since it means
messing with the rather delicate upstream ABI decisions. If you're
Fedora, your can only switch ABIs when the upstream does it, and then
you're stuck with that decision until they release libfoo version X+1.
...
> Instead, you should copy your sources over and build your projects on
> each platform. This is why package management exists.
I agree that is the sane and normal way of doing it. And yes, that
also means I'm not sure you are wrong.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: Hope for your project - a little off topic.
http://groups.google.com/group/comp.lang.c++/t/e4b7c8315db7f411?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 15 2013 10:14 am
From: woodbrian77@gmail.com
On Friday, October 4, 2013 5:08:44 PM UTC-5, woodb...@gmail.com wrote:
> Also I'll pay someone $100 cash and give them a $200
> investment in my company if they help me find someone
> to work with. The company rewards investments to 3
> times their original amount. So you would receive
> anywhere from $0 to $600 on the investment part,
> depending on how things go for the company. I'll pay
> the $100 cash after working with whomever it is for 4
> months.
I'm happy to announce an increase here.
I'll pay $300 cash and give a $300 investment in my
company.
== 2 of 2 ==
Date: Sun, Dec 15 2013 10:39 am
From: Mr Flibble
On 15/12/2013 18:14, woodbrian77@gmail.com wrote:
> On Friday, October 4, 2013 5:08:44 PM UTC-5, woodb...@gmail.com wrote:
>> Also I'll pay someone $100 cash and give them a $200
>> investment in my company if they help me find someone
>> to work with. The company rewards investments to 3
>> times their original amount. So you would receive
>> anywhere from $0 to $600 on the investment part,
>> depending on how things go for the company. I'll pay
>> the $100 cash after working with whomever it is for 4
>> months.
>
> I'm happy to announce an increase here.
>
> I'll pay $300 cash and give a $300 investment in my
> company.
"Well that's a shit load of fucking bastard cunts" -- Paul Calf
http://www.youtube.com/watch?v=F-kfeyEzAT8
==============================================================================
TOPIC: My two string classes could be "templatized" into one, but for one
problem...
http://groups.google.com/group/comp.lang.c++/t/781a70fa362f1b0c?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 15 2013 12:54 pm
From: DSF
On Mon, 09 Dec 2013 00:52:07 -0500, DSF <notavalid@address.here>
wrote:
Hello group! A group answer for the group of responders.
Sorry I'm late responding. It's due to a few sick days and the fact
that converting the FStringX classes into a template wasn't as simple
as I thought and I had to go do some more research on templates. The
FStringX classes contained code I'd never tried to put in a template.
Also, I wanted to be sure it actually worked before responding.
First, I'd like to thank Paavo Helde, Robert Wessel and Tobias
M�ller for what turned out to be the best answer. Overload the string
functions.
To my credit, I would like to say I created the code below before
reading Paavo's post on the 10th. I dropped the d and replaced it
with a capital F to visually fit in better with the FString class.
Also, and this will cover Robert Wessel's comment about exporting the
dstr* series to a C program, the dstr* series and other string
manipulators are in a C library I've written. Useable for both
languages. About 80% of the library is written in x86 assembly, so
some kind of wrapper was necessary. (I suppose one could figure out
the name mangling and export C++ names in assembly code, but wrappers
are easier, cost nothing, and are more likely to be portable between
compilers on the same platform.)
This means I couldn't use Paavo's code from the tenth, because it
would break the UNICODE-defined A and W in the string library header.
Come to think of it, I could just #undef dstrlen and any others after
the header is included, then Paavo's method would work. But I think
I'll leave it as it is. It separates the C nomenclature from the C++.
Under the d'oh! category: I don't know if I just forgot it a long
time ago or whatever, but it never occurred to me that non-member
functions could be overloaded, too. It hasn't come up in my
programming. But now...
inline size_t Fstrlen(const char *str){return ::dstrlenA(str);}
inline size_t Fstrlen(const wchar_t *str){return ::dstrlenW(str);}
etc.
... I get the correct version for free! (No overhead!) The compiler
picks the correct FStrlen by parameter type and, with inlining,
Fstrlen(some_string); assembles to a direct call to the proper
dstrlen, A or W.
Problem solved. But to be thorough, answers to other questions.
As to Paavo Helde's question regarding:
// FStr being the template class
typedef FStr<char> FStringA;
typedef FStr<wchar_t> FStringW;
#ifdef UNICODE
#define UCFLAG
#undef UNICODE
Subscribe to:
Posts (Atom)