http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Writing good articles that have much better chance to be seen by others - 4
messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/ddbe20a354342370?hl=en
* c++ as scripting language - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/8b6a860779bd7319?hl=en
* String not printing data on next line despite \n in the string - 2 messages,
2 authors
http://groups.google.com/group/comp.lang.c++/t/35658d761ffe5130?hl=en
* Design patterns - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
==============================================================================
TOPIC: Writing good articles that have much better chance to be seen by others
http://groups.google.com/group/comp.lang.c++/t/ddbe20a354342370?hl=en
==============================================================================
== 1 of 4 ==
Date: Tues, Dec 29 2009 3:33 pm
From: Kaz Kylheku
On 2009-12-25, red floyd <no.spam.here@its.invalid> wrote:
> On 12/24/2009 12:05 PM, tanix wrote:
>> [redacted]
>
> Here's another one.
>
> Avoid ad-hominem attacks against people who have professional
> reputations you could only dream about having. People such as
> Pete Becker.
Argumento ad hominem does not refer to disagreeing with someone in a rude way.
One perfect example of ad hominem would be something like ``whatever P___ B___
writes is holy scripture because of /who/ he is and his professional
reputation, not because of what is actually written''.
== 2 of 4 ==
Date: Tues, Dec 29 2009 8:21 pm
From: tanix@mongo.net (tanix)
In article <20091229152640.468@gmail.com>, Kaz Kylheku <kkylheku@gmail.com> wrote:
>On 2009-12-24, tanix <tanix@mongo.net> wrote:
>> So, from this standpoint, try to keep the context of the article
>> intact. No not delete some section of the article you are following
>> upon because you think it is "insignificant" in YOUR opinion.
>
>In my opinion, it is bad netiquette not to trim the quoted article
>as much as possible.
Just the other way around.
Quite often, this stripping procedure is explicitly meant to
distort the material and present it as something else.
Secondly, there is absolutely no issues with technical aspect of it.
>A Usenet archive to be useful must preserve the tree structure of
>threads.
Not true.
There may be SOME articles in a thread that are of interest
generally. They may contain some code, some specific ideas,
etc.
While majority of articles, or even thread may not represent
any value for all practical purposes.
Secondly, unless you have a server with years worth of retention,
all you can see is just a couple of days of articles.
You can not search it to find what you are looking for.
You can not review some interesting thread, written years ago,
and ALL sorts of things like that.
>If you can't navigate to a parent article to recover context,
>find a better quality Usenet archive search tool.
VAST majority of article views happen via web,
and what they end up seeing is a SINGLE article.
In most cases, they can not even follow threads,
because there is not next, prev button.
>> Because it may turn out to be significant in readers opinion.
>Nice sentiment;
It is not a sentiment.
It is a BASIC principles of democracy.
> but the reader of an archive isn't a paying customer of the
>article author, so he doesn't get to dictate how the article should have been
>structured to serve him best.
:--}
Looks like a bad joke by someone, whose intent is probably
not that kosher.
Do you realize how damaged the usenet archives are as a result
of this stripping procedure?
Well, probably at least 50% of all articles are useless.
ALL the significant context is gone.
All the intermediate discussions, considerations and issues
are gone.
When you look at usenet from the web, it is totally fragmented
goubledy gook in more cases then not.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 3 of 4 ==
Date: Tues, Dec 29 2009 8:24 pm
From: tanix@mongo.net (tanix)
In article <20091229153000.927@gmail.com>, Kaz Kylheku <kkylheku@gmail.com> wrote:
>On 2009-12-25, red floyd <no.spam.here@its.invalid> wrote:
>> On 12/24/2009 12:05 PM, tanix wrote:
>>> [redacted]
>>
>> Here's another one.
>>
>> Avoid ad-hominem attacks against people who have professional
>> reputations you could only dream about having. People such as
>> Pete Becker.
>
>Argumento ad hominem does not refer to disagreeing with someone in a rude way.
>
>One perfect example of ad hominem would be something like ``whatever P___ B___
>writes is holy scripture because of /who/ he is and his professional
>reputation, not because of what is actually written''.
I see this "ad hominem" template used quite often.
And every single time I remeber seeing it,
it was made by people with perverted minds, distorting things
and attacking someone, blaming him for attacking them.
This is simply a template, used by people with perverted minds,
whose brain capacity does not allow them to find the real solution
or face reality.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 4 of 4 ==
Date: Tues, Dec 29 2009 11:23 pm
From: tanix@mongo.net (tanix)
I am redirecting this reply to the original thread.
Because it is of significance.
The origninal thread was split by some zombies by inserting
the CR/LF and blanks into subject lines, which made several
different threads out of original one.
So, if you already read it, just skip this one.
Change the subject line in other funky threads so theyh merge
back with the original thread.
The correct Subject header for this thread is:
Re: Writing good articles that have much better chance to be seen by others
Now...
In article <20091229152640.468@gmail.com>, Kaz Kylheku <kkylheku@gmail.com>
wrote:
>On 2009-12-24, tanix <tanix@mongo.net> wrote:
>> So, from this standpoint, try to keep the context of the article
>> intact. No not delete some section of the article you are following
>> upon because you think it is "insignificant" in YOUR opinion.
>In my opinion, it is bad netiquette not to trim the quoted article
>as much as possible.
Just the other way around.
Quite often, this stripping procedure is explicitly meant to
distort the material and present it as something else.
Secondly, there is absolutely no issues with technical aspect of it.
>A Usenet archive to be useful must preserve the tree structure of
>threads.
Not true.
There may be SOME articles in a thread that are of interest
generally. They may contain some code, some specific ideas,
etc.
While majority of articles may not represent
any value for all practical purposes.
Secondly, unless you have a server with years worth of retention,
all you can see is just a couple of days of articles.
You can not search it to find what you are looking for.
You can not review some interesting thread, written years ago,
and ALL sorts of things like that.
>If you can't navigate to a parent article to recover context,
>find a better quality Usenet archive search tool.
VAST majority of article views happen via web,
and what they end up seeing is a SINGLE article.
In most cases, they can not even follow threads,
because there is not next, prev button.
>> Because it may turn out to be significant in readers opinion.
>Nice sentiment;
It is not a sentiment.
It is a BASIC principles of democracy.
> but the reader of an archive isn't a paying customer of the
>article author, so he doesn't get to dictate how the article should have been
>structured to serve him best.
:--}
Looks like a bad joke by someone, whose intent is probably
not that kosher.
Do you realize how damaged the usenet archives are as a result
of this stripping procedure?
Well, probably at least 50% of all articles are useless.
ALL the significant context is gone.
All the intermediate discussions, considerations and issues
are gone.
When you look at usenet from the web, it is a totally fragmented
goubledy gook in more cases then not.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
==============================================================================
TOPIC: c++ as scripting language
http://groups.google.com/group/comp.lang.c++/t/8b6a860779bd7319?hl=en
==============================================================================
== 1 of 3 ==
Date: Tues, Dec 29 2009 3:37 pm
From: Sam
Michael DOUBEZ writes:
> Le 29/12/2009 17:31, Fred Zwarts a écrit :
>> Michael Doubez wrote:
>>> On 29 déc, 13:16, Sam<s...@email-scan.com> wrote:
>>>> balajee writes:
>>>>> Hi,
>>>>> I am new bee to C++. Basically I am TCL pogrammer, write scripts to
>>>>> automate interactive applications such as telnet,ftpetc. Can we use
>>>>> C+ + also for the same purpose? as scripting language for above
>>>>> applications?
>>>>
>>>> C++ is not a scripting language. It is a compiled language.
>>>
>>> It is not.
>>> An interpreter engine does exists:
>>> http://root.cern.ch/drupal/content/cint
>>
>> The C++ language is not by definition a compiled language.
>> But CINT is a bad example.
>
> But it is the only interpreter I know of.
It may be an interpreter of something, but unless it is capable of accepting
any syntactically valid C++ source, and "interpreting" it to produce the
same results as if it were compiled, then it cannot be accurately described
as a C++ interpreter.
== 2 of 3 ==
Date: Tues, Dec 29 2009 5:18 pm
From: "BGB / cr88192"
"Sam" <sam@email-scan.com> wrote in message
news:cone.1262129829.39427.22505.500@commodore.email-scan.com...
<--
Michael DOUBEZ writes:
> Le 29/12/2009 17:31, Fred Zwarts a écrit :
>> Michael Doubez wrote:
>>> On 29 déc, 13:16, Sam<s...@email-scan.com> wrote:
>>>> balajee writes:
>>>>> Hi,
>>>>> I am new bee to C++. Basically I am TCL pogrammer, write scripts to
>>>>> automate interactive applications such as telnet,ftpetc. Can we use
>>>>> C+ + also for the same purpose? as scripting language for above
>>>>> applications?
>>>>
>>>> C++ is not a scripting language. It is a compiled language.
>>>
>>> It is not.
>>> An interpreter engine does exists:
>>> http://root.cern.ch/drupal/content/cint
>>
>> The C++ language is not by definition a compiled language.
>> But CINT is a bad example.
>
> But it is the only interpreter I know of.
It may be an interpreter of something, but unless it is capable of accepting
any syntactically valid C++ source, and "interpreting" it to produce the
same results as if it were compiled, then it cannot be accurately described
as a C++ interpreter.
-->
granted, but AFAIK it may be close enough, nevermind missing features and
slight differences...
for example, what does it matter that much, if for example, "foo.bar" and
"foo->bar" are equivalent, ...
what if say, 95% of the time, things work, but in those 5% of edge cases,
fails miserably?...
likely, it just can't claim standards conformance is all.
it would be like, say, if you had someone who was not very good with
English, but most of the time were understood and understood what was being
said, but every so often would have notable grammer errors, not make sense,
or fail to understand well-formed statements.
do we say then that they can't speak English?... no, we usually just say it
isn't very good at it.
the reasonable cutoff then is when it is clearly different, and most or all
input fails to work.
German is not English, Spanish is not English, and Chinese is not English.
put them together, and neither side knows what is being said by the other.
Chinese-English is still English, even if often broken or incoherent, none
the less it is English, just not good English...
"watch where step, the slipery is decieving...".
programming is likely much the same way.
== 3 of 3 ==
Date: Wed, Dec 30 2009 12:11 am
From: Michael Doubez
On 30 déc, 00:37, Sam <s...@email-scan.com> wrote:
> Michael DOUBEZ writes:
> > Le 29/12/2009 17:31, Fred Zwarts a écrit :
> >> Michael Doubez wrote:
> >>> On 29 déc, 13:16, Sam<s...@email-scan.com> wrote:
> >>>> balajee writes:
> >>>>> Hi,
> >>>>> I am new bee to C++. Basically I am TCL pogrammer, write scripts to
> >>>>> automate interactive applications such as telnet,ftpetc. Can we use
> >>>>> C+ + also for the same purpose? as scripting language for above
> >>>>> applications?
>
> >>>> C++ is not a scripting language. It is a compiled language.
>
> >>> It is not.
> >>> An interpreter engine does exists:
> >>>http://root.cern.ch/drupal/content/cint
>
> >> The C++ language is not by definition a compiled language.
> >> But CINT is a bad example.
>
> > But it is the only interpreter I know of.
>
> It may be an interpreter of something, but unless it is capable of accepting
> any syntactically valid C++ source, and "interpreting" it to produce the
> same results as if it were compiled, then it cannot be accurately described
> as a C++ interpreter.
A standard C++ interpreter may not be the goal of CINT developers.
In the standard, the term 'compilation unit' is used but not defined;
and I suspect it is used as a synonym of 'translation unit' which *is*
defined. If you define 'compiled language' has 'without translation',
you are right but nowadays most interpreted languages use JIT and
nothing prevents from doing the same with c++.
--
Michael
==============================================================================
TOPIC: String not printing data on next line despite \n in the string
http://groups.google.com/group/comp.lang.c++/t/35658d761ffe5130?hl=en
==============================================================================
== 1 of 2 ==
Date: Tues, Dec 29 2009 3:53 pm
From: Paavo Helde
"BGB / cr88192" <cr88192@hotmail.com> wrote in
news:hhdjmg$8ob$1@news.albasani.net:
> even then, it is not often "as bad" in practice, for example, for
> calls like 'fgets()' one supplies the maximum string length anyways
> (typically a few chars less than the buffer size), so this much is
Why "few chars less"? Because you are not sure in the documentation?
Or in yourself?
> self-limiting. one can know the call will not return an oversize
> string, since it will be cut off and returned on the next line.
>
> in many other cases, one knows the code that both produces and accepts
> the strings, and so can know that code further up the chain will not
> exceed the limit.
>
> as well, 256 is an "accepted" maximum string length (a tradition since
> long past that something is seriously wrong if a string is longer than
> this).
Accepted by who? I'm serving 10MB HTTP packets through std::string so I'm
sorry I have never heard of this convention. (There was a 256-char string
limitation in Turbo Pascal 3.3, but fortunately this is about 15 years in
history ;-)
>
> much like how something is wrong if a line in a text file is longer
> than 80 chars, and it is usually best to limit output to 76 chars just
> to be safe... (except in certain file formats, where longer lines tend
> to pop up a lot...).
It seems you are confusing the human interface with the program
interface.
>
>
> this does allow "some" safety with fixed-size char arrays, which is
> good since these are one of the fastest ways I know of to implement
> certain string operations.
Using fixed-size arrays does not mean you may skip the check if the data
fits in there. Actually, if the input is not verified and comes from
outside of the program, then it is ridiculous to not check its size. The
cost of doing that is zero, as compared to the time of getting the data
from outside into the program.
I guess many viruses are in dept to guys like you when the "internally
safe" code somehow gets re-used and exploited in the wild.
Paavo
== 2 of 2 ==
Date: Tues, Dec 29 2009 6:17 pm
From: "BGB / cr88192"
"Paavo Helde" <myfirstname@osa.pri.ee> wrote in message
news:Xns9CF11339AD57Epaavo256@216.196.109.131...
> "BGB / cr88192" <cr88192@hotmail.com> wrote in
> news:hhdjmg$8ob$1@news.albasani.net:
>
>> even then, it is not often "as bad" in practice, for example, for
>> calls like 'fgets()' one supplies the maximum string length anyways
>> (typically a few chars less than the buffer size), so this much is
>
> Why "few chars less"? Because you are not sure in the documentation?
> Or in yourself?
>
had to go check the documentation...
actually, I had thought the N was the max number of chars to read, excluding
the '\n' and the 0.
apparently the N is adjusted automatically...
oh well...
doesn't matter too much if there is an occasional fgets around with an N of
254...
>
>> self-limiting. one can know the call will not return an oversize
>> string, since it will be cut off and returned on the next line.
>>
>> in many other cases, one knows the code that both produces and accepts
>> the strings, and so can know that code further up the chain will not
>> exceed the limit.
>>
>> as well, 256 is an "accepted" maximum string length (a tradition since
>> long past that something is seriously wrong if a string is longer than
>> this).
>
> Accepted by who? I'm serving 10MB HTTP packets through std::string so I'm
> sorry I have never heard of this convention. (There was a 256-char string
> limitation in Turbo Pascal 3.3, but fortunately this is about 15 years in
> history ;-)
>
"accepted" by traditional practice.
typically, constants like PATH_MAX, ... are 256.
it doesn't take long (for example, if one digs around in system headers),
before a string-length limit of 256 becomes a recurring pattern (even if
there are variations, for example, UNIX_MAX is 108, but I think this is
because of a general rule that (sizeof(sockaddr_storage)==128) or so, ...).
there are many other examples of this particular limit being in use.
it is an accepted limit, much like how i, j, and k, are accepted names for
integer variables, ...
granted, sometimes one wants a bigger limit though, and sometimes a bigger
limit is used (as there is no real technical reason for this particular
limit apart from convention), ...
I once wrote an HTTP server though, and requests with longer strings kept
comming from nowhere (mostly a string of repreating characters with some
garbage at the end), so in that case I made the limit 1024 and also put in a
limit check. (it can be noted that I think a lot of them were like 256 A's
followed by the garbage...).
luckily though, any buffer overflow exploits intended for one server are
likely to do little more than crash another...
>>
>> much like how something is wrong if a line in a text file is longer
>> than 80 chars, and it is usually best to limit output to 76 chars just
>> to be safe... (except in certain file formats, where longer lines tend
>> to pop up a lot...).
>
> It seems you are confusing the human interface with the program
> interface.
>
either way, this limit is established, as a sort of rule of convention for
most well-formed text files.
it is much like how, by convention, a programmer should not write code with
lines longer than this limit.
>>
>>
>> this does allow "some" safety with fixed-size char arrays, which is
>> good since these are one of the fastest ways I know of to implement
>> certain string operations.
>
> Using fixed-size arrays does not mean you may skip the check if the data
> fits in there. Actually, if the input is not verified and comes from
> outside of the program, then it is ridiculous to not check its size. The
> cost of doing that is zero, as compared to the time of getting the data
> from outside into the program.
>
granted, external disk IO is usually measurable at around 20 MB/s IME.
however, there is a lot which often happens "within" the program, say, when
ones' app is divided up into lots of DLL's which do lots of their internal
communication via data serialized as strings, ...
one component will produce streams of text as its output, and another
component will parse them and follow embedded commands. many tasks may
involve many stages of processing of this sort (in addition to the use of
binary API's, ...).
nevermind that, in many of these cases, ANY unsafe input would be a security
risk, even if it does fit nicely into the buffers. the reason here being
that many of these facilities actually have access to features which are
either turing complete in their own right (yeah, this property tends to pop
up a lot...), or have access to code-generation machinery.
consider for example one has a text-stream "eval" mechanism. outside access
to eval is dangerous even if the text itself is well-formed, since eval will
generally allow whatever code hits it to much around with the app (unless of
course the eval is sandboxed, but I am assuming here it is not...).
similar goes if several components are connected via a stream in a
PostScript like format, and, say, some input goes over which fouls up the
command-interpreter, creates an infinite loop, or worse.
trivial example: "/foo {foo} def foo"
granted, this trivial case could be handled by detecting a stack overflow,
but in the general case, it would be difficult to secure even with input
validation...
> I guess many viruses are in dept to guys like you when the "internally
> safe" code somehow gets re-used and exploited in the wild.
>
or it could be just like expecting to check that pointers always point to
valid addressable memory (say, if one is using a garbage collector with the
ability to validate that a pointer is a heap pointer).
often, it would be too expensive, and too much of a hassle, to check these
things as a general matter of practice.
so, a tradeoff is made:
we assume that the caller is passing valid data, and typically check either
in code which is not likely to be a bottleneck, or where the "safety" of the
other end is not ensured.
typically, validity checking will be done when: performing file IO, dealing
with a network connection, or implementing or dealing with a public API.
if none of these is being done (for example, all this is stuff going on
purely internal to the app, which could happen easily enough) then there may
not be a need to validate.
==============================================================================
TOPIC: Design patterns
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
==============================================================================
== 1 of 3 ==
Date: Tues, Dec 29 2009 6:36 pm
From: Jacqueline Townsend
Yes, robust design patterns kinda get untidy therefore, most programmers avoid them.
== 2 of 3 ==
Date: Tues, Dec 29 2009 8:10 pm
From: tanix@mongo.net (tanix)
In article <Obs_m.86101$Wd1.56390@newsfe15.iad>, Daniel Pitts <newsgroup.spamfilter@virtualinfinity.net> wrote:
>Jayson Cormier wrote:
>> Bean it! Everything... bean-able. Enterprise Java Bean, Netbeans...
>>
>>
>Kicked in the beans.
>
>The Java folks had a great idea with JavaBeans, but they failed at
>implementing it in a consistent and useful way. There is no language
>level support for property-change listeners, so it becomes extremely
>burdensome trying to create a functional bean which is useful as a GUI
>model.
>
>Don't get me wrong, I'm primarily a Java programmer. I just think that
>the Bean hype has caused many people to forget basic abstraction
>concepts, and the benefits of Beans have yet to been fully realized.
Well, I think Sun stretched itself too much creaing ALL sorts of
gadgets, "toolkits", "subsystems" and you name it.
As a result, they spread themselves too thin, worked in too many
different directions and finally, boom, the biggest tragedy in the
sw business, a war with Microsoft, which simply killed Java.
As of this moment, the traffic on MFC sites is twice as much as on
C++ sites and at least 5 times as much as on Java sites.
And Java has contributed significantly by simplifying the language,
getting away from all these pointers, "by value", references and
all sorts of other complications in the language that end up creating
nothing but nightmare.
People often forget that developers have ALL sorts of things in their
mind. They don't need to remember another universe of things when
incoroprating some functioinality from some toolkit or some other
language complication that is voluminous.
Just switching from IDE world view, with its thousands of things
to remember, to debugger worldview, with its piles of things,
to language worldview, and on and on and on, down to switching
your mind to your email program worldivew, then your editor
worldview, which also has thousands of things to keep in mind
and its own concepts, symbols, keystroke sequences, codes,
maps, tables, languages, fonts, colors and on and on and on.
So, what happens that that you have to remember millions of
different things, hundreds ways to switch your mind into totally
different universe and its perspective.
So, when someone develops something, they think someone has
either time or interest in studying another bible sized book
and INSTANTLY be able to switch to another bible sized worldview.
That is what I mean when I say:
"We totally do not understand what information is".
Just a stone age view.
Meanwile, the load on the mind is simply immense.
Just look at things like Java generics or C++ templates,
or .net all sorts of things.
Does anybody think that someone is going to sit there for half
an hour and stare at all those hierogliphs when they look at
some method or class? How long is it going to take you to
develop anything worth even mentioning if you have to switch
your mind at this rate?
And now we have these design patterns with ALL sorts of side
effects. People look at design patterns as some kind of
revolutionary progress and try to stick them on to anything
they stick.
Just as I described before, I worked JSpider.
Very nice conceptually. It used the visitor pattern and the
whole program was totally async. When you try to spider the
web, using this thing the amount of things you have to do is
quite something to consider. There are ALL sorts of complications,
structures, objects, trees and you name it to be dynamically
constructed, updated, etc.
Try to debug this thing?
Well, I spent at least a week working with that code and trying
to extend it so it has much more powerful functionality and
much more flexible everything.
You can not even DEBUG that thing in async mode, because you
may get ANY async event coming from ANY of the threads,
simpltaneously accessing either some page or entire site.
As a result, you can not single step through this thing
and actually relate anything to anything else.
It was the worst nightmare I recall.
No wonder the guy, who originally wrote JSpider, just gave
up and did not maintain or develop it for the last 5 years
at least, despite the fact that it is the most powerful
spider I saw, at least in Java world, which is the ONLY
thing I am interested in.
Just being able to run my main app on Linux after my win
box was rooted and was unusable for a mont, beats all the
arguments I heard against Java hands down.
There was not even need to recompile it.
Sure, GUI did look quite differently and less pleasing then
on the win, but functionality was perfectly there.
And I see ALL sorts of design pattern that create such a
nightmare from debugging standpoint or even from the standpoint
of being able to quickly analyze your code withing a couple
of seconds in order to implement something or fix something,
that the overall net benefit is zero, if not negative.
But yes, it DOES look on paper as something "revolutionary",
something really "impressive".
As a mind trip that is.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
== 3 of 3 ==
Date: Tues, Dec 29 2009 8:13 pm
From: tanix@mongo.net (tanix)
In article <hheeb9$u0b$2@speranza.aioe.org>, Jacqueline Townsend <inanestz6@san-teck.de> wrote:
>Yes, robust design patterns kinda get untidy therefore, most programmers avoid
> them.
Well, if you could put that design pattern in some comfortable box
so it sits there and once you have gone through pain of implementing
it, you don't have to worrry about it, then it would be a different
story.
But plenty of design patterns end up creating the async. code, and
they are such a pain on the neck to debug in a more or less complex
program, that I bet you can find more than handful of them that
actually help things and are like hands in glove at the end.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
==============================================================================
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