Re: WEAK_REFERENCE?
On Wed, Nov 13, 2013 at 10:18:27PM +0100, Andreas Tobler wrote: > On 11.11.13 08:47, Konstantin Belousov wrote: > > On Sat, Nov 09, 2013 at 11:16:08PM +0100, Andreas Tobler wrote: > >> Hi all, > >> > >> anyone interested in this patch to remove the WEAK_ALIAS and introduce > >> the WEAK_REFERENCE? > >> > >> http://people.freebsd.org/~andreast/weak_ref.amd64.diff > >> > >> I have this running since months on amd64 and I have no issues with. > >> > >> I remember having had a communication with bde@ that he is in favour in > >> doing that but I lacked the time to complete. > >> A similar thing is pending for i386 and sparc64. The ppc stuff is > >> already committed since a longer time. > >> > >> If no one is interested, I'm happy to clean up my tree and skip this. > > > > I am not sure why do you include the changes to END() in the same patch. > > Did you looked over the all END() usages on amd64, is it always paired > > with ENTRY() ? The CNAME() for ELF is the pedantism anyway. > > > > Other than the somewhat questionable inclusion of the END() change, which > > should be committed separately, if ever, I think the change is fine. > > Am I correct, without this line in sys/amd64/include/asm.h? > > #define END(name) .size CNAME(name), . - CNAME(name) Yes. If committing it, please make separate commit. > > If so, I just need a usable dot.emacs file to match the formatting > expectations from bde. Sounds easy, but I didn't succeed so far. Nah, cannot be. Emacs source code has too many inconsistencies, the code does not follow its own style. I doubt Bruce would use it. pgpBq2r9sqNf3.pgp Description: PGP signature
CAM panic with tethered Virgin Mobile Mifi 2200
I've had a Virgin Mobile MiFi 2200 CDMA modem for a few years that I've successfully been using in tethered mode on my 8-STABLE laptop. The only issue is that I have to do a camcontrol eject to get it to switch from being a umass device to being a modem. Today I decided to try to add this device to usbdevices and u3g, with the U3GINIT_SCSIEJECT quirk so it would be more convenient to use. I plugged it into my 11-CURRENT machine to find it's ID. This showed up in /var/log/messages: Nov 13 16:42:16 scratch kernel: ugen2.2: at usbus2 Nov 13 16:42:16 scratch kernel: umass0: on usbus2 Nov 13 16:42:16 scratch kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 Nov 13 16:42:16 scratch kernel: umass0:9:0: Attached to scbus9 Nov 13 16:42:16 scratch kernel: cd0 at umass-sim0 bus 0 scbus9 target 0 lun 0 Nov 13 16:42:16 scratch kernel: cd0: Removable CD-ROM SCSI-2 device Nov 13 16:42:16 scratch kernel: cd0: Serial Number 09116664373 Nov 13 16:42:16 scratch kernel: cd0: 1.000MB/s transfers Nov 13 16:42:16 scratch kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present Nov 13 16:42:16 scratch kernel: cd0: quirks=0x10<10_BYTE_ONLY> Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:, (Reserved ASC/ASCQ pair) Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:, (Reserved ASC/ASCQ pair) Nov 13 16:42:17 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:, (Reserved ASC/ASCQ pair) Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:, (Reserved ASC/ASCQ pair) Nov 13 16:42:18 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:, (Reserved ASC/ASCQ pair) Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): Error 6, Retries exhausted Nov 13 16:42:19 scratch kernel: (cd0:umass-sim0:0:0:0): cddone: got error 0x6 back Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:, (Reserved ASC/ASCQ pair) Nov 13 16:42:20 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: Check Condition Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:, (Reserved ASC/ASCQ pair) Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): Retrying command (per sense data) Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 c8 00 00 00 01 00 Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): CAM status: SCSI Status Error Nov 13 16:42:21 scratch kernel: (cd0:umass-sim0:0:0:0): SCSI status: C
buildworld error on -current
Hi all, I have some problens with -current: building shared library librpcsvc.so.5 ===> lib/libsbuf (all) ===> lib/libtacplus (all) ===> lib/libutil (all) ===> lib/libypclnt (all) ===> lib/libcxxrt (all) ===> lib/libc++ (all) c++ -O2 -pipe -I/usr/src/lib/libc++/../../contrib/libc++/include -I/usr/src/li b/libc++/../../contrib/libcxxrt -nostdlib -DLIBCXXRT -Qunused-arguments -fstack- protector -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-un used-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -std=c++0x -Wno-c++11-extensions -c /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp -o algorithm.o In file included from /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: In file included from /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:627: /usr/src/lib/libc++/../../contrib/libc++/include/memory:3331:3: error: no matching literal operator for call to 'operator "" __len' with argument of type 'unsigned long long' or 'const char *', and no matching literal operator template 0__len = (__len - 1) & ~static_cast<_Size>(63); ^ 1 error generated. *** Error code 1 Stop. make[5]: stopped in /usr/src/lib/libc++ *** Error code 1 Stop. make[4]: stopped in /usr/src/lib *** Error code 1 And some ports not compile, as gnash vlc and others, and sound not work with some other multimidea softwares, like parole and xmms, with parole I can't change the default driver to OSS, and when I build this ports I tried use pulsealdio, Alsa and others supports but anyone work. Olny firefox can play some movies but not all my box: root@valfenda:/usr/src # uname -a FreeBSD valfenda 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r257602: Mon Nov 4 05:59:42 BRST 2013 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64 root@valfenda:/usr # svn info src Caminho: src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Raiz do Repositório: svn://svn.freebsd.org/base UUID do repositório: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revisão: 258094 Tipo de Nó: diretório Agendado: normal Autor da Última Mudança: emaste Revisão da Última Mudança: 258094 Data da Última Mudança: 2013-11-13 12:46:41 -0200 (Qua, 13 Nov 2013) TIA, Rizzo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WEAK_REFERENCE?
On 11.11.13 08:47, Konstantin Belousov wrote: > On Sat, Nov 09, 2013 at 11:16:08PM +0100, Andreas Tobler wrote: >> Hi all, >> >> anyone interested in this patch to remove the WEAK_ALIAS and introduce >> the WEAK_REFERENCE? >> >> http://people.freebsd.org/~andreast/weak_ref.amd64.diff >> >> I have this running since months on amd64 and I have no issues with. >> >> I remember having had a communication with bde@ that he is in favour in >> doing that but I lacked the time to complete. >> A similar thing is pending for i386 and sparc64. The ppc stuff is >> already committed since a longer time. >> >> If no one is interested, I'm happy to clean up my tree and skip this. > > I am not sure why do you include the changes to END() in the same patch. > Did you looked over the all END() usages on amd64, is it always paired > with ENTRY() ? The CNAME() for ELF is the pedantism anyway. > > Other than the somewhat questionable inclusion of the END() change, which > should be committed separately, if ever, I think the change is fine. Am I correct, without this line in sys/amd64/include/asm.h? #define END(name) .size CNAME(name), . - CNAME(name) If so, I just need a usable dot.emacs file to match the formatting expectations from bde. Sounds easy, but I didn't succeed so far. Thank you for the feedback! Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: new Xorg (KMS, etc.) for Radeon 9600
Le 10/11/2013 18:20, d...@gmx.com a écrit : drmn0: info: GTT: 0M 0xF000 - 0xEFFF Tijl Coosemans is right, the problem is this line. As I don't really now how AGP works and have no AGP hardware to reproduce the problem, can you post the output of the following commands as a start? pciconf -lvbce devinfo -vr Thanks! -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libc++ vs. libstdc++ usage in the ports tree
On 13 Nov 2013, at 19:51, Andriy Gapon wrote: > on 13/11/2013 19:52 Ryan Stone said the following: >> In my experience libstdc++ does not have good ABI stability between versions > > In my experience it does. > In either case compatibility between different versions of relatively modern > libstdc++ version is no doubt much better than between libstdc++ and libc++. Well, GNU libstdc++ is backwards compatible, so you can run programs originally linked against our 4.2.1 version of libstdc++.so, using the latest ports version of libstdc++.so, and they should work. (Not vice versa, but that is not a supported use case.) On the other hand, different C++ standard libraries simply cannot be mixed. The internal implementations are usually completely different. This is not really news at all, certainly not to the ports people. :-) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: libc++ vs. libstdc++ usage in the ports tree
on 13/11/2013 19:52 Ryan Stone said the following: > In my experience libstdc++ does not have good ABI stability between versions In my experience it does. In either case compatibility between different versions of relatively modern libstdc++ version is no doubt much better than between libstdc++ and libc++. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
On Wed, Nov 13, 2013 at 12:52:16PM -0500, Ryan Stone wrote: > On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen wrote: > > This brings up another point into which I am running with the previously > > discussed blender issue. > > > > Let's assume port A_defcompiler does not specify a compiler and c++ lib, it > > will default to libc++ and clang++ on 10.x or newer, correct? > > If now a port B_gnuish depends on port A_defcompiler, but at the same > > defines > > GCC + libstdc++, the resulting binary might link against libc++ and > > libstdc++ > > at the same time. This in turn makes the port unusable. The same applies > > to the other way around. > > > > Right now we do not have mechanism to detect and handle those flaws. > > Maintainers > > might be even less aware of those issues. Does anyone know a proper way to > > deal > > with this at the moment on 10.x+ or is this something that was missed until > > now? > > How different is this from the previous situation? As I understand it > previously A_defcompiler would be linked against the system libstdc++ > and B_gnuish would be linked against the gccXX port libstdc++. In my > experience libstdc++ does not have good ABI stability between versions > so shouldn't you have the same potential for problems? I haven't seen a problem with mixing the system's libstdc++ with a version from lang/gcc46. I can assure you that the problem is very really with libc++ vs libstdc++ within the ports collection. To getting working news/pan and math/octave, I had to recompile graphics/graphite2, graphics/libGL, graphics/libGLU, and x11-toolkits/fltk with "USE_GCC=any" to avoid the conflict. Fortunately, I have only another 360 installed ports to check for the conflict. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
On Wed, Nov 13, 2013 at 7:59 PM, George Kontostanos wrote: > On Tue, Nov 12, 2013 at 1:13 PM, Erwin Lansing wrote: > >> On Wed, Nov 06, 2013 at 02:59:15PM +0100, Erwin Lansing wrote: >> > >> E> > >> > >> E> > Erwin, can you please handle that? >> > >> E> >> > >> E> Things are much worse that this, the ports are completely written >> under the assumption that there is a Bind in base, which of course would >> already break with WITHOUT_BIND before Bind was completely removed. It >> will be hard to fix without breaking the installed base of 8 and 9. Sigh. >> > >> E> >> > >> E> I'll try to work on it this week, but unfortunately have a full >> schedule of meetings and travel as well. >> > > >> > > Suggestion. An option to install the rc script would solve that >> problem. >> > > >> > >> > If only it was that simple, it would have been done a long time ago. >> As Gleb points out, the ports are broken by design. The rc script needs a >> complete rewrite, and that's only after fixing all configuration files, >> setting up chroot, etc etc and all that while not breaking the installed >> base on 8 and 9. I spent most of yesterday on this and if I'm lucky, I'm >> halfway through. >> > >> >> >> Sorry about the delay, but I did finally update all three dns/bind9* >> ports today. I have dropped the complicated chroot, and related >> symlinking, logic from the default rc script as I don't think that >> is the right place to implement things. I would recommend users >> who want the extra security to use jail(8) instead of a mere chroot. >> >> This change should not affect the installed base of FreeBSD 9.x and >> earlier systems, but new installations there should note that the >> symlink option is no longer turned on by default, but still supported. >> >> I tested some default cases, but by no means can test every corner case, >> so please let me know how this works out. >> >> Best, >> Erwin >> >> > Excellent thanks so much! > > If you had named running using the old rc scripts and config in 10 you > will need to: > > 1) Backup your zones & stop named > 2) Delete /var/named/* > 3) Create a new symlink in etc to /usr/local/etc/namedb > 4) Restore your zones > 5) Start named from the new rc script > > Sorry I forgot also that if if you don't specify the location of named in the rc.conf: named_program="/usr/local/sbin/named" You will get an error message: root@hp:/etc # /usr/local/etc/rc.d/named start /usr/local/etc/rc.d/named: WARNING: run_rc_command: cannot run /usr/sbin/named Those are observations from a test machine that I use which was running bind with the old rc style. Thanks -- George Kontostanos --- http://www.aisecure.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf
On Tue, Nov 12, 2013 at 1:13 PM, Erwin Lansing wrote: > On Wed, Nov 06, 2013 at 02:59:15PM +0100, Erwin Lansing wrote: > > >> E> > > > >> E> > Erwin, can you please handle that? > > >> E> > > >> E> Things are much worse that this, the ports are completely written > under the assumption that there is a Bind in base, which of course would > already break with WITHOUT_BIND before Bind was completely removed. It > will be hard to fix without breaking the installed base of 8 and 9. Sigh. > > >> E> > > >> E> I'll try to work on it this week, but unfortunately have a full > schedule of meetings and travel as well. > > > > > > Suggestion. An option to install the rc script would solve that > problem. > > > > > > > If only it was that simple, it would have been done a long time ago. As > Gleb points out, the ports are broken by design. The rc script needs a > complete rewrite, and that's only after fixing all configuration files, > setting up chroot, etc etc and all that while not breaking the installed > base on 8 and 9. I spent most of yesterday on this and if I'm lucky, I'm > halfway through. > > > > > Sorry about the delay, but I did finally update all three dns/bind9* > ports today. I have dropped the complicated chroot, and related > symlinking, logic from the default rc script as I don't think that > is the right place to implement things. I would recommend users > who want the extra security to use jail(8) instead of a mere chroot. > > This change should not affect the installed base of FreeBSD 9.x and > earlier systems, but new installations there should note that the > symlink option is no longer turned on by default, but still supported. > > I tested some default cases, but by no means can test every corner case, > so please let me know how this works out. > > Best, > Erwin > > Excellent thanks so much! If you had named running using the old rc scripts and config in 10 you will need to: 1) Backup your zones & stop named 2) Delete /var/named/* 3) Create a new symlink in etc to /usr/local/etc/namedb 4) Restore your zones 5) Start named from the new rc script -- George Kontostanos --- http://www.aisecure.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen wrote: > This brings up another point into which I am running with the previously > discussed blender issue. > > Let's assume port A_defcompiler does not specify a compiler and c++ lib, it > will default to libc++ and clang++ on 10.x or newer, correct? > If now a port B_gnuish depends on port A_defcompiler, but at the same > defines > GCC + libstdc++, the resulting binary might link against libc++ and > libstdc++ > at the same time. This in turn makes the port unusable. The same applies > to the other way around. > > Right now we do not have mechanism to detect and handle those flaws. > Maintainers > might be even less aware of those issues. Does anyone know a proper way to > deal > with this at the moment on 10.x+ or is this something that was missed until > now? How different is this from the previous situation? As I understand it previously A_defcompiler would be linked against the system libstdc++ and B_gnuish would be linked against the gccXX port libstdc++. In my experience libstdc++ does not have good ABI stability between versions so shouldn't you have the same potential for problems? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
https://wiki.freebsd.org/NewC++Stack says things about linking against both libc++ and libstdc++ , do they still apply? Best regards Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
Steve Kargl : [...] Sigh. Adding USE_GCC isn't the solution. % pan Segmentation fault (core dumped) % ldd /usr/local/bin/pan | grep ++ libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000) libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000) This can't be good. And, unfortunately, testing math/octave shows no better :( % octave Segmentation fault (core dumped) % ldd /usr/local/bin/octave-3.6.4 | grep ++ libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) This brings up another point into which I am running with the previously discussed blender issue. Let's assume port A_defcompiler does not specify a compiler and c++ lib, it will default to libc++ and clang++ on 10.x or newer, correct? If now a port B_gnuish depends on port A_defcompiler, but at the same defines GCC + libstdc++, the resulting binary might link against libc++ and libstdc++ at the same time. This in turn makes the port unusable. The same applies to the other way around. Right now we do not have mechanism to detect and handle those flaws. Maintainers might be even less aware of those issues. Does anyone know a proper way to deal with this at the moment on 10.x+ or is this something that was missed until now? Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Wed, Nov 13, 2013 at 9:51 AM, Zhihao Yuan wrote:
>> An implementation of the vector class might allocate all of the elements on
>> the heap lazily, but it's not required to and could equally have space for a
>> small number inside the object, expanding to something like this:
>>
>> struct Entry {
>>struct MangledNameOfVectorOfEntry {
>> size_t size;
>> Entry small[4];
>> Entry *ptr;
>>};
>> };
>
> If you don't learn C++, then just don't make claims like these. If I can
> not recursively declare std::array, which is totally allocated on
> stack with layout exactly same as T[N], I would say this implementation
> is mad.
Sorry, this part is wrong. Stack allocation does require complete type.
> A deque is more akin to an array, so in C it would be something like:
> [...]
> This is clearly nonsense - you can't have a structure that contains itself.
> [...]
These part has nothing to do with C++.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Wed, Nov 13, 2013 at 2:29 AM, Shane Ambler wrote: > A possible solution I found looking into this is to wrap the Entry > reference in a std::unique_ptr - so changing - > std::deque messages; > to - > std::deque> messages; This "fix" is wrong. (Smart) pointers of T have comparison behaviors different from T itself, so this may silently change a program's runtime behavior. A better fix is to use `std::deque>`. Both libstdc++ and libc++ support vector, and vector's comparison behavior is as same as T. And of course,they both have value semantics. -- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On Wed, Nov 13, 2013 at 5:04 AM, David Chisnall wrote:
> A deque is more akin to an array, so in C it would be something like:
> [...]
> This is clearly nonsense - you can't have a structure that contains itself.
> [...]
> An implementation of the vector class might allocate all of the elements on
> the heap lazily, but it's not required to and could equally have space for a
> small number inside the object, expanding to something like this:
>
> struct Entry {
>struct MangledNameOfVectorOfEntry {
> size_t size;
> Entry small[4];
> Entry *ptr;
>};
> };
If you don't learn C++, then just don't make claims like these. If I can
not recursively declare std::array, which is totally allocated on
stack with layout exactly same as T[N], I would say this implementation
is mad.
> It would make sense to have a std:deque or std:deque, because
> then you're only storing references or pointers to the outer structure in the
> inner structure.
It makes no sense, since you switched from value semantics to
reference semantics.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Are clang++ and libc++ compatible?
On 12 Nov 2013, at 18:21, John Baldwin wrote:
>> struct foo {
>> struct foo bar;
>> }
>
> Except it isn't. It's declaring the head of a container. This is more
> like:
>
> struct foo {
> TAILQ_HEAD(, foo) messages;
> };
Eitan is correct here. The definition of std::deque is that it copies the
value that is the template argument and does not require modifications to the
layout. A deque is more akin to an array, so in C it would be something like:
struct foo {
struct foo bar[10];
};
This is clearly nonsense - you can't have a structure that contains itself.
The same is true for the deque. It's not clear what the pan people actually
wanted, but an efficient implementation of a deque would most likely contain
space for a small number of the template argument elements, so they are
literally defining a structure containing a structure containing the parent
structure. The same would be true if they did:
struct Entry {
std::vector v;
};
An implementation of the vector class might allocate all of the elements on the
heap lazily, but it's not required to and could equally have space for a small
number inside the object, expanding to something like this:
struct Entry {
struct MangledNameOfVectorOfEntry {
size_t size;
Entry small[4];
Entry *ptr;
};
};
It would make sense to have a std:deque or std:deque, because
then you're only storing references or pointers to the outer structure in the
inner structure.
David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
