http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* C++ jobs down another 40% - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
* ♠♤♠♤♠♤【Paypal】 Wholesale Cheap Boots brand shoes ( www.ecyaya.com ) - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/49eee9bc7c203d04?hl=en
* 田●田●田 Cheap Wholesale Air Force One Shoes at www.fjrjtrade.com <paypal
payment> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/5e9bf8a314eda877?hl=en
* std::map element in heap or stack? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/c9389bfe3bb26d37?hl=en
* Exception Misconceptions: Exceptions are for unrecoverable errors. - 12
messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
* String not printing data on next line despite \n in the string - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c++/t/35658d761ffe5130?hl=en
* Searching SourceForge - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/18c471574f99a91d?hl=en
* Locale to Unicode Codepoint mapping? - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/0f87b730b24e407a?hl=en
* Why does this crash? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/09275db5bcbd6f3b?hl=en
* Event dispatcher, hooks and Interceptor pattern for C++? - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/a82e5c39e2fe1f12?hl=en
* ┈━═☆ Cheap wholesale Lv Jean, True Relig Jean, Laguna Beach Jean, G-star
Jean ect at website: www.fjrjtrade.com <Paypal Payment> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6fe10cb989d88f0e?hl=en
==============================================================================
TOPIC: C++ jobs down another 40%
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Dec 25 2009 11:58 pm
From: "BGB / cr88192"
"tanix" <tanix@mongo.net> wrote in message
news:hh3nuq$14q$2@news.eternal-september.org...
> In article <hh3ne4$7k2$1@news.albasani.net>, "BGB / cr88192"
> <cr88192@hotmail.com> wrote:
>>
>>"Chris M. Thomasson" <no@spam.invalid> wrote in message
>>news:xR9Zm.3013$8e4.2445@newsfe03.iad...
>>> "tanix" <tanix@mongo.net> wrote in message
>>> news:hh31vk$82i$1@news.eternal-september.org...
>>>> In article
>>>> <66e7b0f7-4c71-4db4-a9f1-3f9d7e4dc5a5@a32g2000yqm.googlegroups.com>,
>>>> James
>>>> Kanze <james.kanze@gmail.com> wrote:
>>>>>On Dec 23, 11:02 pm, red floyd <redfl...@gmail.com> wrote:
>>>>>> On Dec 23, 12:50 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>>>>>
>>>>>> > The number of job adverts in the UK citing C++ has fallen
>>>>>> > 40% for the second year in a row:
>>>>>
>>>>>> Hey, Jon! Wha'ts the market for F# jobs like?
>>> [...]
>>>>
>>>> Well, I just looked at it on Wikipedia:
>>>> http://en.wikipedia.org/wiki/F_Sharp_%28programming_language%29
>>>>
>>>> Looks like another bluff to me. All sorts of bells and whistles.
>>>> For me, personally, it is a no go, and primarlily because it is
>>>> based on .net framework.
>>>
>>> FWIW, here is a fairly portable C# and CLR implementation:
>>>
>>> http://www.mono-project.com
>>>
>>
>>yep, in my case, I acknowledge that mono exists.
>>looking deeper into the project though, I am personally a little less
>>compelled:
>>it is, IMO, poorly architected and built on terrible code (and terrible
>>coding practices).
>
> Uggh. That one is going to wait then.
>
well, I guess it is probably not so bad if:
one only really expects it to work on Linux, and uses MS's .NET on Windows;
makes sure to pretend (sort of) that they are coding on Windows, and stays
clear of Mono's extensions (mostly GTK bindings, glue into a bunch of GNome
related stuff, ...).
personally, I would have assumed making a new GUI API, which was generally
free of being tied to a particular OS-level GUI. I don't like the idea of
coding against a GTK wrapper, as personally I don't want to be tied to
having to use GTK.
but, this is not the end of it, as it is worth noting that Mono itself is
tied to GTK at a very fundamental level (IOW, a lot of the core VM code is
built on GTK's API functions, on GLib, ...).
I at first put some effort into trying to get it to build from sources on
Windows, but was having far too many difficulties, and personally found the
code a bit nasty, so quickly enough gave up.
I later started looking into writing my own .NET implementation, but this
petered out, as my frameworks' architecture started taking shape on its own,
but is not a whole lot like the .NET VM.
actually, my project is a lot more of a chimera (some parts influenced by
the JVM, others by .NET, others by GCC, others by LLVM, ...).
however, I think its only real advantage is that I personally feel the role
of the VM is different, and so there are many "philosophical" differences.
personally, I rather dislike monolithic architectures. and so, much of the
architecture is based around loosely coupled "modules" or "components", and
some effort is put into making these compoents too specific, even to each
other.
so, my beliefs here are that:
the world does not revolve around the VM, the VM framework should "assist"
the app, not "dominate" it;
it should be possible to use which parts are needed, and discard the rest
(or supply alterantive implementations, if this is needed);
the architecture should remain relatively open, as not to overly limit
possible use cases (consider if the VM is composed of lego blocks which can
be put together in different ways under the discretion of the frontend app);
the VM should also play well with pre-existing technologies (I have tried to
base many of the components after fairly "standard" pieces, and although
imperfect at times, it is possible to use "off the shelf" apps for many
purposes, both to provide input or accept output);
...
so, I am at odds with both .NET and the JVM on philosophical grounds;
and, I disagree with LLVM on architectural grounds (granted, I have a mess
here, but personally I just don't really like LLVM's architecture);
...
however, I have tried to minimize creating "novel" parts when possible.
sadly, some level of "novelty" and "internal dependencies" are inevitable it
seems...
thus far, much of the VM revolves around "good old C", both as the language
of implementation, and as the language of scripting. I have attempted to
move beyond C (Java and C# looked like good languages to try to add, and
JavaScript and Scheme also have some interest).
however, it is all a bit of a "trudging through mud" experience, and C
remains as the only really "usably complete" language in the mix (my C
compiler contains a few holes and failings, but for the most part it is
adequate).
but, ideally, an app will "use" a framework, rather than be "built on top
of" it, and it "should" be a component which can be integrated into a
project (or dropped again) without otherwise requiring significant
modification.
this is the ideal, although granted, it is much work to achieve these sorts
of ideals.
>>granted, nothing is perfect.
>>
>>in general, I like C# though, as for the most part it seems a fairly
>>cleanly
>>designed language (apart from that it seems to need some level of "black
>>magic" to be able to parse).
>>
>>I am a little more hesitant about the rest of the .NET framework though,
>>and
>>would rather it was something capable of being statically compiled and
>>operated standalone.
>
> I just looked at some of it in passing.
> Looks like some kind of equivalent of JVM underneeth.
>
C# is sort of like "Java's big brother" in terms of design. at its core,
they are in many ways fairly similar languages (just C# returns a little
closer to its C and C++ roots, re-adding many more features and
complexities...).
in a similar way, the .NET VM architecture is sort of like a "big brother"
to the JVM. there are many subtle aspects which are similar, but with one
notable and apparent difference:
.NET is FAR more complicated WRT its internal workings.
(the JVM has a few hairy bits, but in general it is "not that bad", and a
beating together a working basic implementation is a "reasonably" easily
achievable goal). well, apart from the persisting lack of a class library
(writing Java code in a vacuum is not nearly so compelling).
> A single fact that you need to agree with something to even
> have your app to run under it, is a total no go for me.
>
> You can not even deliver your J# app as a single executable
> is simply berzerk. And now, you can not even compile Java
> starting with VC 2008 and higher. Disaster.
>
yeah.
>>little in the language particularly prohibits this, only that I am not
>>aware
>>of any standalone C# implementation.
>
>>it is, at the moment, a little easier to write standalone Java, since
>>there
>>is both GCJ, and JBC is simple enough as to make it not particularly
>>difficult to trans-compile to C or ASM
>
> Oh, interesting. Is there a way to generate Java code out
> of C++/MFC by any chance?
>
"there be dragons there".
Java can be compiled to C without too much horror, since for the most part
JBC uses a clear subset of C's basic capabilities (although, the translation
is at a fairly low level of abstraction, for example, I operate "underneath"
the JVM's stack model, and essentially remap stack operations to local
variables via a kind of naive graph-conversion algo...).
I actually use a plain Java compiler to produce the class files, so that I
could them mostly focus on translating the bytecode to C.
however, C does not map nicely to the JVM (even in the simple case, it is
horridly inefficient, and even more horridly crappy), this much is not
likely worth the bother.
C++ -> Java, if possible, would likely be something too terrible to be
described.
x86 -> Java or JBC should be possible, but I doubt would be of much
practical use (likely poor efficiency, and the languages would not be able
to really relate or share data at a meaningful level). likewise for just
writing an x86 interpreter.
however, an interpreter would allow, potentially, compiling C++ code to x86,
loading the x86 in an interpreter and running it (at likely crap speeds),
...
is it worthwhile?... probably not.
it is worth noting that low-abstraction machine-code like representations
(including JBC and x86 machine code) are generally easier to translate and
manipulate effectively, whereas with higher-level forms (such as source
code), one can generally do a much better job and has far more "power".
however, JBC can be fairly faithfully converted to C (much easier than many
other possible paths), and does not tend to introduce all that many
"impedence" problems.
hence, it works acceptably to convert Java to C by first compiling to JBC
(AKA: class files), and then translating.
however, this does not extend to the general case, and is very specific to
various internal properties of both Java and JBC.
(although, granted, there are still a few sharp edges, but these are
managable).
for example, Java requires that the stack have exactly the same layout at
both the source and destination of a jump, and that the layout of the stack
is required to be constant at a given bytecode position.
the implications of these simple restrictions are notable and drastic, and
without these particular rules, doing an effective translation would have
been a much uglier problem (essentially requiring "simulation", rather than
a value-flow graph-based translation, ...).
just imaging here that every push and pop pushes or pops an abstract
variable, rather than a value, and so the sequence of stack-based operations
can be compared to putting down and picking up the ends of tubes and
plugging them into operations, and then putting down the result-tube, ...
the process, though naive, is elegantly simple, and can convert a method
from a sequence of stack operations, into a graph of interconnected
operations, which can then be (fairly straightforwardly) converted back into
C code.
none of this holds with either C, C++, or x86 machine code, OTOH, and hence
such a conversion is not directly possible as such.
or such...
== 2 of 2 ==
Date: Sat, Dec 26 2009 4:32 am
From: tanix@mongo.net (tanix)
In article <hh4fo1$7p6$1@news.albasani.net>, "BGB / cr88192" <cr88192@hotmail.com> wrote:
>
>"tanix" <tanix@mongo.net> wrote in message
>news:hh3nuq$14q$2@news.eternal-september.org...
>> In article <hh3ne4$7k2$1@news.albasani.net>, "BGB / cr88192"
>> <cr88192@hotmail.com> wrote:
>>>
>>>"Chris M. Thomasson" <no@spam.invalid> wrote in message
>>>news:xR9Zm.3013$8e4.2445@newsfe03.iad...
>>>> "tanix" <tanix@mongo.net> wrote in message
>>>> news:hh31vk$82i$1@news.eternal-september.org...
>>>>> In article
>>>>> <66e7b0f7-4c71-4db4-a9f1-3f9d7e4dc5a5@a32g2000yqm.googlegroups.com>,
>>>>> James
>>>>> Kanze <james.kanze@gmail.com> wrote:
>>>>>>On Dec 23, 11:02 pm, red floyd <redfl...@gmail.com> wrote:
>>>>>>> On Dec 23, 12:50 pm, Jon Harrop <j...@ffconsultancy.com> wrote:
>>>>>>
>>>>>>> > The number of job adverts in the UK citing C++ has fallen
>>>>>>> > 40% for the second year in a row:
>>>>>>
>>>>>>> Hey, Jon! Wha'ts the market for F# jobs like?
>>>> [...]
>>>>>
>>>>> Well, I just looked at it on Wikipedia:
>>>>> http://en.wikipedia.org/wiki/F_Sharp_%28programming_language%29
>>>>>
>>>>> Looks like another bluff to me. All sorts of bells and whistles.
>>>>> For me, personally, it is a no go, and primarlily because it is
>>>>> based on .net framework.
>>>>
>>>> FWIW, here is a fairly portable C# and CLR implementation:
>>>>
>>>> http://www.mono-project.com
>>>>
>>>
>>>yep, in my case, I acknowledge that mono exists.
>>>looking deeper into the project though, I am personally a little less
>>>compelled:
>>>it is, IMO, poorly architected and built on terrible code (and terrible
>>>coding practices).
>>
>> Uggh. That one is going to wait then.
>>
>
>well, I guess it is probably not so bad if:
>one only really expects it to work on Linux, and uses MS's .NET on Windows;
>makes sure to pretend (sort of) that they are coding on Windows, and stays
>clear of Mono's extensions (mostly GTK bindings, glue into a bunch of GNome
>related stuff, ...).
>
>personally, I would have assumed making a new GUI API, which was generally
>free of being tied to a particular OS-level GUI. I don't like the idea of
>coding against a GTK wrapper, as personally I don't want to be tied to
>having to use GTK.
Sounds horrible.
>but, this is not the end of it, as it is worth noting that Mono itself is
>tied to GTK at a very fundamental level (IOW, a lot of the core VM code is
>built on GTK's API functions, on GLib, ...).
GUI IS one of the biggest problems.
I had a chance to look at some of those toolkits in passing.
Horrible stuff.
I think there needs to be some portable GUI subsystem so you don't have
to worry about one toolkit on one platform and totally different way
of doing it on another.
Something like it is in Java for example.
Otherwise, they keep reinventing the wheel and none of it you can
rely upon as a single version of your code.
Unfortunately, you need some equivalent of JVM to do it to shield
you from the O/S particularities.
But I think we are at the point where things like JVM or MVM
or that sucky .net are essentially what virtual machines are.
Processing power and memory limitations are no longer there.
It is understood that at a time of P-Machine (Pascal), which was meant
to significantly improve the performance of Pascal, it was unrealistic
to expect that the idea will be accepted, and it was not.
But now things are different.
Basically, the portability, a single way of saying something,
without worrying about the O/S, environment or anything for that
matter is what is needed more than anything else.
I personally think F# is a flop, no matter how many people join
the camp. It is a convoluted, over complicated pile of concoctions
that try to give you all sorts of bells and whistes to the point
that they even try to address the database issues and do some
hacks of Javascript level where functions may include other functions
as parameters. It is a mix of Lisp and Javascript. Essentially
the same idea of dynamically built code. Except complexities
and the very concepts are as flaky as it get from what I see.
Building a dynamic code that can go as far as dynamically construct
some other code is not exactly a new idea, going back to Forth,
Lisp, etc.
But the very concept is flawed. The code becomes utterly unintuitive.
You can not even comprehend what comes out of it at the end.
I talked to Javascript guys and they said once you hit a certain
problem related to this kind of stuff, good luck. Because it is
going to be a hell for you to fix it and you may have to spend
months on it. I'd say I agree after looking at Javascript.
A while back, I had the same idea, except it was for database
applications. I asked a question: what prevents you from writing
a database stored program where you use the rows to store your
high level instructions? Well, nothing really. I implemented in
and it worked just fine. But then it withered away. Basically,
I stopped working with database.
Now they have it all over the place.
But there are plenty of disadvantages of such an approach.
It lacks the necessary structure. Yes, it is as portable as it
gets, but you don't have that "super-language" syntax. It is
all disassociated set of instructions, no matter how high level
and how powerful they are. It lacks the properties of high
level languages.
So, my opinion on this is that people think "it would be nice"
to add the ability to construct the programs. But they seem to
fail to comprehend that your very language becomes a nightmare
in the modern world.
Again, people do not have neither time, nor interest to waste
hours of their time to either read some complicated goubledy
gook code, that takes hours just to understand what it does
essentially because of the most horrible, utterly unintuitive
language syntax constructs, and I specifically mean generics.
When and why do you need generics and what does it buy you?
Well, I can find only one place in my code, and that is a relatively
large piece of code, where "generics is a must". Lucky me,
I can not even use generics because it is not supported in
my development environment, thanx to these wars between
Microsoft and Sun.
So, I had to implement it using the "copy/paste antipattern" and
I have about 3 copies of exactly the same logic, dealing with
3 types or argument.
Do I regret it? - Nope. Not to the least.
Did I EVER have ANy problems with it? - Not that I know of.
I don't even notice this code. Works like a champ.
And each of those methods take about 10 lines of code.
Why would I bother to write some ugly code using generics?
I would not even THINK about such a think. UTTERLY usesless.
How many places in your code do you have that do very similar
things? Well, I bet ALL over the place. Would you need to
replace it with generics? Well, try.
One professor from France, a while back said:
Writing programs automatically is just a myth that will never
happen. Because each program is unique and has millions of
nasty little things that distinguish them from something
similar.
Otherwise, we would not have a software industry by now.
It would be all generated by the software robots.
And with all the "developments", interfaces, OO approach,
it is still a myth, just the same.
I do not think THIS is the priority of development and THIS
is what is going to imporve the sofware design.
And I do not think that introductions of more and more
complexities into syntax and notation is going to solve
ANYTHING. It is just going to create more and more headaches
as it becomes more and more unintuitive.
Language designers seem to be totally oblivious of the fact
that their language is not exactly what is going on in the
programmers or designer's mind. They need some specific
JOB to be done. Some specific CONCEPT to be implemented,
some specific ARCHITECTURE that will do such and such.
They could care LESS if your obscession with languages means
something to you as language designer. I do not recall many
cases, if any, where I thought: oh crap, I can not do this
and that because my language SYNTAX is screwed up, or my
espressive power is not enough.
But I do recall TONS of cases where I had to waste almost
half an hour of my time looking at some utterly ugly code,
written by some idiot with complex of inferiority, that
probably wasted DAYS of his time to write some generics
goubledy gook code that was not even needed to begin with.
I could do exact same thing with funken C code, not even C++.
And the hell would sooner get frozen before they can prove
ANY advantage of that "purist" code and all those compile
time "benefits" they get out of it.
But no. These suckers need to show the whole world how "smart"
they are. You see, they can OUTSMART you!
:--}
What a bunch of sickos, utterly brainless idiots, driven by
the complex of inferiority, forever trying to prove everybody
how "smart" they are. Why do you need to even bother with such
foolish things? I simply can not find a bettter term for it.
>I at first put some effort into trying to get it to build from sources on
>Windows, but was having far too many difficulties, and personally found the
>code a bit nasty, so quickly enough gave up.
Hey. Thanx for your feedback. That is exactly the kind of thing
I need to hear. The last thing in the world I am interested in
wasting weeks, if not months of my time just to eventually realized
I was screwed again by some fools, selling my pussy in the sky with
diamonds.
>I later started looking into writing my own .NET implementation, but this
>petered out, as my frameworks' architecture started taking shape on its own,
>but is not a whole lot like the .NET VM.
>actually, my project is a lot more of a chimera (some parts influenced by
>the JVM, others by .NET, others by GCC, others by LLVM, ...).
Well, would be interesting to see what kind of thing you came up with.
You can write an article on it. Don't worry about that "off topic" crap.
We'll fight if we have to.
however, I think its only real advantage is that I personally feel the role
>of the VM is different, and so there are many "philosophical" differences.
Like what?
You see, what I am beginning to sense more and more that the solution
to language and portability issues is that very VM as a concept.
And I think Java is a perfect example of it.
Because it demonstrated in practical terms that the whole language
becomes much more powerful (in my opinion) and MUCH more portable
and all sorts of portability related issues could be resolved,
and GUI, threads and garbage collections could be wired right into it.
So, once you have a VM that handles all those nasty details,
you are shielded from ALL sorts of problems and issues.
Yes, that VM probably have to have some web related functionality
wired right into it. Plenty people complain about very primitive,
low level support of web apps in Java, and I trust what they say
and I can see some of it, and I think the language and VM
designers need to pay MUCH closer attention to what they ask for
instead of inventing some ugly even even more complicated stuff
with language syntax and semantics, that turns out to be some
of the most useless thing at the end just because no one really
needs it in forseable future. It all just adds to conceptual fat
at the end.
>personally, I rather dislike monolithic architectures. and so, much of the
>architecture is based around loosely coupled "modules" or "components", and
>some effort is put into making these compoents too specific, even to each
>other.
Sure, why not?
>so, my beliefs here are that:
>the world does not revolve around the VM, the VM framework should "assist"
>the app, not "dominate" it;
Well, it does not have to DOMINATE it.
But it CAN assist it, so you don't have to worry inventing another
language to use some of those things, so necessary from the standpoint
of portability, such as GUI, filesystem layer, threads, GC and other
basic and universal mechanisms, needed by just about any app out there.
I don't think you can even argue the case of VM being "evil"
even on an embedded system, even though that is a stretch.
>it should be possible to use which parts are needed, and discard the rest
>(or supply alterantive implementations, if this is needed);
I totally agree. Dynamic system wiring is probably more beneficial
that most of bells and whistles I see.
>the architecture should remain relatively open, as not to overly limit
>possible use cases (consider if the VM is composed of lego blocks which can
>be put together in different ways under the discretion of the frontend app);
I'd LOVE to see THAT kind of thing.
>the VM should also play well with pre-existing technologies (I have tried to
>base many of the components after fairly "standard" pieces, and although
>imperfect at times, it is possible to use "off the shelf" apps for many
>purposes, both to provide input or accept output);
>....
>so, I am at odds with both .NET and the JVM on philosophical grounds;
I don't want to even HEAR about .net or asp.
To me, that equates with profound evil, whose only purpose is
to dominate the world. The same thing as NWO, only in sw business.
That stuff is out the window for me, and for good.
From my end, it is RADICAL non acceptance of the whole underlying
philosophy of it, which is nothing more than maximization of the
rate of sucking of the blood of many by the few.
It is total NON portability.
It is a police state equivalent of the "matrix", the sowtware industry
version of it.
It is a dead end that will NEVER, under ANY circumstances,
will either solve any problems we are facing right now,
or make things EASIER in order to make some genuine progress.
It is nothing more than a giant speder web, whose square purpose
is to catch as many flies and get them entangled in a deadly dance.
It is UTTER NON cooperation. It is an idea of total control of destiny
of human kind that eventually translates into a two class society,
the "elite" and "slaves", and this is not just some "conspiracy
theory". This IS the reality of what is going on.
Those anti-globalists are not just some bunch of fools.
I just learned recently that their leader happens to be a former
supreme court justice. Someone who knows this thing so good, that
many sculls are going to get cracked to even comprehend what he knows.
Must be a person of total honesty to take SUCH a grand risk.
He can be killed ANY moment and he knows that all too well.
THESE are the kinds of people that need to be involved in politics,
if we are to get any benefit for ALL, and not just fattest parasites,
sucking every drop of blood they can find from the body of
mankind.
>and, I disagree with LLVM on architectural grounds (granted, I have a mess
>here, but personally I just don't really like LLVM's architecture);
Sorry. Do not know what LLVM is.
>....
>
>however, I have tried to minimize creating "novel" parts when possible.
>
>sadly, some level of "novelty" and "internal dependencies" are inevitable it
>seems...
Sure. There is no way around it. That's the whole trip of it at the end.
>thus far, much of the VM revolves around "good old C", both as the language
>of implementation, and as the language of scripting. I have attempted to
>move beyond C (Java and C# looked like good languages to try to add, and
>JavaScript and Scheme also have some interest).
C# - full stop.
Red siren: WARNING: You are entering the domain of The Head,
Microsoft, the Evil Most Profound.
Unless C# is accepted by everybody and unless it is not a subject
of copyrights and pattents, I would not touch it with a 6 foot poll.
There is simply no need for it to begin with.
C# does not solve anything so radical that is is worth even
bothering with, regardless of how many language "experts" say
it is salvation for mankind.
>however, it is all a bit of a "trudging through mud" experience,
And forever so.
> and C
>remains as the only really "usably complete" language in the mix
Indeed. It is the ONLY true "revolution" in the software industry,
that contributed more to it than all the other stuff combined.
>(my C
>compiler contains a few holes and failings, but for the most part it is
>adequate).
You mean you have your own C compiler? :--}
That made my day!
>but, ideally, an app will "use" a framework, rather than be "built on top
>of" it,
What do you mean by that?
> and it "should" be a component which can be integrated into a
>project (or dropped again) without otherwise requiring significant
>modification.
>this is the ideal, although granted, it is much work to achieve these sorts
>of ideals.
>>>granted, nothing is perfect.
>>>
>>>in general, I like C# though, as for the most part it seems a fairly
>>>cleanly
>>>designed language (apart from that it seems to need some level of "black
>>>magic" to be able to parse).
>>>
>>>I am a little more hesitant about the rest of the .NET framework though,
>>>and
>>>would rather it was something capable of being statically compiled and
>>>operated standalone.
>>
>> I just looked at some of it in passing.
>> Looks like some kind of equivalent of JVM underneeth.
>C# is sort of like "Java's big brother" in terms of design. at its core,
>they are in many ways fairly similar languages (just C# returns a little
>closer to its C and C++ roots, re-adding many more features and
>complexities...).
Well, I saw some of that stuff. Never had enough time to get into
it. And what I saw does not make that much of a sense to me.
Just another pile of complications and bells and whistles
that simply make my job MORE difficult and not less,
even though they'd take me up on spears for saying things these,
lil could I care though. Cause I know where I stand and what I need.
Not them.
>in a similar way, the .NET VM architecture is sort of like a "big brother"
>to the JVM.
I bet it is a ripoff essentially.
> there are many subtle aspects which are similar, but with one
>notable and apparent difference:
>..NET is FAR more complicated WRT its internal workings.
Well, that IS the very core strategy of Microsoft.
What it is is this: whenever you need to do ANY kind of improvement,
do it in the MOST complicated way possible. So it takes those goats
at least two years to feel comfortable with it.
If you need to add 2 and 2, do it in such a way, that you have five
layers of abstraction. Plug in universal-trans-gallactic,
super duper omnipotent wrapper that won't even run unless they
sign YOUR "protocols". Then document it as little as you can.
And release it under the slogan of "New Revolutionary Technology"
(of suckology).
The square purpose of Microsoft is to get everyone entangled into
this gook, and once they are caught, there is no way out.
Then attach your sucking tubes to their body and suck as much blood
as you can manage. Until they can barely breath and walk.
That IS the very core of their "strategy".
The same thing is Google, the manifistation of evil even more
profound from what I know.
Recently I have heard that they have all these zombies running
arount the hallways at Microsoft with plastic smiles, stuck on
their faces, while thinking about ANY kind of crap they can
come up with so it could be "patented".
What Microsoft and Google do right now is to try to patent
ANYTHING they can imagine. They pay people a few hundred bux
if they come up with ANY crazy thing that could be patented.
Not that they have ANY plans to actually use thesse "invention".
But just to prevent ANYBODY from possibly doing it, and if they
DO intent to use it and if they DO invent something, you can
claim: sorry, you can only do it if I attach my sucking tubes
to your body and suck your blood.
The same thing is what Google is doing this very moment.
The consequences are simply horrendous. I just thought about
a couple of things and I had goose bumps, just to see what
could be result of it in my specific situation, even though
I don't think their zombies already patented some stuff I've
been doing.
>(the JVM has a few hairy bits, but in general it is "not that bad", and a
>beating together a working basic implementation is a "reasonably" easily
>achievable goal).
Well, good.
That is ALL that counts at the end.
> well, apart from the persisting lack of a class library
>(writing Java code in a vacuum is not nearly so compelling).
Well, I even heard some people in Java world complaining that
Java has just WAY to much stuff, which should not belong to
a language.
From what I see, this C# stuff is mostly a ripoff of Java.
But that is another matter.
Just look at collections. They are rich enough to fill vast
majority of applications and their performance is as good as
it gets. All the algorithms that I saw are top notch
implementations that approach the theoretical limit of a given
approach.
And that is ALL I want to hear about collections.
And if you don't have something that is covered by collections,
well, that is what programmers are for. Keeps you gainfully
employed after all.
In other words, I can not agree with this one.
I'd like to see more substance to this argument.
>> A single fact that you need to agree with something to even
>> have your app to run under it, is a total no go for me.
>>
>> You can not even deliver your J# app as a single executable
>> is simply berzerk. And now, you can not even compile Java
>> starting with VC 2008 and higher. Disaster.
>yeah.
>>>little in the language particularly prohibits this, only that I am not
>>>aware
>>>of any standalone C# implementation.
>>
>>>it is, at the moment, a little easier to write standalone Java, since
>>>there
>>>is both GCJ, and JBC is simple enough as to make it not particularly
>>>difficult to trans-compile to C or ASM
>>
>> Oh, interesting. Is there a way to generate Java code out
>> of C++/MFC by any chance?
>"there be dragons there".
>Java can be compiled to C without too much horror,
Well, I am talking about MFC specifically, and that is GUI
stuff to a large extent, that works totally different than Java way.
I don't think it is a trivial task.
> since for the most part
>JBC uses a clear subset of C's basic capabilities (although, the translation
>is at a fairly low level of abstraction, for example, I operate "underneath"
>the JVM's stack model, and essentially remap stack operations to local
>variables via a kind of naive graph-conversion algo...).
Cool stuff. Why don't you publish more about it?
Some principles, architecture or what have you.
If you think you can do it or even interested in doing it...
>I actually use a plain Java compiler to produce the class files, so that I
>could them mostly focus on translating the bytecode to C.
>however, C does not map nicely to the JVM (even in the simple case, it is
>horridly inefficient, and even more horridly crappy), this much is not
>likely worth the bother.
>
>C++ -> Java, if possible, would likely be something too terrible to be
>described.
Too bad. Well, what to do? I was just trying to see if I could
save a couple of months of work if I had not rewrite it by hand.
But that's ok. We can live with that.
I would REALLY like to port my monitoring firewall to linux.
The problems are mostly GUI and low level network driver interface.
>x86 -> Java or JBC should be possible, but I doubt would be of much
>practical use (likely poor efficiency, and the languages would not be able
>to really relate or share data at a meaningful level). likewise for just
>writing an x86 interpreter.
Well, I did not expect to have much luck. But just in case.
The stuff doe not map from MFC to Java that well.
Baeically, you have to rewrite the whole thing.
But I bet it is going to be the easiest thing in the world,
going from C++/MFC to Java. It would probably be 3 times as hard
to go the other way around. MFC sucks pretty bad as far as sophisticated
GUI goes where you do not use the modal dialogs and where you dialogs
are not some dumb, single threaded, fixed size miniscule boxes,
just like about anything microsoft does, but are fully resizable,
multi-threaded, property sheet/page dialogs.
That thing would be a disaster to implement in MFC.
>however, an interpreter would allow, potentially, compiling C++ code to x86,
>loading the x86 in an interpreter and running it (at likely crap speeds),
No. Interpreters are totally out of the window for this job.
It is high traffic, high performance situation, where you have
to do all sorts of tricks to make sure you are not blown out
in some situations.
>....
>is it worthwhile?... probably not.
>it is worth noting that low-abstraction machine-code like representations
>(including JBC and x86 machine code) are generally easier to translate and
>manipulate effectively, whereas with higher-level forms (such as source
>code), one can generally do a much better job and has far more "power".
I don't know what is JBC.
>however, JBC can be fairly faithfully converted to C (much easier than many
>other possible paths), and does not tend to introduce all that many
>"impedence" problems.
>hence, it works acceptably to convert Java to C by first compiling to JBC
>(AKA: class files), and then translating.
I need C++, and specifically, MFC to Java.
>however, this does not extend to the general case, and is very specific to
>various internal properties of both Java and JBC.
>(although, granted, there are still a few sharp edges, but these are
>managable).
>for example, Java requires that the stack have exactly the same layout at
>both the source and destination of a jump, and that the layout of the stack
>is required to be constant at a given bytecode position.
>the implications of these simple restrictions are notable and drastic, and
>without these particular rules, doing an effective translation would have
>been a much uglier problem (essentially requiring "simulation", rather than
>a value-flow graph-based translation, ...).
>
>just imaging here that every push and pop pushes or pops an abstract
>variable, rather than a value, and so the sequence of stack-based operations
>can be compared to putting down and picking up the ends of tubes and
>plugging them into operations, and then putting down the result-tube, ...
>
>the process, though naive, is elegantly simple, and can convert a method
>from a sequence of stack operations, into a graph of interconnected
>operations, which can then be (fairly straightforwardly) converted back into
>C code.
>
>none of this holds with either C, C++, or x86 machine code, OTOH, and hence
>such a conversion is not directly possible as such.
>or such...
Hey. Good article. I really enjoyed it.
--
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: ♠♤♠♤♠♤【Paypal】 Wholesale Cheap Boots brand shoes ( www.ecyaya.com )
http://groups.google.com/group/comp.lang.c++/t/49eee9bc7c203d04?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 12:27 am
From: hero
♠♤♠♤♠♤【Paypal】 Wholesale Cheap Boots brand shoes ( www.ecyaya.com )
Footwear (paypal payment)( www.ecyaya.com )
wholesale DIOR Boots in www.ecyaya.com
wholesale DIOR Sandal in www.ecyaya.com
wholesale Burberry Boots in www.ecyaya.com
wholesale Burberry Sandal in www.ecyaya.com
wholesale Chanel Boots in www.ecyaya.com
wholesale Chanel Sandal in www.ecyaya.com
wholesale COACH Boots in www.ecyaya.com
wholesale COACH Sandal in www.ecyaya.com
wholesale D&G Boots in www.ecyaya.com
wholesale DIOR Boots in www.ecyaya.com
wholesale DIOR Sandal in www.ecyaya.com
wholesale ED Hardy Boots in www.ecyaya.com
wholesale Fendi Boots in www.ecyaya.com
wholesale GUCCI Boots in www.ecyaya.com
wholesale GUCCI Sandal in www.ecyaya.com
wholesale LV Boots in www.ecyaya.com
wholesale LV Sandal in www.ecyaya.com
wholesale UGG Boots Shoes in www.ecyaya.com
wholesale Versace Boots in www.ecyaya.com
Paul Smith shoes (paypal payment)( www.ecyaya.com )
Jordan shoes (paypal payment)( www.ecyaya.com )
Bape shoes (paypal payment)( www.ecyaya.com )
Chanel shoes (paypal payment)( www.ecyaya.com )
D&G shoes (paypal payment)( www.ecyaya.com )
Dior shoes (paypal payment)( www.ecyaya.com )
ED hardy shoes (paypal payment)( www.ecyaya.com )
Evisu shoes (paypal payment)( www.ecyaya.com )
Fendi shoes (paypal payment)( www.ecyaya.com )
Gucci shoe (paypal payment)( www.ecyaya.com )
Hogan shoes (paypal payment)( www.ecyaya.com )
Lv shoes (paypal payment)( www.ecyaya.com )
Prada shoes (paypal payment)( www.ecyaya.com )
Timberland shoes (paypal payment)( www.ecyaya.com )
Tous shoes (paypal payment)( www.ecyaya.com )
Ugg shoes (paypal payment)( www.ecyaya.com )
Ice cream shoes (paypal payment)( www.ecyaya.com )
Sebago shoes (paypal payment)( www.ecyaya.com )
Lacoste shoes (paypal payment)( www.ecyaya.com )
Air force one shoes (paypal payment)( www.ecyaya.com )
TODS shoes (paypal payment)( www.ecyaya.com )
AF shoes (paypal payment)( www.ecyaya.com )
==============================================================================
TOPIC: 田●田●田 Cheap Wholesale Air Force One Shoes at www.fjrjtrade.com <
paypal payment>
http://groups.google.com/group/comp.lang.c++/t/5e9bf8a314eda877?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 12:28 am
From: "www.fjrjtrade.com"
田●田●田 Cheap Wholesale Air Force One Shoes at www.fjrjtrade.com <paypal
payment>
Welcome to visit www.fjrjtrade.com
Cheap Wholesale Air Force One Shoes
Wholesale Air Force One Shoes (paypal payment)
http://www.fjrjtrade.com/916-Air-Force-one.html
Wholesale Air Force One 25 Men (paypal payment)
http://www.fjrjtrade.com/1627-Air-Force-one-25%28M%29.html
Wholesale Air Force One Children (paypal payment)
http://www.fjrjtrade.com/1629-Air-force-One-Children.html
Wholesale Air Force One low (paypal payment)
http://www.fjrjtrade.com/1630-Air-Force-one%28low%29.html
Wholesale Air Force One M&W (paypal payment)
http://www.fjrjtrade.com/1631-Air-Force-One%28MW%29.html
Wholesale Air Force One Mid (paypal payment)
http://www.fjrjtrade.com/1632-Air-Force-one%28Mid%29.html
Wholesale Air Force One Mid Men (paypal payment)
http://www.fjrjtrade.com/1771-Air-Force-one-Mid-Man.html
Wholesale Air Force One Mid Women (paypal payment)
http://www.fjrjtrade.com/1772-Air-Force-one-Mid-Women.html
Wholesale Air Force One Women (paypal payment)
http://www.fjrjtrade.com/1633-Air-Force-One%28W%29.html
Website:
http://www.fjrjtrade.com
==============================================================================
TOPIC: std::map element in heap or stack?
http://groups.google.com/group/comp.lang.c++/t/c9389bfe3bb26d37?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 12:49 am
From: Michael Tsang
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
shuisheng wrote:
> Dear All,
>
> I am wondering the inserted element in std::map is located in heap or
> stack? For example
>
> std::map<int, double> a;
> a[0] = 3.14;
>
> The element of the map: pair<int, double>(0, 3.14) is in heap or
> stack? I think to know it is important for memory management.
>
> Thank you a lot ahead,
>
> Shuisheng
The C++ standard does not actually define the terms "heap" and "stack". The
only part which the standard uses "stack" is "stack unwinding", which is
related to exception handling. Consult the implementation documentation to
know how std::map works.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAks1ziAACgkQG6NzcAXitM/uawCcDEW+OOnxcPp+e0DpMYDeg8ie
nZEAn3TDMhd+/CP7NKRQtMYMpeSaAwLo
=Nb5w
-----END PGP SIGNATURE-----
==============================================================================
TOPIC: Exception Misconceptions: Exceptions are for unrecoverable errors.
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
==============================================================================
== 1 of 12 ==
Date: Sat, Dec 26 2009 1:36 am
From: peter koch
On 24 Dec., 12:01, ta...@mongo.net (tanix) wrote:
> In article <e5f9f274-0663-4563-bc4d-feaa1d858...@e27g2000yqd.googlegroups.com>, peter koch <peter.koch.lar...@gmail.com> wrote:
>
> >On 23 Dec., 23:51, Kaz Kylheku <kkylh...@gmail.com> wrote:
> >> On 2009-12-22, James Kanze <james.ka...@gmail.com> wrote:
>
> >> > And there can be other issues besides leaking. =A0In the end,
> >> > you've got to ensure internal consistency for all possible
> >> > control flows. =A0When some of the possible control flows are the
> >> > result of an exception, then this requirement is called
> >> > exception safety.
>
> >> Right; for instance failing to unlock a mutex, or roll
> >> back a transaction, aren't resource leaks.
>
> >Yes it is. A mutex held is also a ressource, and so is a transaction.
> >Both should be wrapped in a class having appropriate destructor
> >semantics.
>
> Yup.
>
> You have to unwind EVERYTHING, no matter how small it is.
> Otherwise, sooner or later your box will run out of steam.
You have to unwind everything in any language. By unwinding it in the
destructor you only write it once and you dont have to have have
special code for exceptions. Contrast this to Java: here you need the
code explicitly present in every function using the feature.
/Peter
== 2 of 12 ==
Date: Sat, Dec 26 2009 4:35 am
From: tanix@mongo.net (tanix)
In article <hh43ed$n8s$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>Kaz Kylheku wrote:
>> On 2009-12-25, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>>> tanix wrote:
>>>>> Virtual machines are always slower then real machines....
>>>> This is a blanket statement by someone who is obscessed with
>>>> machine cycles while his grand piece of work is not even worth
>>>> mentioning, I'd say.
>>> Well, I've started and stopped application which controlled Shanghai
>>> airptort back in 1993.
>>
>> This is inconsistent with the observation that you write bullshit
>> that we might expect from someone who was /born/ in 1993.
>
>Well, that depends...I was born in 68'.
>
>Let me show you one thing:
>
>Number of nodes: 5855000
>Timer: initial randomize: 0.818023
>Timer: merge_sort: 5.558880
>Timer: randomize after merge: 1.201952
>Timer: radix_sort: 2.021901
>Timer: randomize after radix: 1.470415
>Timer: quick_sort after radix: 3.805699
>vnode size : 5855000
>Timer: quick_sort nodes by address: 0.730361
>Timer: quick_sort: 0.505779
>Timer: randomize after quick: 0.911052
>cummulative result:
>----------------------------------
>initial randomize: 3.470863
>merge: 21.176704 randomize: 5.611846
>radix: 8.425690 randomize: 6.397170
>quick sort nodes by address: 3.909824 > vector<void*> quick sort then
>fill linked list with nodes sorted by address
>quick no address sort after radix: 15.180166 > unoptimized linked list,
>, nodes are not sorted by address
>quick: 2.297783 randomize: 4.075525 > nodes are sorted by address....
>7 times faster same algorithm, almost 6 million nodes
>Pt count created:999999
>true
>true
>qsort:0.06568 > this is cache optimized quick sort of million elements
>vector
>sort:0.134283 > this is sort from gcc lib
>lqsort:0.19908 > this is cache optimized sort of linked list of million
>elements
>lsort:0.437295 > this is linked list sort from gcc's lib
>Pt count:0
Hey, cool. I like that one. Only if I could understand
what it means.
>Which virtual machine can perform crucial cache optimizations?
Sorry. I donnow. You just blew my stack!
:--}
>Greets
--
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 12 ==
Date: Sat, Dec 26 2009 4:41 am
From: James Kanze
On Dec 24, 10:56 am, peter koch <peter.koch.lar...@gmail.com> wrote:
> On 23 Dec., 23:51, Kaz Kylheku <kkylh...@gmail.com> wrote:
> > On 2009-12-22, James Kanze <james.ka...@gmail.com> wrote:
> > > And there can be other issues besides leaking. In the
> > > end, you've got to ensure internal consistency for all
> > > possible control flows. When some of the possible control
> > > flows are the result of an exception, then this
> > > requirement is called exception safety.
> > Right; for instance failing to unlock a mutex, or roll back
> > a transaction, aren't resource leaks.
> Yes it is. A mutex held is also a ressource, and so is a
> transaction. Both should be wrapped in a class having
> appropriate destructor semantics.
A mutex probably should be considered a resource, but a
transaction? If the transaction is really a concrete object,
perhaps, but what if it is just an invariant that is temporarily
broken. (A good example of this would be a simple
implementation of shared_ptr. Boost goes to a lot of effort to
ensure that shared_ptr always leaves the program in coherent
state, but given that there are two dynamic allocations
involved, it requires careful consideration to ensure exception
safety.)
--
James Kanze
== 4 of 12 ==
Date: Sat, Dec 26 2009 4:47 am
From: tanix@mongo.net (tanix)
In article <20091225195850.746@gmail.com>, Kaz Kylheku <kkylheku@gmail.com> wrote:
>On 2009-12-25, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Dec 23, 11:21 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>> tanix wrote:
>>>>> In article <hgskgk$kc...@news.albasani.net>, Vladimir Jovic
> <vladasp...@gmail.com> wrote:
>>>>> C++ would probably be benefited tremendously if it adopted some
>>>>> of the central Java concept, such as GC, threads and GUI.
>>>
>>>> GC is heavy performance killer especially on multiprocessor systems
>>>> in combination with threads....it is slow, complex and inefficient...
>>>
>>> Obviously, you've never actually measured. A lot depends on the
>>> application, but typically, C++ with garbage collection runs
>>> slightly faster than C++ without garbage collection. Especially
>>> in a multi-threaded envirionment,
>>
>> How that can possibly be?
>
>How it can be is that surprising truths in the world don't take a pause
>so that morons can catch up.
Wow! That looks like a wresting arena!
:--}
>> GC kills all threads when it has
>> to collect?
>Big news: stopping threads using the scheduler is more efficient than
>throwing locks or atomic instructions in their execution path.
Kewl argument.
>What's more efficient: pausing a thread once in a long while, or having
>it constantly trip over some atomic increment or decrement, possibly
>millions of times a second?
>> Or it can magically sweep through heap,stack,bss
>> etc and scan without locking all the time or stopping program?
>The job of GC is to find and reclaim unreachable objects.
That's what I though. But who knows. May be there is some magic to it.
:--}
>When an object becomes unreachable, it stays that way. A program does
>not lose a reference to an object, and then magically recover the
>reference. Thus, in general, garbage monotonically increases as
>computation proceeds.
>This means that GC can in fact proceed concurrently with the
>application. The only risk is that the program will generate more
>garbage while GC is running, which the GC will miss---objects which GC
>finds to be reachable became unreachable before it completes.
>But that's okay; they will be found next time.
>
>This is hinted at in the ``snapshot mark-and-sweep'' paragraph
>in the GC algorithms FAQ.
>
> http://www.iecc.com/gclist/GC-algorithms.html
>
>> Explain to me how?
>
>Go study garbage collection. There is lots of literature there.
>
>It's not a small, simple topic.
>
>> Manual deallocation does not have to lock at all....
>WTF are you stuipd?
>Firstly, any comparison between GC and manual deallocation is moronic.
Well, kinda blunt way of putting it, but I'd have to agree.
>In order to invoke manual deallocation, the program has to be sure
>that the object is about to become unreachable, so that it does
>not prematurely delete an object that is still in use. Moreover,
>the program has to also ensure that it eventually identifies all objects
>that are no longer in use. I.e. by the time it calls the function, the
>program has already done exactly the same the job that is done by the
>garbage collector: that of identifying garbage.
>/Both/ manual deallocation and garbage collection have to recycle
>objects somehow; the deallocation part is a subset of what GC does.
>(Garbage collectors integrated with C in fact call free on unreachable
>objects; so in that case it is obvious that the cost of /just/ the call
>to free is lower than the cost of hunting down garbage /and/ calling
>free on it!)
>
>The computation of an object lifetime is not cost free, whether it
>is done by the program, or farmed off to automatic garbage collection.
>
>Your point about locking is naively wrong, too. Memory allocators which
>are actually in widespread use have internal locks to guard against
>concurrent acces by multiple processors. Even SMP-scalable allocators
>like Hoard have locks. See, the problem is that even if you shunt
>allocation requests into thread-local heaps, a piece of memory may be
>freed by a different thread from the one which allocated it. Thread A
>allocates an object, thread B frees it. So a lock on the heap has to be
>acquired to re-insert the block into the free list.
--
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.
== 5 of 12 ==
Date: Sat, Dec 26 2009 5:02 am
From: tanix@mongo.net (tanix)
In article <hh491l$uig$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>Kaz Kylheku wrote:
>> On 2009-12-25, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>>> James Kanze wrote:
>>>> On Dec 23, 11:21 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>>> tanix wrote:
>>>>>> In article <hgskgk$kc...@news.albasani.net>, Vladimir Jovic
> <vladasp...@gmail.com> wrote:
>>>>>> C++ would probably be benefited tremendously if it adopted some
>>>>>> of the central Java concept, such as GC, threads and GUI.
>>>>> GC is heavy performance killer especially on multiprocessor systems
>>>>> in combination with threads....it is slow, complex and inefficient...
>>>> Obviously, you've never actually measured. A lot depends on the
>>>> application, but typically, C++ with garbage collection runs
>>>> slightly faster than C++ without garbage collection. Especially
>>>> in a multi-threaded envirionment,
>>> How that can possibly be?
>>
>> How it can be is that surprising truths in the world don't take a pause
>> so that morons can catch up.
>>
>>> GC kills all threads when it has
>>> to collect?
>>
>> Big news: stopping threads using the scheduler is more efficient than
>> throwing locks or atomic instructions in their execution path.
>>
>Well, stopping threads by using scheduler or any other means
>while they work is same or worse as throwing locks or atomic
>instructions in excetion path....
>Actually this is I said already. Simplest way to perform garbage
>collection is to pause program scan references then continue program...
>
>> What's more efficient: pausing a thread once in a long while, or having
>> it constantly trip over some atomic increment or decrement, possibly
>> millions of times a second?
>
>Atomic increment/ decrement costs nothing if nothing is locked....
>So there is actually small probability that that will happen
>because usually there are not many objects referenced from multiple
>threads.
>
>
>>
>>> Or it can magically sweep through heap,stack,bss
>>> etc and scan without locking all the time or stopping program?
>>
>> The job of GC is to find and reclaim unreachable objects.
>
>Exactly.
>
>>
>> When an object becomes unreachable, it stays that way. A program does
>> not lose a reference to an object, and then magically recover the
>> reference. Thus, in general, garbage monotonically increases as
>> computation proceeds.
>>
>> This means that GC can in fact proceed concurrently with the
>> application.
>
>Oonly after it finds unreferenced objects...
>
> The only risk is that the program will generate more
>> garbage while GC is running, which the GC will miss---objects which GC
>> finds to be reachable became unreachable before it completes.
>> But that's okay; they will be found next time.
>
>So you will have 500 megabytes ram more used then with manual
>deallocation.... ;)
>
>>
>> This is hinted at in the ``snapshot mark-and-sweep'' paragraph
>> in the GC algorithms FAQ.
>>
>> http://www.iecc.com/gclist/GC-algorithms.html
>>
>>> Explain to me how?
>>
>> Go study garbage collection. There is lots of literature there.
>>
>> It's not a small, simple topic.
>>
>>> Manual deallocation does not have to lock at all....
>>
>> WTF are you stuipd?
>
>Stupid?
>
>>
>> Firstly, any comparison between GC and manual deallocation is moronic.
>
>Of course, manual deallocation does not have to pause
>complete program...
>
>>
>> In order to invoke manual deallocation, the program has to be sure
>> that the object is about to become unreachable, so that it does
>> not prematurely delete an object that is still in use.
>
>Hey. delete p just frees block of memory. That work is not that
>complicated...
Yes it is.
What happens AFTER is has been "freed" as it looks to you?
Can you tell me?
> Moreover,
>> the program has to also ensure that it eventually identifies all objects
>> that are no longer in use. I.e. by the time it calls the function, the
>> program has already done exactly the same the job that is done by the
>> garbage collector: that of identifying garbage.
>What are you talking about?
>> /Both/ manual deallocation and garbage collection have to recycle
>> objects somehow; the deallocation part is a subset of what GC does.
>Yup. GC does much more deallocation part can be done concurrently.
>That's why manual deallocation will always be more efficeint
>and faster.
>Look when I say free(p) it is just simple routine....
But what is happening on the O/S level AFTER that?
What is your overall performance as a SYSTEM
and not just some local view of it?
You see, what counts is the END result.
How long does it take user to wait for response.
How long does it take for your program to continue its main operation.
And NOT how long does it take YOU to return from free() call.t
That is just a very local and a primitive view on the system
I'd have to say. I simply have no choice.
>> (Garbage collectors integrated with C in fact call free on unreachable
>> objects; so in that case it is obvious that the cost of /just/ the call
>> to free is lower than the cost of hunting down garbage /and/ calling
>> free on it!)
>?
>> The computation of an object lifetime is not cost free, whether it
>> is done by the program, or farmed off to automatic garbage collection.
>> Your point about locking is naively wrong, too. Memory allocators which
>> are actually in widespread use have internal locks to guard against
>> concurrent acces by multiple processors.
>
>Of course.
>
> Even SMP-scalable allocators
>> like Hoard have locks.
>
>Of course.
Well, so it means that you can not just look at the pinhole
(of free() call return time as overall performance)
> See, the problem is that even if you shunt
>> allocation requests into thread-local heaps, a piece of memory may be
>> freed by a different thread from the one which allocated it.
>I have written such allocator...
> Thread A
>> allocates an object, thread B frees it. So a lock on the heap has to be
>> acquired to re-insert the block into the free list.
>Lock operation is very short and collision between two thread may pause
>one or two threads. But other will continue to work. unlike with
>gc which will completely pause program for sure.
Well, too bad we are still at it.
You see, to me the program performance translates in to run time
of some more or less complex operation to complete.
What I care about is not how many time my program "frezes" for so
many microseconds, but how long will it take me to comple my run.
If it takes me 4 hours, it is one thing.
If it takes me 4 hrs. and 10 minues, that is nothing to even mention.
But if it takes me 5 hrs, I'd start scratching my cockpit.
But not yet.
But when it takes me 6 hrs vs. 4, I'd definetely start looking
at some things.
>Greets!
--
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.
== 6 of 12 ==
Date: Sat, Dec 26 2009 5:05 am
From: tanix@mongo.net (tanix)
In article <20091225214028.996@gmail.com>, Kaz Kylheku <kkylheku@gmail.com> wrote:
>On 2009-12-25, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Dec 24, 10:11 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>> tanix wrote:
>>>>> In article <hguelj$k4...@news.albasani.net>, Branimir Maksimovic
> <bm...@hotmail.com> wrote:
>>>
>>> [...]
>>>> Memory managment is not a problem. You can implement GC, for
>>>> any apllication even in assembler. Reference counting is
>>>> simple form of gc and works well in c++ because of RAII.
>>>
>>> Reference counting doesn't work in C++, because of cycles. And
>>> reference counting is very, very slow compared to the better
>>> garbage collector algorithms.
>>>
>> Hm, have you ever head cycles? In my long experience I never
>> had cyclic references...
>> Reference counting can;t be slow because it does not have
>> to lock all threads
>
>Reference counting blocks the calling thread on an atomic increment
>or decrement operation whenever the reference count must be manipulated.
>
>Reference counting generates bus traffic. Whenever a refcount field is
>written, the corresponding cache line is now dirty on the local
>processor and must be updated to the other processors.
>
>Refcounting forces garbage objects to be visited one by one before they
>are reclaimed, in a random order, and possibly more than once! An object
>with refcount 42 will in general be visited 42 times before 42
>references can be dropped.
>
>Someone recently remarked in the comp.lang.lisp newsgroup that a
>a particular historic Lisp implementation, which used reference counting
>rather than real GC, sometimes fell into such a long pause in
>processing a dropped reference that frustrated programmers would just
>reboot the system!!!
>
>See when you drop a refcount on an object and it reaches zero, you are
>not done. That object has pointers to other objects, and /their/
>references have to be dropped. Refcounting does not eliminate the
>fact that a graph is being walked.
>
>But reference counting is the dumbest, slowest way of hunting down garbage.
What a pleasure to read this kind of stuff, I tellya.
--
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.
== 7 of 12 ==
Date: Sat, Dec 26 2009 5:11 am
From: tanix@mongo.net (tanix)
In article <hh49qn$vv6$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>Kaz Kylheku wrote:
>> On 2009-12-25, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>>> James Kanze wrote:
>>>> On Dec 24, 10:11 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>>> tanix wrote:
>>>>>> In article <hguelj$k4...@news.albasani.net>, Branimir Maksimovic
> <bm...@hotmail.com> wrote:
>>>> [...]
>>>>> Memory managment is not a problem. You can implement GC, for
>>>>> any apllication even in assembler. Reference counting is
>>>>> simple form of gc and works well in c++ because of RAII.
>>>> Reference counting doesn't work in C++, because of cycles. And
>>>> reference counting is very, very slow compared to the better
>>>> garbage collector algorithms.
>>>>
>>> Hm, have you ever head cycles? In my long experience I never
>>> had cyclic references...
>>> Reference counting can;t be slow because it does not have
>>> to lock all threads
>>
>> Reference counting blocks the calling thread on an atomic increment
>> or decrement operation whenever the reference count must be manipulated.
>
>Hm, it does block nothing, actually it can happen if two or more
>threads share same object which is in practice rare case.
>And in same time add/release references.
>Actually typical scenario is auto_ptr not shared ptr when
>one thread passes object to the other.
>
>>
>> Reference counting generates bus traffic. Whenever a refcount field is
>> written, the corresponding cache line is now dirty on the local
>> processor and must be updated to the other processors.
>
>Reference counting generates much less bus traffic then stopping
>program and scanning memory. In order for GC to reach pointers,
>it must ensure that every pointer in application
>is flushed in memory, which is ....much much worse then
>reference counting... Actually scanning memory generates
>bus traffic if scan area, is larger than cache, which
>is usually case since real world application heap
>is usually larger than available cache.
>
>>
>> Refcounting forces garbage objects to be visited one by one before they
>> are reclaimed, in a random order, and possibly more than once! An object
>> with refcount 42 will in general be visited 42 times before 42
>> references can be dropped.
>
>42 references , unlikely... If it had million references, we could
>be worried, but 42;)
>
>
>>
>> Someone recently remarked in the comp.lang.lisp newsgroup that a
>> a particular historic Lisp implementation, which used reference counting
>> rather than real GC, sometimes fell into such a long pause in
>> processing a dropped reference that frustrated programmers would just
>> reboot the system!!!
>
>Hm. Lisp? This is shared_ptr we talking about...
>
>
>>
>> See when you drop a refcount on an object and it reaches zero, you are
>> not done. That object has pointers to other objects, and /their/
>> references have to be dropped. Refcounting does not eliminate the
>> fact that a graph is being walked.
>
>You are wrong. shared_ptr's are usually used externally, auto_ptr's are
>usually used internally. or simply new in constructor/delete
>in destructor.
>
>
>>
>> But reference counting is the dumbest, slowest way of hunting down garbage.
>
>?
>
>Greets
Jeez. I feel jealous. I wish this is the kind of stuff is the kind
of thing I'd have to worry.
--
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.
== 8 of 12 ==
Date: Sat, Dec 26 2009 5:12 am
From: tanix@mongo.net (tanix)
In article <20091225215011.599@gmail.com>, Kaz Kylheku <kkylheku@gmail.com> wrote:
>On 2009-12-25, tanix <tanix@mongo.net> wrote:
>> In article <hh3dco$osh$1@news.albasani.net>, Branimir Maksimovic
> <bmaxa@hotmail.com> wrote:
>> Looks like it is a matter of life and death to you.
>> But I doubt you can win this argument.
>
>I doubt you can convince this village bohunk that he can possibly
>lose an argument.
Jeez. Time to get a bear I guess to mellow out the edges!
:--}
--
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.
== 9 of 12 ==
Date: Sat, Dec 26 2009 5:18 am
From: tanix@mongo.net (tanix)
In article <hh49sd$vv6$2@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>Kaz Kylheku wrote:
>> On 2009-12-25, tanix <tanix@mongo.net> wrote:
>>> In article <hh3dco$osh$1@news.albasani.net>, Branimir Maksimovic
> <bmaxa@hotmail.com> wrote:
>>> Looks like it is a matter of life and death to you.
>>> But I doubt you can win this argument.
>>
>> I doubt you can convince this village bohunk that he can possibly
>> lose an argument.
>
>Argument can be won by argument.
Well. Not necessarily. Not that I am trying to argue with this.
Some arguments are much more complex then they might look when
you look at the whole picuture and your main interests or points
of view, and there are ALL sorts of ways you may look at some "problem".
Salesman wants sales, vp wants performance, CEO wants redused cost,
engineer wants code "correctness", marketing guy wants big bang,
accountant wants his books to reconcile cause you guys are wasting
too much, and on and on and on.
Which "argument" is "correct"?
Secondly, do you even WANT to see something that differs
from what you are used to?
>Greets
--
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.
== 10 of 12 ==
Date: Sat, Dec 26 2009 5:22 am
From: tanix@mongo.net (tanix)
In article <bb09f18f-ce17-48b8-923d-5f72cd5bfefa@d20g2000yqh.googlegroups.com>, peter koch <peter.koch.larsen@gmail.com> wrote:
>On 24 Dec., 12:01, ta...@mongo.net (tanix) wrote:
>> In article
> <e5f9f274-0663-4563-bc4d-feaa1d858...@e27g2000yqd.googlegroups.com>, peter
> koch <peter.koch.lar...@gmail.com> wrote:
>>
>> >On 23 Dec., 23:51, Kaz Kylheku <kkylh...@gmail.com> wrote:
>> >> On 2009-12-22, James Kanze <james.ka...@gmail.com> wrote:
>>
>> >> > And there can be other issues besides leaking. =A0In the end,
>> >> > you've got to ensure internal consistency for all possible
>> >> > control flows. =A0When some of the possible control flows are the
>> >> > result of an exception, then this requirement is called
>> >> > exception safety.
>>
>> >> Right; for instance failing to unlock a mutex, or roll
>> >> back a transaction, aren't resource leaks.
>>
>> >Yes it is. A mutex held is also a ressource, and so is a transaction.
>> >Both should be wrapped in a class having appropriate destructor
>> >semantics.
>>
>> Yup.
>>
>> You have to unwind EVERYTHING, no matter how small it is.
>> Otherwise, sooner or later your box will run out of steam.
>
>You have to unwind everything in any language. By unwinding it in the
>destructor you only write it once
Looks nice on paper. I agree.
> and you dont have to have have
>special code for exceptions.
Huh?
> Contrast this to Java: here you need the
>code explicitly present in every function using the feature.
Sorry. I don't follow this.
>/Peter
--
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.
== 11 of 12 ==
Date: Sat, Dec 26 2009 5:52 am
From: "Balog Pal"
"James Kanze" <james.kanze@gmail.com>
> A mutex probably should be considered a resource, but a
> transaction?
Sure. Actually I tend to replace the R in mozaiks from "resource" to
"responsibility". So everything looks uniform, resource alloc comes wih
responsibility to dealloc, mutex lock requires unlock, transaction opening
requires rollback or commit...
So you use the same tech -- the destructor sits there to carry out the
responsibility that is left over.
> If the transaction is really a concrete object,
> perhaps, but what if it is just an invariant that is temporarily
> broken.
For API-based transactions it is simple, call BeginTrans, and keep a bool to
track explicit Rollback or Commit was called.
For internal state transactions it is more complicated -- you record the
stepst taken so rollback can be arranged. Though that is the less suggested
method, I try to use create-then-swap wherever possible.
> (A good example of this would be a simple
> implementation of shared_ptr. Boost goes to a lot of effort to
> ensure that shared_ptr always leaves the program in coherent
> state, but given that there are two dynamic allocations
> involved, it requires careful consideration to ensure exception
> safety.)
Err, what is that "lot effort"? Placing allocations into local scoped_ptrs
then swap or relase them into members afterwards?
== 12 of 12 ==
Date: Sat, Dec 26 2009 6:06 am
From: tanix@mongo.net (tanix)
Hey guys, the thread:
Re: Exception Misconceptions: Exceptions are for unrecoverable errors.
has been fragmented as it has been split by some zombies
by inserting CR/LF and blanks into a subject line.
As a result, there are several threads, not one.
Would you change the subject when you follow up on these thread
so they all merge into one thread again?
Just remove all white speces after unrecoverable.
One thread has two blanks after unrecoverable, which makes it
a different thread.
--
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: 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 1 ==
Date: Sat, Dec 26 2009 2:05 am
From: Paavo Helde
"BGB / cr88192" <cr88192@hotmail.com> wrote in
news:hh3l5j$4o5$1@news.albasani.net:
>
> "Paavo Helde" <myfirstname@osa.pri.ee> wrote in message
> news:Xns9CEBD26804A1Epaavo256@216.196.109.131...
>> SRK <kumarsr@gmail.com> wrote in news:f45f3f70-d140-4b48-af0a-
>> 10f52eee8394@15g2000prz.googlegroups.com:
>>
>>> Hi folks,
>>> I am trying to read some data from a config file and want that data
>>> to be printed in formatted way foe example if I have this string in
>>> the config file - ABC PQR XYZ and want to display it like
>>>
>>> ABC
>>> PQR
>>> XYZ
>>>
>>> for that I have put the above mentioned string as ABC \nPQR \nXYZ
>>>
>>> But instead of displaying the next string on next line, when I print
>>> the data, it prints as ABC \nPQR \nXYZ.
>>
>> You need to convert two symbols (backslash and n) to a single symbol
>> (line-feed '\n').
>>
>> If this is not very performance-critical, you can do it in-place:
>>
>> std::string s = "ABC\\nPQR\\nXYZ\\n"; // contains backslash and n
>>
>> std::string::size_type k = 0;
>> while((k=s.find("\\n", k))!=s.npos) {
>> s.replace(k, 2, "\n");
>> }
>>
>> // s now contains linefeed characters instead.
>>
>
> or, maybe the good old char-pointers strategy:
> char tb[256]; //or whatever is the maximum sane length
This is a buffer overrun error waiting to happen (or being exploited). At
least one should check the length, or allocate a buffer long enough. In
this case this should be easy.
> char *s, *t;
>
> s=input; t=tb;
> while(*s)
> {
> if((*s=='\\') && (*(s+1)=='n'))
> { *t++='\n'; s+=2; continue; }
> *t++=*s++;
> }
> *t++=0;
>
>
> granted, one can debate whether or not this is good style in C++, ...
> but, should work ok.
This is a C solution, and assumes C strings (zero-terminated, no embedded
zeroes). Probably this is a harmless assumption, but nevertheless it is
slightly different, and makes the coding a bit more convenient (no extra
care needed when checking *(s+1)).
The same algorithm can be made to work with std::string as well of
course, by extracting the C-style string pointer via the c_str() member
function:
std::string input = ...
std::string output(input.length(), '\0');
if (!input.empty()) {
const char* s = input.c_str();
char* t = &output[0];
// C-style algorithm here...
output.resize(t-&output[0]);
}
Paavo
==============================================================================
TOPIC: Searching SourceForge
http://groups.google.com/group/comp.lang.c++/t/18c471574f99a91d?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Dec 26 2009 4:02 am
From: "zdumiony"
The question may seem silly but I want to ask how to search for SourceForge.
Home http://sourceforge.net/ changed interface. I search by keyword
narrowing the category. How do I find all the projects for the programming
language regardless of the keyword and category?
== 2 of 2 ==
Date: Sat, Dec 26 2009 5:05 am
From: Sherm Pendley
"zdumiony" <zdumiony@jestem.pl> writes:
> The question may seem silly but I want to ask how to search for SourceForge.
> Home http://sourceforge.net/ changed interface. I search by keyword
> narrowing the category. How do I find all the projects for the
> programming language regardless of the keyword and category?
I use a site-specific Google search for that kind of thing, such as:
<http://www.google.com/search?q=c%2B%2B+site%3Asourceforge.net>
sherm--
==============================================================================
TOPIC: Locale to Unicode Codepoint mapping?
http://groups.google.com/group/comp.lang.c++/t/0f87b730b24e407a?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Dec 26 2009 4:20 am
From: James Kanze
On Dec 25, 2:06 pm, "Peter Olcott" <NoS...@SeeScreen.com> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message
> news:991f32d8-319c-45ad-9b9c-12a7f2a3daef@s31g2000yqs.googlegroups.com...
> > On Dec 23, 6:27 pm, "Peter Olcott" <NoS...@SeeScreen.com>
> > wrote:
> >> I need to know the set of Unicode codepoints associated
> >> with every regional dialect of a human language. How can I
> >> go about finding this information?
> >www.unicode.org. Go to the code charts under the standard.
> > In general, for such things, look for the reference site.
> > This one is actually very well done, but even in the case of
> > those that are less well done, the reference is the
> > reference.
> I already studied these for many hours. They do not have what
> I need. I need to know the exact subset of Unicode code points
> that apply to a specific dialect of a specific language.
I doubt you'll find much more. I'm not even sure that "the
exact subset of Unicode code points that apply to a specific
dialect of a specific language" has a concrete meaning. Local
dialects generally don't have formal spellings, and different
authors treat them differently. And the formalized written
forms of languages tend to contain a lot of accents that only
show up in one or two words (e.g. "naïve" in English); trying to
root out all of those accents is probably a hopeless task.
> A superset of these will not do, I must have the minimum set
> of code points. This has to be known because the keyboard must
> know which glyphs to produce.
What does the keyboard have to do with this? It's a known
problem that the keyboard doesn't have enough keys for most
languages, and that various alternatives have been developed.
(Even in English: does your keyboard have "“"? It's a
standard character in both American and British English.)
> I am working on internationalizing this system:
> www.OCR4Screen.com
Wouldn't that entail understanding all characters, even if they
wouldn't normally be used in the current locale?
--
James Kanze
== 2 of 2 ==
Date: Sat, Dec 26 2009 4:36 am
From: James Kanze
On Dec 25, 3:59 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> "Peter Olcott" <NoS...@SeeScreen.com> wrote in news:EMCdnTXL-
> 5ZSW6nWnZ2dnUVZ_qudn...@giganews.com:
[...]
> In any case, the local alphabete ultimately depends on the
> local national decisions and conventions - which characters
> are considered to belong to the national character set, and
> which are not. This can change over time.
Exactly. It can also vary regionally---Swiss German doesn't use
exactly the same character set as standard German---, and
culturally---if nothing else, most languages use a different set
of characters when the data must be entered via a standard
keyboard.
> > This has to be known because the keyboard must know which
> > glyphs to produce.
> Knowing what characters some vendor has decided to include in
> a keyboard mapping for given language might help of course.
> However, this must not be relied on too much.
Especially as, as mentionned above, keyboard input often follows
different rules: in French, the standard double quotes would be
« ... » ; when entering text from a keyboard, " ... " is
considered acceptable (although normally, French doesn't have a
" character).
> > I am working on internationalizing this system:
> > www.OCR4Screen.com
> For OCR-like tasks one also has to consider that text can
> often contain foreign characters and even words. For example,
> in Russian technical texts it is common to type technical
> terms in Latin alphabete. To make things worse, there are many
> symbols which have the same look in Cyrillic and in Latin, but
> correspond to different Unicode code points. Recognizing them
> correctly is no easy task.
> 5-minute Google search produced these pages, maybe these are of any help:
> http://developer.mimer.com/charts/index.tml
> http://www.evertype.com/alphabets/
Just a note, very relevant with regards to your previous comment
about changing over time: the list of characters for French in
the second doesn't include ü. Which is present in words like
aigüe. At least since the last spelling reforme---before, one
would have written aiguë. (But ü was still present in names
like Saül. And ÿ, which is given, only occurs in five or six
proper nouns---all the names of small villages.)
--
James Kanze
==============================================================================
TOPIC: Why does this crash?
http://groups.google.com/group/comp.lang.c++/t/09275db5bcbd6f3b?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 4:58 am
From: mzdude
On Dec 25, 3:12 pm, JoeC <enki...@yahoo.com> wrote:
> I am loading a BYTE array into a vector in an object. Then I want to
> reverse the order of the array in the vector.
>
> static
> BYTE Bits[] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> 0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,0,
> ...
>
> cbm2 = new colorBitmap(Bits,16*16,colors, 12);
>
> colorBitmap::colorBitmap(BYTE * b, int n1, BYTE* rgb, int n2){
>
> int lp;
>
> create();
>
> for(lp = 0; lp != n1; lp++)
> bitData.push_back(*b++);
where is the closing brace for the ctor? What is create()?
limit the scope of lp to the for loop.
>
> void colorBitmap::flipBitmap(){
>
> std::vector<BYTE>temp;
> for(int lp = 0; lp != bitData.size();lp++) <-Fails
> temp.push_back(bitData[lp]);
>
what is bitData?
> bitData.clear();
>
> for(int lp = bitData.size(); lp !=0; lp--)
> bitData.push_back(temp[lp]);
>
> copy(bitData.end(), bitData.begin(), back_inserter(temp)); Fails
> as well.
should be a reverse_copy().
>
> What can I do to work with a vector in a way the program will not
> crash?
In the future posting the smallest complete example will
help us to help you.
Also spend some time familiarizing youself with the
algorithms in the standard library.
std::reverse() will greatly simplify your task.
==============================================================================
TOPIC: Event dispatcher, hooks and Interceptor pattern for C++?
http://groups.google.com/group/comp.lang.c++/t/a82e5c39e2fe1f12?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 6:50 am
From: Lothar Behrens
Are there any documents available about the interceptor pattern?
I have a class that registers an event handler to be called on a given
event. The interceptor pattern then should be used to add restrictions
or other things to the function.
I could implement that in my dispatcher class (like an event
dispatcher pattern), but I think there are patterns also usable for
this issue in C++.
I have cases where I register event handlers per class and others per
instance (by adding the pointer to the event name). Thus when I have
an event handler per instance, but a interceptor
per class I have to strip the pointer from the event name (after
resolving it from the number) to locate the handler correctly.
Any help out there?
Thanks
Lothar
==============================================================================
TOPIC: ┈━═☆ Cheap wholesale Lv Jean, True Relig Jean, Laguna Beach Jean, G-
star Jean ect at website: www.fjrjtrade.com <Paypal Payment>
http://groups.google.com/group/comp.lang.c++/t/6fe10cb989d88f0e?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 6:57 am
From: "www.fjrjtrade.com"
┈━═☆ Cheap wholesale Lv Jean, True Relig Jean, Laguna Beach Jean, G-
star Jean ect at website: www.fjrjtrade.com <Paypal Payment>
Cheap wholesale Jeans
http://www.fjrjtrade.com/1261-Jean.html
Cheap wholesale A&F Jean
http://www.fjrjtrade.com/2169-AF-Jean.html
Cheap wholesale Artful Dodger Jean
http://www.fjrjtrade.com/1954-Artful-Dodger-Jean.html
Cheap wholesale BBC Jean
http://www.fjrjtrade.com/1955-BBC-Jean.html
Cheap wholesale Cavalli Jean
http://www.fjrjtrade.com/1956-Cavalli-Jean.html
Cheap wholesale Iceberg Jean Man
http://www.fjrjtrade.com/2172-Iceberg-Jean-Man.html
Cheap wholesale Kanji Jean Man
http://www.fjrjtrade.com/2173-Kanji-Jean-Man.html
Cheap wholesale Laguna Beach Jean
http://www.fjrjtrade.com/1951-Laguna-Beach-Jean.html
Cheap wholesale Michael Jackson Jean Man
http://www.fjrjtrade.com/2174-Michael-Jackson-Jean-Man.html
Cheap wholesale Prada Jean
http://www.fjrjtrade.com/1957-Prada-Jean.html
Cheap wholesale RMC Jean
http://www.fjrjtrade.com/1958-RMC-Jean.html
Cheap wholesale Robins Jean Man
http://www.fjrjtrade.com/2175-Robins-Jean-Man.html
Cheap wholesale Roca Wear Jean
http://www.fjrjtrade.com/1959-Roca-Wear-Jean.html
Cheap wholesale ZEN Jean
http://www.fjrjtrade.com/1950-ZEN-Jean.html
Cheap wholesale Affliction Jean
http://www.fjrjtrade.com/1262-Affliction-Jean.html
Cheap wholesale Akademiks Jean
http://www.fjrjtrade.com/1263-Akademiks-Jean.html
Cheap wholesale Armani Jean
http://www.fjrjtrade.com/1264-Armani-Jean.html
Cheap wholesale Bape Jean
http://www.fjrjtrade.com/1265-Bape-Jean.html
Cheap wholesale Christian Audigier Jean
http://www.fjrjtrade.com/1267-Christian-Audigier-Jean.html
Cheap wholesale Coogi Jean
http://www.fjrjtrade.com/1268-Coogi-Jean.html
Cheap wholesale Crown Holder Jean
http://www.fjrjtrade.com/1269-Crown-Holder-Jean.html
Cheap wholesale D&G Jean
http://www.fjrjtrade.com/1270-DG-Jean.html
Cheap wholesale Diesel Jean
http://www.fjrjtrade.com/1271-Diesel-Jean.html
Cheap wholesale Ecko Unltd Jean
http://www.fjrjtrade.com/1272-Ecko-Unltd-Jean.html
Cheap wholesale Ed Hardy Jean
http://www.fjrjtrade.com/1273-Ed-Hardy-Jean.html
Cheap wholesale Evisu Jean
http://www.fjrjtrade.com/1274-Evisu-Jean.html
Cheap wholesale G-Star Jean
http://www.fjrjtrade.com/1275-G-Star-Jean.html
Cheap wholesale Gucci Jean
http://www.fjrjtrade.com/1276-Gucci-Jean.html
Cheap wholesale LEVI'S Jean
http://www.fjrjtrade.com/1281-LEVIS-Jean.html
Cheap wholesale LRG Jean
http://www.fjrjtrade.com/1282-LRG-Jean.html
Cheap wholesale LV Jean
http://www.fjrjtrade.com/1283-LV-Jean.html
Cheap wholesale Rock Jean
http://www.fjrjtrade.com/1284-Rock-Jean.html
Cheap wholesale True Relig Jean
http://www.fjrjtrade.com/1285-True-Relig-Jean.html
Cheap wholesale Versace Jean
http://www.fjrjtrade.com/1286-Versace-Jean.html
More items at website:
http://www.fjrjtrade.com
==============================================================================
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