http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Bitwise 2010 ( IIT Kharagpur ) An Annual Algorithm Intensive Online
Programing Contest - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/49fa14c702c63327?hl=en
* isspace - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/89ca303518428e34?hl=en
* Another strange linux kernel change - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/e05a4158a9750a03?hl=en
* Avoiding pointers to member functions - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/91122aae5ea3693a?hl=en
* C++ Workshop Announcement from the NYLUG and NYLXS Mailing Lists - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/5899d52668535101?hl=en
* Advice on using templates and vector to improve exception handling - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/36f052e700775e41?hl=en
* Safe to use substr? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/cece8bdad80abdbe?hl=en
* ===Welcome to comp.lang.c++! Read this first. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/8359863cfafcc5aa?hl=en
==============================================================================
TOPIC: Bitwise 2010 ( IIT Kharagpur ) An Annual Algorithm Intensive Online
Programing Contest
http://groups.google.com/group/comp.lang.c++/t/49fa14c702c63327?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 30 2010 1:32 pm
From: "Bitwise 2010 "
Bitwise is an Annual Algorithm Intensive Online Programming Contest,
organized by the Department of Computer Science and Engineering,
Indian Institute of Technology Kharagpur (IIT Kgp), one of the premier
institutes of technology in India. Bitwise has earned its position
over the years and the last edition held in Februrary 2009 saw 3000
participants from over 50 countries !
The contest will be held on the 14th February, 2010, for a period of
12 hours. Algorithm intensive programming problems will be put up on
our website and the participants would be expected to code their
solutions in C/C++, and submit them online. The solutions will be
evaluated at real time and the results will be communicated to the
participants. The contest presents a great way to showcase your
individual talent at an international scale and benchmark against the
best in the world. At the same time, solving the challenging problems
is a lot of fun! And the cash incentives are definitely attractive!
Registration for the event is now on. You can register for the event
at our website.
http://www.bitwise.iitkgp.ernet.in
You can also participate in Enigma, our unique online quiz, an
integral part of Bitwise since 2007, which presents an impeccable set
of twisted questions designed to tantalize your brain. Enigma 2010, is
now on and presents Enigma in its new avatar at,
http://www.bitwise.iitkgp.ernet.in/enigma_thegame .
We look forward to your participation in Bitwise 2010. Good luck!
Regards,
Team Bitwise 2010
==============================================================================
TOPIC: isspace
http://groups.google.com/group/comp.lang.c++/t/89ca303518428e34?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 30 2010 1:34 pm
From: gervaz
On Jan 30, 1:15 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Jan 30, 12:05 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
> > James Kanze <james.ka...@gmail.com> writes:
> > >There are no standard names for locales
> > AFAIK, C90 defines a locale by the name of "C",
> > which should also be visible from C++.
>
> And Posix defines "POSIX". Neither of which are really useful
> for anything.
>
> --
> James Kanze
Ok, so I think that I will open my file specifying to use UTF-8
encoding, but how can I do it in C++?
==============================================================================
TOPIC: Another strange linux kernel change
http://groups.google.com/group/comp.lang.c++/t/e05a4158a9750a03?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 30 2010 2:12 pm
From: Daniel Giaimo
On 1/30/2010 5:38 AM, Man-wai Chang to The Door (24000bps) wrote:
>> i++ increments i and returns the old value. ++i increments i and
>> returns the new value. So, for example, if i were 4 to begin with,
>> then before the change the code would cause i to become 5 and j to
>> become 4, and after the change the code would cause i to become 5
>> and j to become 5.
>
> I understood pre- and post-increment. But that line does not really
> affect anything critical.
>
Maybe you know more about the pre-conditions satisfied when this
particular piece of code is run, but from reading just what you posted
j is used on the very next line, so I would assume it matters whether
it starts at i or i+1.
--
Dan G
==============================================================================
TOPIC: Avoiding pointers to member functions
http://groups.google.com/group/comp.lang.c++/t/91122aae5ea3693a?hl=en
==============================================================================
== 1 of 3 ==
Date: Sat, Jan 30 2010 3:12 pm
From: Robert Fendt
And thus spake ram@zedat.fu-berlin.de (Stefan Ram)
30 Jan 2010 19:49:50 GMT:
> I assume, you want to make the behavior of an instance
> of a class to be changeable at run-time. ¯¯¯¯¯¯¯¯
Yes. Sorry for being not precise on that matter. Since a class is a type and since types are not first-class entities in C++, strictly speaking one cannot change the behaviour of a class at runtime at all, always and only of its instances (this is true even for static members, which some people call 'class members').
> The usual solution to do this, is to make the behavior
> depending on some state. Then, by changing this state
> (which can be done at run-time), the behavior of the
> object can be adjusted.
I do know the concept of member variables reflecting the state of an object. The question was more or less about what design is the best compromise between performance and elegance in order to achieve a specific kind of behaviour change. That said, and since performance really _is_ a problem in the context, there most probably is no really 'elegant' solution, and the least ugly one seems to be sticking with the member function pointer after all. Thanks anyway for taking the time, I really appreciate it.
Regards,
Robert
== 2 of 3 ==
Date: Sat, Jan 30 2010 3:23 pm
From: Robert Fendt
And thus spake "BGB / cr88192" <cr88192@hotmail.com>
Sat, 30 Jan 2010 13:37:18 -0700:
> 1, is the most direct and also gives the best performance FWIW.
>
> anyways, the syntax is not THAT horrible, and really, if it does seem that
> bad, one can always "typedef" the function-pointer, making it look about
> like a normal field...
>
> anyways, the syntax for normal function pointers is still far less ugly than
> when one is passing or returning function pointers... (maybe stop for a
> second to imagine the declaration of a function accepting a function pointer
> and returning another function pointer...).
Yes, passing function pointers around is where the nasty really starts. Just switching stored pointers is something akin to virtual functions, in a way (just not as flexible, but more light-weight). You are right, one can use them at least in a semi-clean way, so I think I will stick with them.
> there is always the option of using object fields and switch statements (to
> re-dispatch to other methods), which has both good and bad points...
The switch statement pattern is of course always an option. But before I do that, I think I will stick with the member function pointer. It is a little bit faster _and_ more readable; performance really is an issue at that point, since the function in question will be run as part of an image transformation loop. So yes, I am willing to sacrifice a bit of cleanliness in the design if it yields significant speed advantages. But using switches does not look very beneficial from both the performance and the design points of view.
Regards,
Robert
== 3 of 3 ==
Date: Sat, Jan 30 2010 4:31 pm
From: "BGB / cr88192"
"Robert Fendt" <robert@fendt.net> wrote in message
news:20100131002313.6cc96dc6@vulcan.local...
> And thus spake "BGB / cr88192" <cr88192@hotmail.com>
> Sat, 30 Jan 2010 13:37:18 -0700:
>
>> 1, is the most direct and also gives the best performance FWIW.
>>
>> anyways, the syntax is not THAT horrible, and really, if it does seem
>> that
>> bad, one can always "typedef" the function-pointer, making it look about
>> like a normal field...
>>
>> anyways, the syntax for normal function pointers is still far less ugly
>> than
>> when one is passing or returning function pointers... (maybe stop for a
>> second to imagine the declaration of a function accepting a function
>> pointer
>> and returning another function pointer...).
>
> Yes, passing function pointers around is where the nasty really starts.
> Just switching stored pointers is something akin to virtual functions, in
> a way (just not as flexible, but more light-weight). You are right, one
> can use them at least in a semi-clean way, so I think I will stick with
> them.
>
yep.
>> there is always the option of using object fields and switch statements
>> (to
>> re-dispatch to other methods), which has both good and bad points...
>
> The switch statement pattern is of course always an option. But before I
> do that, I think I will stick with the member function pointer. It is a
> little bit faster _and_ more readable; performance really is an issue at
> that point, since the function in question will be run as part of an image
> transformation loop. So yes, I am willing to sacrifice a bit of
> cleanliness in the design if it yields significant speed advantages. But
> using switches does not look very beneficial from both the performance and
> the design points of view.
>
yes, agreed...
I guess some people though really like the switches though, and I guess they
do a little better in cases where there are a number of possible states, but
little liklihood of dynamically adding any new states.
> Regards,
> Robert
==============================================================================
TOPIC: C++ Workshop Announcement from the NYLUG and NYLXS Mailing Lists
http://groups.google.com/group/comp.lang.c++/t/5899d52668535101?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 30 2010 5:46 pm
From: Ruben Safir
I'm considering working the C++ program in the following manner. I want
this to be a serious endeavor with commitment to learning. I hope to
initiate the first phase over 3 months. A full blown exploration of the
standard C++ language to include syntax, namespace, the standard
libraries, compilation, datatypes, memory management, Class structure and
Object design, scope, and a run down of the standard libraries, based
largely of the classic text, C++ Primer Stanley Lippman and Josee Lajoie,
The C++ Programming Language by Bjarne Stroustrup, as well as some C
programming as needed for supplementation, from Kings, C Programming: A
Modern Approach. Other books are welcome for additional materials as
needed as C++ texts tend to be wonderfully short on clarity on specific
language particulars.
I'm expecting to put out lecture size workshops 2 times a week, maybe
Mondays and Thursdays. They will be posted to the NYLUG mailing list,
NYLXS mailing list (hangout), to comp.lang.C++. I'll try to cross post
to all three mediums, and I'll be putting up edited versions of
everything at http://www.nylxs.com/docs/workshops/ . Sunday nights I
hope to meet with everyone on line on IRC on Freenode, #nylug during
normal Sunday night NYLXS technite events. Finally, I hope that we can
meet every two weeks in order to work together on code and
exercises...although admittedly, getting that done once a month might be
a more doable goal. Times and Places we will discuss and work out. We
might be able to dove tail this with the NYLUG workshop if they don't
view that as an invasion.
As a roadmap, after the first three months, I hope to move into studying
serious Unix based systems libraries, such as networking libraries, file
system libraries, unix sockets, and all that wonderful stuff many of us
know nothing about. Then I hope to spend a 6 months on the Linux Kernel
and Device drivers. I know that the Kernel is largely C and not C++ but
I think we can still pull this off, and after about 6 months of this, I
hope to move on to X11 libraries, and application building. Perhaps we
can touch GTK libraries, QT libraries after the core X11 set is
explored.
Its a lot of work and it takes a serous commitment. I tried to do this
once before and it failed on its face. So I'm hoping we can start this
up again with more success.
In my mind, it is very easy to get involved in one of the advanced
scripting languages in order to have fun, and even make a few bucks, but
everything always comes back to C and C++ for the kind of advanced work
and employment that separates the unemployed from the well employed in
times of recession.
Obviously, we will be using GCC, Make, Autoconf, and Tags and personally
I'll be using VIM, and I'll discuss it much at the beginning. No editor
wars. Use whatever editor you enjoy. I don't care. Just please don't
distract the program with a parallel track of study.
So who is still game? This kind of study could cost someone 10 grand at
NYU and you might never learn as much.
Ruben
==============================================================================
TOPIC: Advice on using templates and vector to improve exception handling
http://groups.google.com/group/comp.lang.c++/t/36f052e700775e41?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 30 2010 5:47 pm
From: Öö Tiib
On Jan 30, 2:06 am, jdm <james.d.mclaugh...@googlemail.com> wrote:
> Hi,
>
> I've been trying to improve on my program's exception handling, due to
> the amount of code duplication resulting from the following (not to
> mention the need to recode when the relevant data required five
> variables):
>
> struct three_long_int_misc_exception
> {
> std::string ident_string;
> long int err_number1, err_number2, err_number3;
> three_long_int_misc_exception(std::string i="Unknown exception
> (three_long_int_misc_exception).", long int x=0, long int y=0, long
> int z=0)
> {
> ident_string = i;
> err_number1 = x;
> err_number2 = y;
> err_number3 = z;
> }
>
> };
>
> struct three_unsigned_long_int_misc_exception
> {
> std::string ident_string;
> unsigned long int err_number1, err_number2, err_number3;
> three_unsigned_long_int_misc_exception(std::string i="Unknown
> exception (three_unsigned_long_int_misc_exception).", unsigned long
> int x=0, unsigned long int y=0, unsigned long int z=0)
> {
> ident_string = i;
> err_number1 = x;
> err_number2 = y;
> err_number3 = z;
> }
>
> };
>
> struct four_long_int_misc_exception
> {
> std::string ident_string;
> long int err_number1, err_number2, err_number3, err_number4;
> four_long_int_misc_exception(std::string i="Unknown exception
> (four_long_int_misc_exception).", long int w=0, long int x=0, long int
> y=0, long int z=0)
> {
> ident_string = i;
> err_number1 = w;
> err_number2 = x;
> err_number3 = y;
> err_number4 = z;
> }
>
> };
>
> (There were also structs for when the exception data consisted only of
> one or two ints.)
>
> Although the following was a bit more complicated to throw, it seemed
> a better idea:
>
> template <typename T> struct multiple_integer_misc_exception
> {
> std::string ident_string;
> std::vector<T> error_numbers;
>
> multiple_integer_misc_exception()
> {
> ident_string = "";
> error_numbers = std::vector<T>(1);
> error_numbers[0] = 0;
> }
>
> multiple_integer_misc_exception(std::vector<T>& v, std::string
> s="Unknown exception (multiple_integer_misc_exception).")
> {
> ident_string = s;
> error_numbers = std::vector<T>(v.size());
> for (int i=0; i < v.size(); i++)
> {
> error_numbers[i] = v[i];
> }
> }
>
> };
>
> However, this doesn't seem to eliminate much of the code duplication
> involved in catching the exceptions, as the main() function now needs
> to include:
>
> catch (multiple_integer_misc_exception<long int> lmime) //Is there a
> better way than these two almost identical catches?
> {
> std::cout<<'\n'<<lmime.ident_string<<'\t';
> for (int i=0; i<lmime.error_numbers.size(); i++)
> {
> std::cout<<lmime.error_numbers[i]<<' ';
> }
> std::cout<<std::endl;
> return 1;
> }
> catch (multiple_integer_misc_exception<unsigned long int> ulmime)
> {
> std::cout<<'\n'<<ulmime.ident_string<<'\t';
> for (int i=0; i<ulmime.error_numbers.size(); i++)
> {
> std::cout<<ulmime.error_numbers[i]<<' ';
> }
> std::cout<<std::endl;
> return 1;
> }
>
> Can anyone suggest a better way to do this?
Try to have not so lot of exception classes, templates or what not and
lot of complex data within your exceptions. Complex exceptions may
start to contain bugs of their own if you continue like that. The part
that did catch the exception has no much to do anyway. It can either
retry the operation it tried or accept that it failed.
What failed and reasons why it failed are usually displayed or logged
so string describing it is usually all what is needed. If the
explanations contain numeric data then that may be
std::stringstream'ed or boost::format'ed into the string as well.
Simplest is to derive your exceptions from std::exception. Override
the what() of your exceptions. Catch in main() will look like:
catch (std::exception& e)
{
std::cout << "Unrecoverable error: "
<< e.what()
<< std::endl;
return 1;
}
If there are numerous possible errors (like when parsing human-entered
text that must fulfill complex set of rules) then some sort of numeric
error-code may also help (to construct url to manual page about that
error). But this is already above common functionality of exceptions.
==============================================================================
TOPIC: Safe to use substr?
http://groups.google.com/group/comp.lang.c++/t/cece8bdad80abdbe?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 30 2010 6:49 pm
From: Immortal Nephi
I want to know that size_type returns –1 (minus one) is safe before I
extract one string into two substrings. First example is safe and
second example is not sure.
const basic_string <char>::size_type npos = -1;
basic_string< char >::size_type begin_index, end_index, length_index;
end_index = 0;
string data = "Hello World!!", token1, token2;
First example:
begin_index = data.find_first_not_of( " ", end_index );
end_index = data.find_first_of( " ", begin_index );
token1 = data.substr( begin_index, end_index - begin_index );
length_index = token1.length();
begin_index returns 0 and end_index returns 5. substr is safe.
Second example:
begin_index = data.find_first_not_of( " ", end_index );
end_index = data.find_first_of( " ", begin_index );
token2 = data.substr( begin_index, end_index - begin_index );
length_index = token2.length();
begin_index returns 6 and end_index returns –1. Is substr safe for
token2 because end_index returns –1 indicates space character is not
found.
Another question—is size_type the same as size_t? They are always
unsigned maximum integer. Can I always copy variable from size_type
to signed integer or unsigned integer?
const basic_string <char>::size_type npos = -1;
signed int sNpos = npos;
unsigned int uNpos = npos;
==============================================================================
TOPIC: ===Welcome to comp.lang.c++! Read this first.
http://groups.google.com/group/comp.lang.c++/t/8359863cfafcc5aa?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 30 2010 9:30 pm
From: Shiva
Welcome to comp.lang.c++! Read this first.
This post is intended to give the new reader an introduction to reading
and posting in this newsgroup. We respectfully request that you read
all the way through this post, as it helps make for a more pleasant
and useful group for everyone.
First of all, please keep in mind that comp.lang.c++ is a group for discussion
of general issues of the C++ programming language, as defined by the ANSI/ISO
language standard. If you have a problem that is specific to a particular system
or compiler, you are much more likely to get complete and accurate answers in a
group that specializes in your platform. A listing of some newsgroups is given
at the end of this post.
The FAQ (Frequently Asked Question) list has a wealth of information for
both the new and veteran C++ programmer. No matter what your experience
level, you are encouraged to read the entire list, if only to familiarize
yourself with what answers are available to minimize redundant replies.
The comp.lang.c++ FAQ is available at http://www.parashift.com/c++-faq-lite/
If the FAQ list does not help, then many regular readers of this group
are happy to assist with problems of standard C++. We have only a few
requests that we ask be adhered to, for the benefit of all:
* Please put a short summary in the subject line. Descriptions such as
"HELP!!!!!!" are not helpful, and many regular posters ignore such
requests. A good example is, "Problem with Virtual Functions."
* State the question or the problem clearly and concisely. Describe what
you are trying to do, and the problem you are running into. Include all
relevant error messages.
* Include the smallest, complete and compilable program that exhibits your
problem. As a rule, posters in comp.lang.c++ will not do homework, but will
give helpful hints if you have shown some willingness to try a solution.
* comp.lang.c++ is forum for discussion, and as such some regular posters do
not give E-mail replies. Very often follow-ups to postings have corrections,
so plan on taking part in the discussion if you post a question. If you
do receive e-mail replies, it is considered polite to post a summary.
* Don't post in HTML format. Many readers of this newsgroup don't use
newsreaders which can handle HTML postings.
* If you have to include source code in your post, include the
source in the message body. Don't use attachments. A lot
of contributors to this newsgroup won't even notice the existence
of attachments or won't open them. You try to get any help
you can get, don't you?
Some netiquette topics which frequently crop up on comp.lang.c++ are
also answered in the FAQ.
* Should I post job advertisements and/or resumes on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.10
* What if I really need a job; should I post my resume on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.11
* What should I do to someone who posts something off-topic?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12
A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.
This is a very busy group, so these requests are designed to make it as
pleasant and efficient an experience as possible. We hope it proves
a valuable commodity to you.
A list of some Newsgroups :
Languages and Programming
-------------------------
comp.lang.c The C Programming Language
comp.lang.asm.x86 x86 assembly language programming
comp.programming Non-language specific programming
comp.graphics.algorithms Issues of computer graphics
Operating Systems
-----------------
comp.os.msdos.programmer DOS, BIOS, Memory Models, interrupts,
screen handling, hardware
comp.os.ms-windows.programmer.win32 MS/Windows: Mice, DLLs, hardware
comp.os.os2.programmer.misc OS/2 Programming
comp.sys.mac.programmer.misc Macintosh Programming
comp.unix.programmer General Unix: processes, pipes, POSIX,
curses, sockets
comp.unix.[vendor] Various Unix vendors
Microsoft VC++
-------------
microsoft.public.vc.language VC++ issues
microsoft.public.vc.mfc MFC Issues
microsoft.public.dotnet.languages.vc C++/CLR Issues
microsoft.public.dotnet.framework .Net Framework
Borland C++ Builder
-------------------
borland.public.cppbuilder.language Borland C++ Builder
borland.public.cpp.language
borland.public.cppbuilder
-Shiva
http://www.slack.net/~shiva/welcome.txt
Sun Jan 31 00:30:00 EST 2010
==============================================================================
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