http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* isspace - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/89ca303518428e34?hl=en
* Incomplete types and std::vector - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/b0741c38fc15b5f7?hl=en
* ordered unordered_map - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/3743266d80703cfb?hl=en
* Static member vs global variable - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/39598a6a81930f50?hl=en
* change function - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/98d241e38cad9662?hl=en
* system("ls") - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ea8887c99b1a8b02?hl=en
* multiset unique values count - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b66513ea50fac61b?hl=en
==============================================================================
TOPIC: isspace
http://groups.google.com/group/comp.lang.c++/t/89ca303518428e34?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 1:02 pm
From: Paavo Helde
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote in
news:slrnhmiei6.1qf.grahn+nntp@frailea.sa.invalid:
> On Fri, 2010-01-29, Paavo Helde wrote:
> ...
>> Or I could keep the text in UTF-8 and use my own custom function for
>> checking for the whitespace, checking directly for all Unicode
>> whitespace characters as listed in
>> http://en.wikipedia.org/wiki/Whitespace_% 28computer_science%29, this
>> seems to me much less error-prone than worrying if Russian locale and
>> std::isspace are working correctly on all platforms.
>
> Worrying? "I don't support doing analysis of Russian text on a
> platform with broken Russian locales" sounds like something you can
> happily say.
Happily to who? My boss? Or the customer? (Happily I myself don't have any
of those problems, the only locale I have needed so far is "C", to override
strange formatting caused by default locales. Everything is just working in
UTF-8.).
BTW, Windows is supporting Russian locales quite well, I believe. The
problem is that it does not support locales with UTF-8 encodings (which are
the only ones which make sense in my (limited) experience).
Cheers
Paavo
==============================================================================
TOPIC: Incomplete types and std::vector
http://groups.google.com/group/comp.lang.c++/t/b0741c38fc15b5f7?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 1:34 pm
From: Joshua Maurice
On Feb 3, 12:51 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * James Kanze:
>
> > On Feb 2, 11:25 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> >> On Feb 2, 2:30 pm, James Kanze <james.ka...@gmail.com> wrote:
> >>> On Feb 2, 9:34 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > [...]
> >> Could you explain this to me then? Why was it ever allowed to
> >> delete a pointer to an incomplete type?
>
> > No, I can't explain it. It seems as incongruous to me as it
> > does to you. IMHO, it should be an error, requiring a
> > diagnostic.
>
> 'delete p' where *p is of statically incomplete type T is Undefined Behavior if
> T has a non-trivial destructor or deallocation function, by §5.3.5/5.
>
> 'delete p' where *p is of static type 'void' is Undefined Behavior by §5.3.5/3,
> since there are no actual objects of type 'void'.
>
> There's even a note explaning that particular consequence.
That's the rule. I'm asking why was that ever chosen to be the rule.
Currently, for delete *p, if *p is a complete non-void type with a
trivial destructor and trivial deallocation function, then it's
defined behavior. Otherwise it's undefined behavior. I argue that all
cases of delete *p, where *p is void type or an incomplete type,
should be "diagnostic required". I don't see any good reason for
anything different. The current rules in the standard border on brain
damaged.
== 2 of 2 ==
Date: Wed, Feb 3 2010 1:59 pm
From: "Leigh Johnston"
>> I
>> asked a question elsewhere about the status of auto_ptr. It seems to be
>> quite common to use auto_ptr to implement the pimpl idiom.
>
> Does it? My thoughts here are: why bother. You still need an
> out of line destructor, and if you have to write a destructor
> anyway, what's the problem with putting a delete in it, and
> using a raw pointer. The whole point of the compilation
> firewall idiom is to reduce include file dependencies, and any
> smart pointer will require at least one extra include file.
>
You need both an out of line constructor and destructor. Using auto_ptr for
pimpl does in fact reduce file dependencies which is exactly why I do it.
The translation unit containing the ctor and dtor of the class containing
the pimpl will have access to the complete type.
Read Herb Sutter's
http://www.gotw.ca/publications/using_auto_ptr_effectively.htm it advocates
using auto_ptr for pimpl. I use auto_ptr for pimpl but I will change it to
use unique_ptr when I get a C++0x compiler. Yes I am aware that it is
"officially" undefined behaviour to use auto_ptr for pimpl. The only reason
it remains so in C++0x is that auto_ptr has been deprecated as far as I can
tell.
/Leigh
==============================================================================
TOPIC: ordered unordered_map
http://groups.google.com/group/comp.lang.c++/t/3743266d80703cfb?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 5:38 pm
From: tonydee
On Feb 3, 9:27 pm, Ralf Goertz <r_goe...@usenet.arcornews.de> wrote:
> tonydee wrote:
> > On Feb 2, 10:30 pm, Ralf Goertz <r_goe...@usenet.arcornews.de> wrote:
> >> Pete Becker wrote:
>
> >> > If you're willing to reorganize the container, how about going a small
> >> > step further and replacing it at that point with an ordered container?
>
> >> It seems I will have to do that then, thanks.
>
> > It's a good, simple solution in most cases. If the objects are large
> > and keys small and your RAM limited, and/or that final step is
> > performance critical too, consider
> > - keeping the data in an ordered map, but adding an unordered (hash)
> > map indexing from key to ordered-map iterator
> > - keep the data in a vector, and having unordered and ordered maps
> > from key to index
> > - looking at boost's multi-indexed container library, which can manage
> > the synchronisation of data and indices for you
>
> These are worth trying, especially since I still need to find() in the
> map. The reason why I want an ordered iterator is that I'd like to
> compare all elements with each other and erase duplicate (type Foo)
> values keeping the one with the lower (type unsigned) key (it is more
> complicated than that but you get the point). So I use two nested loops:
>
> typedef unordered_map<unsigned, Foo> Map;
> typedef unordered_set<unsigned> Set;
> Map m;
> Map::iterator i1,i2;
> Set s;
> Set::iterator i3;
>
> void find_elements_in_m_that_need_to_be_compared(unsigned to_this_element,Set&);
>
> bool foo_equal(const Foo &,const Foo&);
>
> for (i1=m.begin();i1!=m.end();++i1) {
> find_elements_in_m_that_need_to_be_compared(i1->first,s);
> for (i3=s.begin();i3!=s.end();++i3) {
> i2=m.find(*i3);
> if (foo_equal(i1->second,i2->second)) {
> m.erase(i2); // (*)
> }
> }
>
> }
>
> Since m is not ordered, I cannot be sure that i1->first is less than
> i2->first. Therefore I might erase the object with the lower key at (*).
> OTOH unordered_map has an erase(iterator, iterator) member function.
> This function seems to be of little use since the key 42 might be in the
> range [8,15).
I'm not sure how often you need to "clean up" these duplicates, but if
Foo has (or can easily be given) a operator<, you may find it better
to have an (ordered) map (something like "std::map<Foo*, unsigned,
Compare_Via_Ptr<Foo*> >" with template <typename T> struct
Compare_Via_Ptr { bool operator()(const Foo* lhs, const Foo* rhs)
const { return *lhs < *rhs; } }; )...
That way you can do a quick lookup to see if an "incoming" Foo is
already stored, preventing the storage of duplicates.
Cheers,
Tony
==============================================================================
TOPIC: Static member vs global variable
http://groups.google.com/group/comp.lang.c++/t/39598a6a81930f50?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 5:51 pm
From: tonydee
> On Feb 4, 5:45 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Feb 3, 3:27 pm, Suneel VLN <suneelsuns...@gmail.com> wrote:
> > > On Feb 3, 11:00 am, Rolf Magnus <ramag...@t-online.de> wrote:
> > > > For objects with static storage duration, there are two
> > > > types of initialization, static and dynamic. static
> > > > initialization is done before dynamic initialization
> > > in such case during static initialization will y be initialized to 0?
> > I don't think the Standard guarantees that...
> It does, and several frequently used programming idioms depend
on it.
Thanks for the correction. Sorry for the misinformation.
On Feb 4, 5:45 am, James Kanze <james.ka...@gmail.com> wrote:
> On Feb 3, 6:43 am, tonydee <tony_in_da...@yahoo.co.uk> wrote:
> > my recollection is compilers are free to use
> > uninitialised/reclaimed memory for static variables that are
> > to be dynamically initialised.
>
> They certainly can't use reclaimed memory, since the object must
> be present for the entire lifetime of the program.
I was thinking at the level of the OS allocating the memory for the
processes it's loading... the memory is reclaimed from other processes
or system caches and allocated to the loading process. Poor wording
if it's put you in mind of the intra-process heap.
> > That would seem more efficient - why initialise something
> > twice?
> On Feb 4, 5:45 am, James Kanze <james.ka...@gmail.com> wrote:
> Maybe because the first initialization is for all intents and
> purposes free.
memset() is pretty fast, and better OSs tend to do it anyway for
security reasons, but acceptable performance is very context
dependent.
> On Feb 4, 5:45 am, James Kanze <james.ka...@gmail.com> wrote:
> And because it might be useful to be able to
> tell whether an object is initialized or not---objects with
> static lifetime are about the only objects which can be accessed
> normally before their constructor has run.
Very true, and stupid of me for not reasoning from those uses.
Cheers,
Tony
==============================================================================
TOPIC: change function
http://groups.google.com/group/comp.lang.c++/t/98d241e38cad9662?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 5:58 pm
From: tonydee
On Jan 30, 7:14 am, "Larry" <dontmewit...@got.it> wrote:
> Hi,
>
> I would like to turn this function:
>
> std::string Socket::ReceiveBytes() {
> std::string ret;
> char buf[1024];
>
> while (1) {
> u_long arg = 0;
> if (ioctlsocket(s_, FIONREAD, &arg) != 0)
> break;
>
> if (arg == 0)
> break;
>
> if (arg > 1024) arg = 1024;
>
> int rv = recv (s_, buf, arg, 0);
> if (rv <= 0) break;
>
> std::string t;
>
> t.assign (buf, rv);
> ret += t;
> }
>
> return ret;
>
> }
>
> into something like:
>
> bool Socket::ReceiveBytes(char * buffer, const int buffersize);
>
> how should I change it internally?
>
> thanks
I think you're making this a lot more complicated than it need be.
The existing recv() or read() functions provide almost this interface
already. If you want to avoid them blocking when no input is
available, set the socket to nonblocking mode before calling them -
you only need do that once instead of checking before every recv().
Cheers,
Tony
==============================================================================
TOPIC: system("ls")
http://groups.google.com/group/comp.lang.c++/t/ea8887c99b1a8b02?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 6:08 pm
From: tonydee
On Jan 22, 6:29 am, "Default User" <defaultuse...@yahoo.com> wrote:
> jl_p...@hotmail.com wrote:
> > On Jan 21, 1:07 pm, Matko <mkl...@foi.hr> wrote:
> > I know of no standard C++-specific way of doing this, but I do know
> > you can use the C functions opendir() and readdir() to do this.
>
> No you don't, because there are no such C functions. There are POSIX
> functions of those names. The fact that the OP is asking about ls makes
> it a good chance those would work.
>
> Brian
Bit harsh! It's fair to call them C functions, as while they're not
be part of the C Standard, they are written in C, and that in itself
is significant as a way of saying you won't get any nice C++-specific
usage conventions....
Back to the main topic - opendir()/readdir() are a good solid
"professional" solution. For the record, the most direct realisation
of Matko (the OP)'s system("ls") is through popen(), which allows the
results of the real "ls" to be read and parsed....
Cheers,
Tony
==============================================================================
TOPIC: multiset unique values count
http://groups.google.com/group/comp.lang.c++/t/b66513ea50fac61b?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Feb 4 2010 12:09 am
From: dushkin
Hi
I wish someone can give a tip on this one..
http://groups.google.co.il/group/comp.lang.c++/browse_thread/thread/1da69b779019d7c4/d060bace91a1830?hl=iw&ie=UTF-8&oe=utf-8&q=multiset+unique+elements+counting#0d060bace91a1830
Thanks!
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment