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
>
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment