http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* ♣Y(^o^)Y♣ 2009 Wholesale cheap Gucci shoes at www.ecyaya.com [paypal] - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ccea7aca103c4911?hl=en
* Design patterns - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?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
* "Reusable" operator overloading for enum? - 6 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/981ab2c7a0c2c5ff?hl=en
* C++ jobs down another 40% - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
* Gigantic Class - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/b3756783d92fd56a?hl=en
* Hot sale Air force one shoes, Nike air max, Nike Shox paypal payment free
shipping (www.vipchinatrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/c3a39c1719ab4760?hl=en
* Exception Misconceptions: Exceptions are for unrecoverable errors. - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
* ♣°ω°♣ cheap wholesale pants belts bikinis underwear at www.ecyaya.com - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/7fe8ea65ab863cc8?hl=en
* Saving a binary file into a string - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/ddc89ddf30293133?hl=en
* Discount wholesale Chanel Handbags Miumiu,LV,Juicy,Gucci, Fendi,Burberry,D&G,
Jimmy Choo(www.vipchinatrade.com) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/126c1693082e7a31?hl=en
==============================================================================
TOPIC: ♣Y(^o^)Y♣ 2009 Wholesale cheap Gucci shoes at www.ecyaya.com [paypal]
http://groups.google.com/group/comp.lang.c++/t/ccea7aca103c4911?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 27 2009 12:21 am
From: hero
♣Y(^o^)Y♣ 2009 Wholesale cheap Gucci shoes at www.ecyaya.com [paypal]
Men size 40,41,42,43,44,45,46. Women size 36,37,38,39,40.
High quality wholesale Air Force One shoes, Nike Jordan, Nike,Air
Max,
Nike Shox, Puma Shoes, Nike shoes, Adidas Shoes, Christian Louboutin,
Chanel Shoes, Coach Shoes, D&G Shoes, Dior Shoes, ED Hardy Shoes,
Evisu Shoes, Fendi Shoes, AFF shoes, Bape shoes, Gucci Shoes, Hogan
shoes, Bikkembergs Shoes, Dsquared Shoes, LV Shoes, Timberland Shoes,
Boss shoes, Versace Shoes, Prada Shoes, Lacoste Shoes, Mauri Shoes,
DC
shoes ect. Details at website www.ecyaya.com.
Cheap wholesale shoes
www.ecyaya.com
Cheap wholesale Gucci shoes
http://www.ecyaya.com/category-582-b0-Gucci-Shoes.html
Cheap wholesale Gucci Boots
http://www.ecyaya.com/category-588-b0-GUCCI-Boots.html
Cheap wholesale Gucci Women High
http://www.ecyaya.com/category-587-b0-Gucci-Shoes-Women-High.html
Cheap wholesale Gucci Men High
http://www.ecyaya.com/category-586-b0-Gucci-Shoes-Man-High.html
Cheap wholesale Gucci Men shoes
http://www.ecyaya.com/category-583-b0-Gucci-Shoes-Man.html
Cheap wholesale Gucci Women shoes
http://www.ecyaya.com/category-584-b0-Gucci-Shoes-Women.html
Cheap wholesale more shoes at Website:
www.ecyaya.com
==============================================================================
TOPIC: Design patterns
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Dec 27 2009 1:05 am
From: Joshua Maurice
On Dec 26, 7:35 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> Joshua Maurice wrote:
> > On Dec 26, 3:01 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> >> Stefan Ram wrote:
> >>> Jonathan Lee <cho...@shaw.ca> writes:
> >>>> But I'm having a small problem finishing it. Anyone know of a
> >>>> pattern for the above problem?
> >>> Sure, just implement it as a GPS.
> >>>http://en.wikipedia.org/wiki/General_Problem_Solver
> >> Hm, back in 1987. my math teacher showed us mathematical proof that
> >> algorithm for creating algorithms can;t possibly exist.
> >> It is based on proof that algorithm for proofs can;t possibly exits
> >> , too...http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
> >> That's why blue brain project is bound to fail.
> >> Because anything which is based on algorithm cannot
> >> be creative...
>
> > Interesting implications there. Almost brings a religious context to
> > the whole discussion. (That is, are humans "simple" chemical machines,
> > or do we possess a "soul"?) Suffice to say, you are greatly
> > simplifying the issues involved and jumping the gun.
>
> I think that this does not have to do anything with soul.
> Fact is that algorithm cannot think and that;s it.
> Human consciousness and intelligence does not works
> on algorithm. Plain fact. We can invent algorithm,
> but algorithm itself can;t produce previously
> unknown algorithm. But human brain can.
> This is mathematical fact....
Is it? Could you cite a published something which claims this? I
disagree with most of what you said. I do not agree that "algorithms
cannot think", nor "human consciousness and intelligence does not work
on an algorithm". Please go educate yourself some more, possibly
reading up on the Turing Test, and related thought experiments.
Also, how do you define "intelligence"? Something like the Turing
Test? What about the common thought experiment of the proverbial guy
in a big room running a very long algorithm, looking up through
millions and millions of pages of responses. Is "the room"
intelligent? Is the paper intelligent? Is there a difference between
the system and the constituent parts?
All of this is far from accepted fact, your stance or mine.
> > This is already so off-topic, but I suggest reading some good books on
> > evolution by natural selection.
> > Dawkin's The Greatest Show On Earth
>
> What does this topic have to do with evolution?
Our brain is a simple "algorithm", using the loosest definition of
algorithm. It may not be determinalistic, but there's no "magic" which
makes it something other than a chemical machine. (At least, that's my
world view.) (Where most people call that magic a "soul".) Evolution
explains how such a complex, interesting, and powerful algorithm came
to be.
== 2 of 3 ==
Date: Sun, Dec 27 2009 2:12 am
From: Branimir Maksimovic
Joshua Maurice wrote:
> On Dec 26, 7:35 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>> Joshua Maurice wrote:
>>> On Dec 26, 3:01 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>> Stefan Ram wrote:
>>>>> Jonathan Lee <cho...@shaw.ca> writes:
>>>>>> But I'm having a small problem finishing it. Anyone know of a
>>>>>> pattern for the above problem?
>>>>> Sure, just implement it as a GPS.
>>>>> http://en.wikipedia.org/wiki/General_Problem_Solver
>>>> Hm, back in 1987. my math teacher showed us mathematical proof that
>>>> algorithm for creating algorithms can;t possibly exist.
>>>> It is based on proof that algorithm for proofs can;t possibly exits
>>>> , too...http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
>>>> That's why blue brain project is bound to fail.
>>>> Because anything which is based on algorithm cannot
>>>> be creative...
>>> Interesting implications there. Almost brings a religious context to
>>> the whole discussion. (That is, are humans "simple" chemical machines,
>>> or do we possess a "soul"?) Suffice to say, you are greatly
>>> simplifying the issues involved and jumping the gun.
>> I think that this does not have to do anything with soul.
>> Fact is that algorithm cannot think and that;s it.
>> Human consciousness and intelligence does not works
>> on algorithm. Plain fact. We can invent algorithm,
>> but algorithm itself can;t produce previously
>> unknown algorithm. But human brain can.
>> This is mathematical fact....
>
> Is it? Could you cite a published something which claims this?
http://www.fact-index.com/m/ma/mathematical_logic.html
http://www.fact-index.com/s/se/second_order_logic.html
I
> disagree with most of what you said. I do not agree that "algorithms
> cannot think", nor "human consciousness and intelligence does not work
> on an algorithm". Please go educate yourself some more, possibly
> reading up on the Turing Test, and related thought experiments.
>
> Also, how do you define "intelligence"? Something like the Turing
> Test?
Intelligence is capability to find algorithm to solve some
problem. Therefore, if it is algorithm, it should be algorithm
that produces algorithm to solve particular problem.
So result would be algorithm. But since there is no algorithm
to proof validity of second order logic formulas, solution
is not based on algorithm, rather on intuition.
What about the common thought experiment of the proverbial guy
> in a big room running a very long algorithm, looking up through
> millions and millions of pages of responses. Is "the room"
> intelligent? Is the paper intelligent? Is there a difference between
> the system and the constituent parts?
>
> All of this is far from accepted fact, your stance or mine.
>
>>> This is already so off-topic, but I suggest reading some good books on
>>> evolution by natural selection.
>>> Dawkin's The Greatest Show On Earth
>> What does this topic have to do with evolution?
>
> Our brain is a simple "algorithm", using the loosest definition of
> algorithm. It may not be determinalistic, but there's no "magic" which
> makes it something other than a chemical machine. (At least, that's my
> world view.) (Where most people call that magic a "soul".) Evolution
> explains how such a complex, interesting, and powerful algorithm came
> to be.
I think that atheists are deluded by algorithmic machines into believing
that brain is such machine. From that point of view atheists are just
another form of religion, which leads science in wrong direction.
Greets
== 3 of 3 ==
Date: Sun, Dec 27 2009 6:16 am
From: tanix@mongo.net (tanix)
In article <hh7bu9$urq$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>Joshua Maurice wrote:
>> On Dec 26, 7:35 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>> Joshua Maurice wrote:
>>>> On Dec 26, 3:01 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>>>>> Stefan Ram wrote:
>>>>>> Jonathan Lee <cho...@shaw.ca> writes:
>>>>>>> But I'm having a small problem finishing it. Anyone know of a
>>>>>>> pattern for the above problem?
>>>>>> Sure, just implement it as a GPS.
>>>>>> http://en.wikipedia.org/wiki/General_Problem_Solver
>>>>> Hm, back in 1987. my math teacher showed us mathematical proof that
>>>>> algorithm for creating algorithms can;t possibly exist.
>>>>> It is based on proof that algorithm for proofs can;t possibly exits
>>>>> ,
> too...http://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems
>>>>> That's why blue brain project is bound to fail.
>>>>> Because anything which is based on algorithm cannot
>>>>> be creative...
>>>> Interesting implications there. Almost brings a religious context to
>>>> the whole discussion. (That is, are humans "simple" chemical machines,
>>>> or do we possess a "soul"?) Suffice to say, you are greatly
>>>> simplifying the issues involved and jumping the gun.
>>> I think that this does not have to do anything with soul.
>>> Fact is that algorithm cannot think and that;s it.
>>> Human consciousness and intelligence does not works
>>> on algorithm. Plain fact. We can invent algorithm,
>>> but algorithm itself can;t produce previously
>>> unknown algorithm. But human brain can.
>>> This is mathematical fact....
>>
>> Is it? Could you cite a published something which claims this?
>
>http://www.fact-index.com/m/ma/mathematical_logic.html
>http://www.fact-index.com/s/se/second_order_logic.html
>
>
> I
>> disagree with most of what you said. I do not agree that "algorithms
>> cannot think", nor "human consciousness and intelligence does not work
>> on an algorithm". Please go educate yourself some more, possibly
>> reading up on the Turing Test, and related thought experiments.
>>
>> Also, how do you define "intelligence"? Something like the Turing
>> Test?
>
>Intelligence is capability to find algorithm to solve some
>problem.
Sorry, I'd like to stay away from this, but can not.
Intelligence is NOT, and never EVER will be
"a capability to find algorithm to solve some problem"
This is the HIGHER order insult to Intelligence.
That is ALL I am interested in saying or even seeing
in THIS grade of crap.
Enough.
>Therefore, if it is algorithm, it should be algorithm
>that produces algorithm to solve particular problem.
>So result would be algorithm. But since there is no algorithm
>to proof validity of second order logic formulas, solution
>is not based on algorithm, rather on intuition.
>
> What about the common thought experiment of the proverbial guy
>> in a big room running a very long algorithm, looking up through
>> millions and millions of pages of responses. Is "the room"
>> intelligent? Is the paper intelligent? Is there a difference between
>> the system and the constituent parts?
>>
>> All of this is far from accepted fact, your stance or mine.
>>
>>>> This is already so off-topic, but I suggest reading some good books on
>>>> evolution by natural selection.
>>>> Dawkin's The Greatest Show On Earth
>>> What does this topic have to do with evolution?
>>
>> Our brain is a simple "algorithm", using the loosest definition of
>> algorithm. It may not be determinalistic, but there's no "magic" which
>> makes it something other than a chemical machine. (At least, that's my
>> world view.) (Where most people call that magic a "soul".) Evolution
>> explains how such a complex, interesting, and powerful algorithm came
>> to be.
>
>I think that atheists are deluded by algorithmic machines into believing
>that brain is such machine. From that point of view atheists are just
>another form of religion, which leads science in wrong direction.
>
>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.
==============================================================================
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: Sun, Dec 27 2009 1:54 am
From: Lothar Behrens
On 27 Dez., 02:21, Pavel
<pauldontspamt...@removeyourself.dontspam.yahoo> wrote:
> Lothar Behrens wrote:
> > 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
>
> RTTI in C++ is not sophisticated enough to get you a static function if
> you have a typeid or another "runtime id" of the event class.
>
> You could probably construct your own metadata ("Runtime Class") so you
> could refer to an instance of "RunTime class" from a virtual method of
> your event or from "dispatchEvent" or similar method of your event
> dispatcher, based on the result of some virtual method of the event
> returning some form of its class id (maybe even typeid).
>
> Alternatively, with somewhat lesser flexibility, you could put your
> intercepting logic into the method of the event itself, something along
> these lines:
>
> class Event;
> class EventHandler {
> public:
> virtual void handle(Event *)=0;
>
> };
>
> class Event {
> public:
> void process() {
> if (!intercept())
> handler_.handle(this);
> } // I assume that's what you meant by "adding pointer to the event name"
> virtual bool intercept(Event *) = 0;
> private:
> EventHandler handler_;
>
> };
>
> class ConcreteEvent : public Event {
> public:
> bool intercept() {
> // one algorithm per event class here
> // so no need to register
> }
>
> };
>
> I am not sure I captured your problem fully; it would help if you posted
> some source code to illustrate the issue.
>
> -Pavel
The C++ language may not have the same capabilities as java, so I need
a dispatcher where I register my callbacks to names or ID's.
The event handler pattern is not the problem, as I use it since some
years.
The interceptor as I do understad, is a pre and post condition I could
activate on demand to change the plain behavior for sample to
add permission handling.
My problem is if this interceptor pattern is also usable if I have a
class (that is a database form) and I have different form instances
and thus different interceptors are required to add logic depending on
the particular form. Thus I may have more than one interceptor per
form. The form it self is a dynamic implementation to be used for
different data to be shown, thus there may also different
interceptors.
My main issue is about saving code. Another function I previously have
implemented is inside of the handlers. I don't like to keep adding
any more if I can do the same with interceptors. (application hooks
will become interceptors)
Lothar
==============================================================================
TOPIC: "Reusable" operator overloading for enum?
http://groups.google.com/group/comp.lang.c++/t/981ab2c7a0c2c5ff?hl=en
==============================================================================
== 1 of 6 ==
Date: Sun, Dec 27 2009 2:40 am
From: Marcel Müller
Hi,
nick wrote:
> inline ParserMode operator|(ParserMode p1, ParserMode p2)
> {
> return (ParserMode)((int)p1 | (int)p2);
> };
> ...
you won't come around to use macros in this case.
E.g.
#define FLAGSATTRIBUTE(T) \
inline static T operator|(T l, T r) \
{ return (T)((unsigned)l|r); } \
inline static T operator&(T l, T r) \
{ return (T)((unsigned)l&r); } \
inline static T& operator|=(T& l, T r) \
{ return l = (T)((unsigned)l|r); } \
inline static T& operator&=(T& l, T r) \
{ return l = (T)((unsigned)l&r); } \
inline static T operator*(bool l, T r) \
{ return (T)(l*(unsigned)r); } \
inline static T operator*(T l, bool r) \
{ return (T)((unsigned)l*r); } \
inline static T operator~(T a) \
{ return (T)~(unsigned)a; }
and possibly
#define CLASSFLAGSATTRIBUTE(T) \
inline friend T operator|(T l, T r) \
{ return (T)((unsigned)l|r); } \
inline friend T operator&(T l, T r) \
{ return (T)((unsigned)l&r); } \
inline friend T& operator|=(T& l, T r) \
{ return l = (T)((unsigned)l|r); } \
inline friend T& operator&=(T& l, T r) \
{ return l = (T)((unsigned)l&r); } \
inline friend T operator*(bool l, T r) \
{ return (T)(l*(unsigned)r); } \
inline friend T operator*(T l, bool r) \
{ return (T)((unsigned)l*r); } \
inline friend T operator~(T a) \
{ return (T)~(unsigned)a; }
for private or protected nested enums.
enum ParserMode
{
PM_NONE = 0,
PM_READY = 1, // ready for next col or row, or EOF
PM_EMPTY = 2, // empty cell
PM_CELL = 4, // cell
PM_QCELL = 8, // quoted cell
PM_HEAD = 16, // header cell
};
FLAGSATTRIBUTE(ParserMode)
The result is similar than the FlagsAttribute class in DotNET.
Marcel
== 2 of 6 ==
Date: Sun, Dec 27 2009 6:01 am
From: "Balog Pal"
"nick" <nick___@fastmail.fm>
> enum ParserMode
> DoStuff(PM_CELL | PM_EMPTY | PM_HEAD);
>
> But this will not work, because the compiler complains about not being
> able to cast between int and ParserMode. So some operator overloading
> clears that up:
> inline ParserMode operator|(ParserMode p1, ParserMode p2)
> inline ParserMode operator&(ParserMode p1, ParserMode p2)
> inline ParserMode operator~(ParserMode p1)
> inline ParserMode& operator&=(ParserMode& p1, ParserMode p2) {
> ...
> ...And everything works fine. But, now I need to add another enum, and
> I don't want to copy all of these overloaded operators for this other
> enum.
Yeah, it is a common "problem" too bad the language did not look for that
when removing the int->enum conversion; the listed operations currently
promote the enum to int (or bigger) create the result and it stays that
type. Instead of vorking natively on the enum and produce that type. :(
At least for | and &.
I never used ~ that way, as it may not work. The rule is that the
implementation type for enum must represent all the enumerators and their |.
so the value of your ~ is not predictable (unless you can force the compiler
to use some fixed type.
To create the missing operators I use a macro that takes enum name as param
and expands to text similar to yours. And just add it right after the enum
definition if it is used that way, saves redundancy and provides kinda
documantation of purpose too.
== 3 of 6 ==
Date: Sun, Dec 27 2009 5:59 am
From: Saeed Amrollahi
On Dec 27, 9:36 am, nick <nick...@fastmail.fm> wrote:
> I'm sort of rusty at C++, so this may be silly, but here's my
> situation:
>
> I have an enum like this:
>
> enum ParserMode
> {
> PM_NONE = 0,
> PM_READY = 1, // ready for next col or row, or EOF
> PM_EMPTY = 2, // empty cell
> PM_CELL = 4, // cell
> PM_QCELL = 8, // quoted cell
> PM_HEAD = 16, // header cell
> };
>
> And elsewhere I want to write something like:
>
> void DoStuff(ParserMode m)
> {
> if (m & PM_HEAD)
> ...
> else if (m & PM_QCELL)
> ...
> }
> ...
> DoStuff(PM_CELL | PM_EMPTY | PM_HEAD);
>
> But this will not work, because the compiler complains about not being
> able to cast between int and ParserMode. So some operator overloading
> clears that up:
>
> inline ParserMode operator|(ParserMode p1, ParserMode p2)
> {
> return (ParserMode)((int)p1 | (int)p2);
> };
> inline ParserMode operator&(ParserMode p1, ParserMode p2)
> {
> return (ParserMode)((int)p1 & (int)p2);
> };
> inline ParserMode operator~(ParserMode p1)
> {
> return (ParserMode)(~(int)p1);
> };
> inline ParserMode& operator&=(ParserMode& p1, ParserMode p2) {
> p1 = p1 & p2;
> return p1;
> }
> ...
>
> ...And everything works fine. But, now I need to add another enum, and
> I don't want to copy all of these overloaded operators for this other
> enum. Is there some way I can share one set of operator overloads
> between many enums using templates, macros, or some other trick, or am
> I just going about this wrong altogether?
>
> Thanks in advance for any help.
>
> -- Nick
Hi Nick
I think the following code helps you
enum ParserMode {
PM_NONE = 0,
PM_READY = 1, // ready for next col or row, or EOF
PM_EMPTY = 2, // empty cell
PM_CELL = 4, // cell
PM_QCELL = 8, // quoted cell
PM_HEAD = 16, // header cell
};
enum ScannerMode { // another enum
SM_NONE = 0,
SM_READY = 1,
SM_EMPTY = 2,
SM_CELL = 4,
SM_QCELL = 8,
SM_HEAD = 16,
};
template<class ENUM_TYPE>
ENUM_TYPE operator|(ENUM_TYPE e1, ENUM_TYPE e2)
{
int i1 = e1; // implicit type conversion
int i2 = e2;
return ENUM_TYPE(i1 | i2);
}
template<class ENUM_TYPE>
ENUM_TYPE operator&(ENUM_TYPE e1, ENUM_TYPE e2)
{
int i1 = e1; // implicit type conversion
int i2 = e2;
return ENUM_TYPE(i1 & i2);
}
template<class ENUM_TYPE>
ENUM_TYPE operator~(ENUM_TYPE e)
{
int i = e; // implicit type conversion
return ENUM_TYPE(~i);
}
int main()
{
ScannerMode s1 = SM_NONE, s2 = SM_HEAD;
s1 = s1 | s2;
ParserMode p1 = PM_NONE, p2 = p1;
p1 = ~p1;
p2 = ~(p2 & p1);
return 0;
}
Regards,
-- Saeed Amrollahi
== 4 of 6 ==
Date: Sun, Dec 27 2009 6:37 am
From: "Balog Pal"
"Saeed Amrollahi" <amrollahi.saeed@gmail.com>
>>
template<class ENUM_TYPE>
ENUM_TYPE operator|(ENUM_TYPE e1, ENUM_TYPE e2)
{
int i1 = e1; // implicit type conversion
int i2 = e2;
return ENUM_TYPE(i1 | i2);
}
<<
There is nothing to restrict the arguments here, so this template may pick
up unwanted stuff. (And use of the old-style cast in return instead of
static_cast makes it even more dangerous).
== 5 of 6 ==
Date: Sun, Dec 27 2009 7:22 am
From: "Johannes Schaub (litb)"
Balog Pal wrote:
> "Saeed Amrollahi" <amrollahi.saeed@gmail.com>
>
>>>
> template<class ENUM_TYPE>
> ENUM_TYPE operator|(ENUM_TYPE e1, ENUM_TYPE e2)
> {
> int i1 = e1; // implicit type conversion
> int i2 = e2;
>
> return ENUM_TYPE(i1 | i2);
> }
> <<
>
> There is nothing to restrict the arguments here, so this template may pick
> up unwanted stuff. (And use of the old-style cast in return instead of
> static_cast makes it even more dangerous).
One may use is_enum<ENUM_TYPE>::value to restrict it.
== 6 of 6 ==
Date: Sun, Dec 27 2009 7:30 am
From: Saeed Amrollahi
On Dec 27, 5:37 pm, "Balog Pal" <p...@lib.hu> wrote:
> "Saeed Amrollahi" <amrollahi.sa...@gmail.com>
>
>
>
> template<class ENUM_TYPE>
> ENUM_TYPE operator|(ENUM_TYPE e1, ENUM_TYPE e2)
> {
> int i1 = e1; // implicit type conversion
> int i2 = e2;
>
> return ENUM_TYPE(i1 | i2);}
>
> <<
>
> There is nothing to restrict the arguments here, so this template may pick
> up unwanted stuff. (And use of the old-style cast in return instead of
> static_cast makes it even more dangerous).
I see what you mean. The code by Nick had the problem too. From point
of C++ Design and Implmentation,
he wanted to share common code between two different enums. For well-
known reasons, I prefer template
over macros. I am not sure, but if I'm not mistaken, in C++0x, the
Scoped enums don't allow the implicit
conversion from enum to int.
regards,
-- Saeed Amrollahi
==============================================================================
TOPIC: C++ jobs down another 40%
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Dec 27 2009 3:02 am
From: "io_x"
"tanix" <tanix@mongo.net> ha scritto nel messaggio
news:hh6heo$2lo$1@news.eternal-september.org...
> In article <hh66vr$scn$1@news.albasani.net>, "BGB / cr88192"
> <cr88192@hotmail.com> wrote:
bla bla bla
again
one general language
1) using a portable thypes
eg u8 == unsigned 32 bits
u32== unsigned 32 bits
i32== int 32 bits
etc and operation on them
2) eliminate all the undefinited behaviour on the languages
--------------------
1) or use one PC virtual machine (all x86 + hardware of one pc, all virtual)
that rapresent x86 PC and whatever you want: eg compiler etc
and install that in each machine even if have different cpu and hardware
== 2 of 4 ==
Date: Sun, Dec 27 2009 3:22 am
From: "Bo Persson"
io_x wrote:
> "tanix" <tanix@mongo.net> ha scritto nel messaggio
> news:hh6heo$2lo$1@news.eternal-september.org...
>> In article <hh66vr$scn$1@news.albasani.net>, "BGB / cr88192"
>> <cr88192@hotmail.com> wrote:
> bla bla bla
>
> again
> one general language
> 1) using a portable thypes
> eg u8 == unsigned 32 bits
> u32== unsigned 32 bits
> i32== int 32 bits
> etc and operation on them
> 2) eliminate all the undefinited behaviour on the languages
> --------------------
> 1) or use one PC virtual machine (all x86 + hardware of one pc, all
> virtual) that rapresent x86 PC and whatever you want: eg
> compiler etc and install that in each machine even if have
> different cpu and hardware
Nothing stops you from writing code that is limited to x86 machines.
Specifying the language as x86 only, stops these guys from using it:
http://www-03.ibm.com/systems/z/
Hardly a great idea!
Bo Persson
== 3 of 4 ==
Date: Sun, Dec 27 2009 6:10 am
From: tanix@mongo.net (tanix)
In article <hh710d$fqt$1@news.albasani.net>, "BGB / cr88192" <cr88192@hotmail.com> wrote:
>
>"tanix" <tanix@mongo.net> wrote in message
>news:hh6heo$2lo$1@news.eternal-september.org...
>> In article <hh66vr$scn$1@news.albasani.net>, "BGB / cr88192"
>> <cr88192@hotmail.com> wrote:
>>>
>>>"tanix" <tanix@mongo.net> wrote in message
>>>news:hh4vpq$304$1@news.eternal-september.org...
>>>> 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.
>>>yep...
>>>and one can also wonder why parts of the core VM (JIT, PE/COFF machinery,
>>>....) need to be dependent on GTK and GLib (using GObject, ...).
>> Well, at least I do not have to worry about it.
>> Probably for historical reasons. After all GTK is one of the oldest
>> toolkits around.
>yeah.
>>>granted, I guess there is a partial solution, which is to use basically a
>>>stripped-down dummy version of GTK for building the VM, but I dislike this
>>>having been needed in the first place.
>> I am not sure how easy it would be to do it with something else.
>> After all, almost anything I saw in terms of graphics on Linux/Unix
>> looked to me like a nightmare.
>this is not even for the graphical code.
>if it were only the graphical code, I would have less reason to complain
>about it...
>> What a pitty.
>> I do not claim I am aware of all the "progress" that has been made,
>> but I think it is one of the weakest points of Linux/Unix.
>> Furthermore, from what I recall, it is not even a single layer
>> of abstraction. There is this dinasaur X11 stuff and on the top of it
>> some GTK and on the top of that is Gnome if you are talking the O/S
>> level user interface. But I am exactly a reference point on this.
>> I did try to look at some graphics related stuff, but every time
>> I had goose bumps just trying to figure out what is what and who is
>> who.
>yep, except that on Windows GTK can work via GDI (though it does so in a
>very X11-like manner, namely creating a window and dumping graphics into
>it...).
>I just dislike GTK though as it has a bad habit of not really working on
>Windows (as well as not exactly being a very clean API).
>X11 abstracts over the graphics hardware and facilitates multiplexing and a
>"window manager".
>>>> 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.
>>>agreed...
>>>sadly, the best option in Mono's case is "Windows Forms", if anything
>>>because it directs to GDI on Windows and GTK on Mono.
>> Windows forms immediately triggers the visual basic syndrome in me.
>> :--}
>> But what I do have to agree that it is pretty easy to graphically
>> design some of your GUI stuff with it. But that is about all the
>> good news about it.
>yes, ok.
>>>> 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.
>>>one can get "halfway there" via clean coding practices.
>> Well, may be. But when you start from scratch, the curve is too steep
>> in terms of time and effort for you to get something realistic done.
>> It is much easier to rely on things like swing or even awt.
>granted, but it is not so bad when after one has a 10+ years old codebase,
>and so most of the basic stuff is already working. granted, there are good
>and bad points here.
>>>> 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.
>>>but, it is not good to waste them either...
>>>many of us do write code where performance matters, and where seemingly
>>>very
>>>little issues in the right spots can eat lots of clock cycles or memory...
>> Yep. No questions about it.
>> But at least if there was some lanugage facilities you could rely upon,
>> the stuff under the hood could be optimized as it forever happens.
>> I am not sure how much of a performace factor the GUI code would
>> be dependent on. Some key listeners, some event listeners, the async
>> processing and things like that.
>yeah.
>one of my annoyances with the JVM though is using UTF-16 for character
>strings, since this makes strings-heavy code waste memory (I personally
>prefer UTF-8 for most things).
>> I have pretty large dialogs I would say, probably with at least 50
>> components,
>> and in some cases 3 times as much. Never ever felt any kind of performance
>> issues with it. Sure, if you do real time graphics or 3D app, that could
>> be a totally different story. But I have no clue in those areas.
>> As long as it is not a real time stuff, I doubt GUI is subject to
>> performance issues.
>I do both 3D and soft-real-time apps.
>in some kinds of apps, performance is fairly critical to usability, as lag
>makes the app unusable.
>>>> 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 disagree in the strict sense.
>>>if the code can be rebuilt easily enough for the various target OS's, this
>>>is often "good enough".
>> Fine with me. I am willing to take a source level portability.
>> For as long as I don't have to give an arm and a leg to sharks like
>> Microsoft or Google.
>ok.
>>>virtualization can help, but usually it is far from free either.
>>>for example, neither JVM nor .NET will allow one to use the same code for
>>>both a hosted and native build, and IMO this aspect is important as
>>>well...
>> Well, I am not even dreaming of that level of portability.
>> At the moment, we are just totally empty handed.
>> And if it takes several years for those "committies" to come up to some
>> kind of agreement, I'd rather take at least some of it, if it can be done
>> "real soon now". As long as they are not going to change it every day.
>ok.
>>>granted, if I compile a bunch of Java to a native EXE or DLL, it can't
>>>really be expected to run on, say, Linux, but this much is not the issue.
>> Yep. Source level compatibility AND the ability to compile it to
>> a natural way things are executed on a given platform, is fine with me.
>> Actually, that was my argument with Java guys a while back.
>> I said: when I run a windows app, I expect it to be an .exe file
>> that I can simply click upon to run the app. Because THAT is the way
>> every runs under windows. Everybody knows it, and everybody is used
>> to it.
>> I do not even want to know that there are some funky portable .class
>> files underneeth, and those are the actual things that run.
>yep.
>> And this is a fundamental conflict with the very concept of ?VM.
>> Because if you simply want to have an exe, then, by definition,
>> you need to compile in your ?VM either into a single executable,
>> or executable that simply loads some dll.
>> And that kinda breaks the whole idea behind the JVM at least
>> since class files are your final "executables".
>> JVM executes a pseudo code, not a native mode code.
>it would be nice to have an option is all, especially for mixed Java and C /
>C++ apps.
>at present, mixing Java and C code is "not exactly nice", which is sad...
>it would be nicer if, say, one could write parts in C, and parts in Java,
You mean ala PHP?
:--}
Well, not sure I like to go THAT far.
It would be fine with me if it could be achieved on a level of
a routine or a class as far as granularity is concerned.
Interfaces are already there.
And yes, this IS one of those things I'd LOVE to have.
If one language turns out to be more efficient for whatever reason,
that would be great if you can just switch to a different language
in a different module to do it.
But then, since both of them rely upon the same VM, unless you can
come up with some trick to avoid it, I am not sure if it is doable
in realistic terms. Otherwise, your whole concept is flawed as far
as VM goes because in one instance you use the VM, and in another,
you go directly to O/S. But then, what is the whole point of VM
and how are you going to achieve that portability?
>and not have to worry about using magic rituals needed to get them to play
>together.
>>> it
>>>would be better if one could compile it in both cases, rather than
>>>creating
>>>yet another barrier:
>> Totally agreed. I want to see it compile into a single native mode
>> app that may or may not use the dlls under windows.
But this is probably like a dream that never happens in reality.
:--}
>> But then I am not sure how would you go about with the very
>> concept of ?VM.
>well, not all VM's are the JVM or .NET style.
>consider the Python VM:
>the main part of the app is typically C or C++, and then it links against
>the VM, which in turn loads python scripts or bytecode files.
>
>the goal and use case is very different, and my VM is, in many respects,
>closer to the Python VM (in purpose) than it is to the JVM.
Is it a fairly complete design?
In terms of threads support, synchronisity issues, events and things
like that?
Cause if it is, I'd be curious to see it.
>so, there is a cost:
>my strategy does not allow avoiding rebuilding an app for various target
>OS's;
Non issue for me. Source level compatibility if fine.
After all, if the same source compiles for a different environment,
what does it cost you to compile compared to the benefits?
>it is a tradeoff, but it is acceptable enough for my uses.
Well, everything is a tradeff at the end.
>although, it is not mandated by my design, this is just how I am currently
>using it (otherwise, I would have to migrate much of the codebase to run on
>top of the VM...).
>>>Java code is, always, run in the VM;
>>>native code is C and JNI.
>>>there are at least several JVM's which ended up allowing running the C
>>>code
>>>in a VM as well (just x86 based rather than JBC), but still using JNI to
>>>interface them.
>> I am sure there are ways to solve these kinds of issues.
>> Exept everybody is busy erecting the castles on a see shore
>> from what I see.
>> Again, I am very displeased with the direction of language
>> development in general, no matter where you look.
>> I think is is a totally dead end approach.
>worth mentioning here is LiquidVM, which runs both Java and C in a VM.
Interesting. Never heard about it.
I did not spend any time on looking at VM grade issues.
>no new language is created here.
Oh, I like that one. I kinda have enough of those languages
to bother about.
>> They are not even looking about the most critical issues to a developer,
>> and "could care less" about what is happening in the world in terms
>> of it being more and more dependent on the information processing
>> aspect, such as web.
>> I doubt what people need is some "revolutionary" syntax.
>> Have not seen ANYTHING that excites me in F#, even though it looks
>> nice on paper. I have not seen things like GUI, threads or GC
>> even mentioned.
>> Why do you think PHP, Python, Ruby, Javascript, SQL and even HTTP
>> are so appealing?
>> Vast majority of web based apps are developed with PHP from what
>> I see. Most of CMS systems, bulletin boards and you name it use PHP,
>> even though Python and Ruby have much higher performance.
>> Just look at the very central idea of PHP that you can mix
>> your html code with php, however crazy it may sound, and it does
>> sound crazy to me. But it gives people so much power and flexibility,
>> that any kid can deveop something working within days, even though
>> they might have never heard such things as synchronicity,
>> threading, acync processing events and things like that.
>> And THAT is what is happening in the world, and I bet you,
>> it is going to be happening more and more.
>> People do not even know about the portability issues.
>> Because they simply do not exist.
>> They could care less if you run JVM or anything for that matter.
>> They don't care how "pure" is your syntax and notation
>> from the standpoint of some "head".
>> They do not know what means static binding or dynamic binding
>> necessarily.
>> And yet, there is a tremendous amount of work being done
>> and it does what they want.
>> Why not look at it as an opportunity?
>> Especially if you have the underlying principles that allow
>> you to run orders of magnitude more efficiently?
>> Why not look at THESE things instead of sitting in an ivory tower
>> and keep inventing some new mental perversion that will make
>> people shiver when they look at it?
>errm...
>I am not trying to build a "new ivory tower", as I already dislike this
>strategy...
>more, I am building stuff to do what I want to do with it...
>I have no new language, no fudamentally new architecture, ...
>actually, it is a set of very conservative designs, in that nearly every
>part is based on things that are already fairly well established, such that,
>for the most part it is invisible.
>once as a joke, I considered calling the whole VM project "Silverfish", and
>went as well as to make a glossy metallic logo image for this (depicting one
>of these critters partly in a circle).
>the idea is a VM more like the silverfish, which lives in ones' laundery and
>eats lint and stuff...
:--}
>however, in general I call it 'BSCC'.
Which is?
>>>> 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.
>>>yeah.
>>>dynamic languages tend to have a certain limit to their scalability.
>> For one thing. Except you need with specific app.
>> If it is a server end, yes, there is a need for scalability
>> and performance, and I think Java solved it quite nicely.
>> Not saying it is the "ultimate" solution. Because none exists in
>> principle.
>yes, ok.
>>>some of their abilities are really nice and powerful at the small scale,
>>>but
>>>the bigger a project gets, the harder it gets to manage.
>>>many static languages tend to scale much better.
>> Sure they do. That is the whole point of them.
>> And that is why I'd like to see a STATICALLY scoped (typed :--})
>> languages to at least consider the modern world.
>> Because they don't even bother about anything else, but their own
>> lil sandbox in the scheme of things.
>well, they work fairly well for what they do.
>static languages make up most of the code which does actual work;
>and dynamic code usually does specific tasks for the benefit of a particular
>app.
I think it should be doable to have the same system that has
multiple behavior with the help of some scripting mechanism
when you need to run in interpretive mode need be.
But, using the same system can run at a performance of static
languages as a core.
Do not see a fundamental problem with it.
>it all works out well enough I think.
>>>my intuition here is that probably C likely scales fairly well (if
>>>practices
>>>are good), with C++ and Java likely comming close (again depending on
>>>practices, Java will likely allow scaling easier at the "medium" scale).
>> Except it is used on the largest scale in banking, finance,
>> wall street, governments, etc.
>ok.
>>>JavaScript is not likely to scale well.
>> Well, it does not need to. It is a client end gizmo.
>it is also gaining popularity in non-browser settings...
Well, could be. I am not exactly a Javascript guy.
I just have a rough idea about it. Never had time to actually
get into the nasty side of it and I am not even excited with
that idea because I have a feeling I'll get entangled in
those nasty surprises where you have to waste weeks to fix
something, like those js guys say.
Plus the most advanced part of it is simply weird to me.
>>>guestimate:
>>>C (with poor practices), likely to turn into an ugly mess at around 30-50
>>>kloc;
>>>C++ (with similarly poor practices), maybe around 50-75 kloc;
>>>Java (with 'generic' practices), likely at around 200-400 kloc.
>>>in C and C++, the user is likely to end up stumbling around with globals
>>>and
>>>memory objects...
>>>in C++, the limit is likely to be a slight bit higher, due mostly to the
>>>programmer trying to naively use namespaces, classes, and RAII as "magic
>>>pendants".
>> I like this one:
>> "only real danger is that we simply forget to release the resource,
>> which, while it does happen, is something that should be quickly caught
>> in any code-review."
>> What a joke!
>yep.
>>>this would work for a little while, but ultimately these can't
>>>save poor practices (for example, a global in a namespace is still a
>>>global,
>>>....).
>>>by adapting many coding policies, the situation is reversed, very
>>>possibly:
>>>C (good practices), ~ 1 Mloc;
>>>C++, ~800 kloc;
>>>Java, ~ 500-600 kloc (?...).
>>>reasoning:
>>>in C, one is likely to have learned early on that fairly rigid coding
>>>practices are needed to help code scale, and if followed make the natural
>>>large-scale structure somewhat different from its smaller-scale form.
>>>C++ is similar, but I suspect it is likely that there will be some
>>>"aliasing" related to misusing some OO features in ways which create
>>>"tangles" (very likely, the same features which tend to help at the
>>>smaller
>>>scale).
Hey, watch that line lenght. Do you see what happens after a couple
of followups?
:--}
>>>actually, from my experience, a sufficiently large C or C++ project is
>>>likely to start notably resembling an existing OS, such as Linux or
>>>Windows
>>>(or at least, this was my experience...).
>>>Java is not likely to help, since the language itself has a fairly
>>>restrictive design, and it would be awkward to use a large-scale
>>>architecture in conflict with the languages' built-in architecture. I
>>>could
>>>be wrong though, not having had much significant experience in the
>>>language.
>>>JavaScript is not likely to scale well much above maybe 10-25 kloc, and
>>>attempting to adapt modular practices would make the language likely
>>>somewhat unappealing.
>>>the advantage if offers then is that, given it is likely to be used for
>>>scripting rather than for infrastructure, code is likely to be small and
>>>divided up into disjoint islands, which would help keep issues
>>>more-or-less
>>>contained (the number of such islands should not be a significant factor
>>>beyond the level of code one has to deal with).
>>>> 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.
>>>ok.
>>>> 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.
>>>newer Java does support generics, FWIW.
>> I know. Except VS 2005 is the last version of IDE that supports
>> Java syntax. Beyond that, there is no concept of anything even
>> remotely related to Java. Thanx to these Sun vs. Microsoft wars.
>ok.
Btw, is there any IDE that is as powerful as VS and supports
Java latest JDK? I tried Borland once. Did not like it a whole
lot. Even though it is kinda ok-ish. Except it works in strictly
Sun's way and produces the .class files at the end. So, during
the run time, my code runs 2 times slower with Sun's version
of JVM.
Secondly, Borland is generally a hacky to my eye.
Not very clean overall. That is why in my view VS beats all others
hands down from any standpoint I can think of.
>>>> 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 realize
>>>> I was screwed again by some fools, selling me 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.
>>>well, for the most part, it is not particularly "compelling".
>> So what?
>> You did spend some time thinking about these things.
>> Don't you think that the results of it is worth some value to others?
>> And even if you are "wrong" and they jump on you in bulk,
>> what is "wrong" with that? Who knows, may be some new insights
>> may come up out of it, for you and for them?
>> I do not think it is such a good idea to simply let your work
>> go to waste because you are aftaid of being condemend.
>> Screw that stuff. One of the most pitiful things.
>> I think if you have done some work, it is imperative you talk about it.
>> It may generate new ideas for others and for you, just by the shear
>> fact that you EXPRESS it. Take it from subconscious level to conscious.
>> Do not underestimate the significance of it.
>ok...
>maybe a paper of rational and design explanations?...
Sure. Why not? That is how it starts.
Why did you even decide to go this way?
What do you see as advantages of approach?
What kind of benefit you get at the end?
How is system architectured?
There are PLENTY of things you can spill out.
Because it looks like you've got something working actually.
It is not just a matter of mental excersize.
Plus, it will help YOU to see some things that are still
carried inside of you on a subconscious level without being
expressed, and that tends to make some things fuzzy.
Again, my personal opinion is this:
NO work should just go to waste, unless it is just an idle
excersize by some kids that have nothing better to do with
their lives but to forever be superficially curious.
We can not afford this any longer.
It is a grandast waste of all - waste of creative potential,
that is actually at work.
That is why I suspect plenty of work is actually being done,
but people just let it go to waste either because of fear
of condemnation of for the inferiority complex, thinking
their stuff is not as great as some Strousrup.
Screw that.
I don't want to challenge the very foundation of C++,
even though it could be. But trust me, it is not exactly
the word of God, omniscient.
Objective C is still live and kicking.
In fact, I just read the other day, that it is now used
heavily by Apple, and I would not underestimate ANYTHING
that Apple does.
So...
>>>it has nearly all of the parts of a traditional compiler:
>>>preprocessor, frontend, IL, codegen, assembler, linker.
>>>the input language is C, the IL is a little funky (and obscure Forth or
>>>PostScript like language, sent between stages in a textual form), the ASM
>>>is
>>>essentially a variant of NASM / YASM style syntax;
>>>the assembler produces COFF, and the linker accepts COFF.
>>>it "may" use a custom name-mangling scheme, which is largely a hybrid of
>>>JVM/JNI naming, and IA-64. basically, it combines a lot of the notation
>>>from
>>>IA-64 with the general syntax of JVM signatures, and then converts it to a
>>>linker symbol with a convention based on that used in JNI (although, it
>>>has
>>>special-cases for several additional characters, as well as a shorter
>>>escape
>>>for chars in the 1-255 range).
>>>this particular type-signature scheme is used by many internal components.
>> Look, I can host your project and ANY documentation you have.
>> We'll make a separate "site" for it that contains the interesting
>> projects in the area of language or system development.
>> You'll have your own top level link that will be shown in the
>> top level index.
>> That is what I can do.
>> This should not go to waste in my opinion.
>well, I have some stuff here:
>http://cr88192.dyndns.org/bscc.html
Ok, I just looked at it.
I do like the idea of components as such.
Once you have such a concept, your hands are untied to do much
more creative things dynamically wiring it in.
I like this one:
"Instead, I try to incorporate things which already exist".
Totally agreed. This should be done as much as possible.
And this one is really cool:
"Why dynamic compilation? Because C just really needs eval..."
I LIKE that kinda stuff!
:--}
..
Jeez! You do have ALL sorts of things worked out by now.
Impressive.
I looked at it. But it is going to take some time to have a deeper
look.
One thing I suggest is to create some graphic stuff, like boxes,
diagrams, a system architecture or whatever you feel comfortable with.
I wish I could support you financially. Except I am not exactly a
"rich" man.
Do you happen to have a Paypal account?
You probably need at least 3 to 10 people working on this thing.
I am not sure you can handle it all by yourself.
>it has a general rationale, a partial spec of some of the data, and some
>project dumps (most recent from around 4 months ago...).
Well, one page is not enough.
Do not underestimate the documenation end of it.
The more things you can spill out in detail, the more benefit
to the whole project it is.
First of all, if things are understood on a more detailed level,
then even if you decide "I had enough of this", the other people
may decide to take it over and there is enough information to
continue the work.
The documentation for this one should be at least 30 fat pages.
The subsystems need to be described in much more detail.
I suggest it to be fully tagged, meaning well cross referenced
well, interlinked, with detailed table of contents.
That should take somewhere in the range of 2 weeks to a month.
Once that is done, you are in a much better shape I think.
At that point, you are going to have something that is not just
going to go away. Because others may be able to pick it up and
go on.
Basically, I do like this kind of thing.
>>>> 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?
>>>both the JVM and .NET want to remake the world in their own image,
>> YES.
>>> and set up "the one true VM to rule them all".
>> Well, except in case of microsoft, you'd have to say
>> "to rule them all as long as you are dealing with OUR stuff".
>> That makes a difference.
>yep.
>>>I disagree with this strategy.
>>>a VM is, IMO, "a framework" not "the framework".
>>>hence, in this sense, I am a little more closely aligned with Python or
>>>Lua.
>>>(although, I personally don't have so many happy feelings towards Python
>>>either).
>> The only thing that prevented me from geting into Python,
>> even when I needed to, was abscence of braces.
>> The very idea of using white space as indentation level is bizzare.
>> Just this single thing was enough to stop even bothering with it,
>> and when I read his arguments on WHY did he do it, it was just
>> a bad joke to me. To try to fit as much code on your screen as you
>> want by simply removing the most stable code block delimiters,
>> is simply insance.
>> On the top of it, when I read some of original documentation,
>> it seems like the guy has difficulties with comprehension skills,
>> jumping right into middle of such nasty things like regular
>> expressions and not being able to explain every step of the way.
>> Some syntax issues with regex are totally unintuitive.
>> Some other stuff like installation subsystem borthers on insanity
>> to me. When I looked at documentation, it was just like reading
>> a bible sized book with ALL sorts of blabber, just to copy some
>> stinky files around and set up some relatively simple things.
>> As a result, full stop on Python. Regardless how many people
>> say it the the solution to mankind's problems. Python is a hack.
>> I like "real" languages developed by people, who have seen it
>> all in and out, and not by some smart "wizards".
>granted, yes.
>I don't so much like the Python language, but I suspect my goals are a
>little more closely aligned, granted, the technology is itself a slight bit
>different...
I do not mind Python in principle.
There are some very flexible feature and pretty rich set of
expressive power. No question about it.
The guy IS pretty clerver I'd say.
Plus, once he's got this thing compilable, and on the fly,
that thing does deserve some attention to be paid.
May be I should have spent more time looking at it.
Except you never seem to have enough time to look at all the stuff
around.
>>>> 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 of people complain about very primitive,
>>>> low level support for 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.
>>>yep.
>>>well, there are merits to VMs, and there are costs...
>> I'll take the merits and accept the costs.
>> What other options do I have?
>granted.
I think you are cheating here.
:--}
I bet you do not agree...
:--}
>>>I don't personally believe in aboloshing the JVM, only that I think the
>>>way
>>>the overall architecture, and the way Sun is managing some things, are not
>>>quite so ideal.
>> May be. But I'd be REALLY careful making these kinds of statements.
>> But if you have a better idea, why not?
>well, as noted, I don't intend to abolish it.
>instead, goals can be addressed partly via alternative implementations which
>address alternative use cases, but which allow for architectural
>differences.
Too general for me. But if you had it all written down on a much
more detailed level, that would help to understand your position.
(wink, wink)
>examples:
>Apache Harmony (different workings and internal organization);
>GCJ (native code support);
>Dalvik (essentially a different VM technology);
>....
>granted, Suns ideal can only be universally true if there is a universal
>implementation, which at this moment is generally held to be Sun's JVM.
>similarly, Sun has historically tried to be fairly "Iron Fisted" with
>maintaining this status quo.
That is true in my opinion.
And that eventually lead to disaster.
Were they more flexible in their approach and tried to cooperate
with ms, instead of posing as messangers of God, omniscient,
who knows, with their size, they could have struck the deal
with ms that would eventually produce more benefit to all,
and to them included, than this warfare stance.
I know those guys at Sun are arrogant. Seen it first hand.
And it WAS disgusting to deal with some of them. No questions about it.
But not to be able to comprehend what it means to fight with
ms? That is beyond all stupidity to me.
What is the result?
There is no longer Sun?
A BIG funken achievment!
>this is the extreme opposite of, say, C, where there is no such
>implementation (MSVC is no more "the true C compiler" than is, say, "GCC").
>there are standards, but a standard is neither a reference implementation
>nor a direct authority figure.
Correct. But I'd have to argue that whatever you have at the end
must be supported by a standard. After all, that IS one of the main
strenghts of the approach to just about anything in the USA.
Once things are standartized, you can rely upon it without fear
that things may DRASTIALLY change tomorrow, which may go as far,
as putting you out of your business or what have you.
But creating standards in such complex areas as software and
system architecture and design is nothing less than nightmare.
The overhead is WAY too much, and it takes YEARS for all those
high tower priests to agree on anything, and even after you do
agree, it is not even clear you genuinely have some breakthrough.
>however, if it is allowed that implementations freely diverge and only
>remain compatible by consensus, then one can no longer claim that apps are
>entirely portable, "lowering" it to the level of C (which is often demeaned
>by supporters as being a low-level and generally unportable language, ...).
I do not know how far you can take this claim of "entirely portable",
and, to tell you the truth, it is now what I am concerned with.
Because I have my own something and I do not want to sweat
if I want to make it work on at least MAJOR platforms, such as
Windows and Linux. I am not even looking at system level portability.
Meaning some low level device driver related code,
even though that would be REAL nice if that was possible.
I recall numega (softice) guys did some work in that direction.
But I did not spend that much time looking at it.
It did generate some stub code. But I was not impressed with
the overal value of it.
>so, most of this is a lot more philosophical and political than
>technological.
>one can actually leverage a very large amount of power from otherwise small
>details, or waste huge amounts on effort on something which hardly amounts
>to much of anything.
Yep.
>>>granted, not everyone has the same needs or ideals, and what the JVM
>>>addresses are a slightly different set of ideals than those I am trying to
>>>address.
>> And those are?
>some want a portable platform, and others want to script an otherwise
>native-code app.
Well, these are two different aspects.
Portability and performance/scalability.
If you can achive BOTH of them with the same system,
that is ideal.
>some want high-level scripting (JavaScript and Flash), whereas others want
>app extension and high performance (such as LLVM).
>in my case, I mostly want high-performance, app-extensions, and scripting.
Well, but scripting IS a portable approach.
So, you are saying you can handle both of these things
and it is going to reconcile?
Then you have a home run!
:--}
>the platform is not, however, an icon of universal portability (as is, my
>project would fail miserably on this front...).
Do not know what you mean.
But the buzzword, which is my main concern, is portability.
Then, portability at high performance.
And THEN only, scalability.
>>>granted, Apache Harmony and GCJ are both pseudo-JVM's, both of which adapt
>>>both Java and much of the JVM architecture, but each varies in some
>>>notable
>>>and fundamental ways:
>>>Harmony seems better adapted as a script VM (for example, for the Apache
>>>web-server);
>>>GCJ can compile Java code to native machine code and link fairly directly
>>>with C++.
>> Oh, now I remember about that GCJ thing. I think I looked at it
>> a while back, just in passing. At that time, I did not believe
>> they are really selling something real and I did not have any first
>> hand experience with it. So I had to abandon it.
>> Is it something worth looking at in your opinion?
>well, if one is using GCC and C++, it is probably an acceptable option.
>otherwise, these are its main merits.
>I think it is fairly "hit or miss" WRT its class library, and only really
>works "impressively" on Linux (mostly because on Linux, it offloads a lot of
>the "heavy lifting" to Eclipse, but on Windows the Eclipse components are
>not present, and so what it implements is a little less complete...).
Well, there IS Eclipse version for windows.
Except I did not quite like it.
Last time I used it was probably a year ago.
It is pitty they can not learn from VS.
Cause it all works like a champ.
Just look at the visual space utilization efficiency.
On smaller screens, there is nothing that even compares to VS
in terms of absolutely necessary things to be seen on the screen,
the size of all gui elements, the ease of navigation between
major aspects of your IDE, and the overall amount of visual
clutter.
Sure, on bigger screens this may no longer be applicable.
But even working with things is MUCH more intuitive and much
more simple in VS.
I did like NetBeans better in this respect.
It looked much cleaner and some Java experts do love it.
Except the code completion is simply horrible.
Primitive as it gets. You have to essentially continuously
scroll all over the place to find the exact symbol you need
to use. Code completion is WAY too primitive.
Why don't these guys learn from that which already exists?
>it should be fine though if one does not demand that generics work, or that
>one has a generally complete class library...
Well, I am perfectly happy with Java in that respect.
It is complet enough for me.
I do think that languages need to include much larger set
of things that were developed by competent people.
So you couold just drag and drop or copy/paste stuff
or simply link it in, without worrying about things like this is
all just a cludge or a hack.
Understood, it takes much more effort to support a rich set
of something. But I generally like to stay away from all sorts
of "toolkits" or what have you.
It all looks nice on paper, but when you start dealing with it,
it is either a grand headache or some weird limitations or ALL
sorts of things.
I like flexibility and freedom of expression.
It is a bit weird that once I hear "toolkit", I am about to
freak out. Seems like well, it should make things easier for
you as you have MORE tools to work with. But either there
is a bible sized pile of concoctions and I have to spend
another couple of years learning their weirdness, as they
put the whole world upside down and I have to learn another
language on the top of what I already know, which is too much
as is, or there is such a weird way to do something, that I
could care less if those "great designers" exist.
I have no time to learn another universe that is totally
different from the Universe I know already. Go to hell!
I need simplicity.
I need clarity.
I need expressive power.
I need flexibility.
And I do NOT need another pile of crap on my shoulders,
no matter how grand it looks on the paper.
I could care less if F# exists.
The look I took at it just yesterday was enough to put that thing
on a back burner for at least a year.
I am not interested in chasing some new "fasion"
and get sucked in into a "revolutionary" "new paradigm".
Enough of THAT kind of crap.
I saw so many "paradigms" already, that I wish I could unwind
some of it and make a deal with God to give me my years of
life back and erase some of that grand bullshit from my record.
In that respect, I am as "conservative" as it gets.
I give a flying dead chicken about "new technologies".
It is all an old story to me.
I give a funk about some "breaktrough" language.
I want something that will fit nicely into my cockpit
with all the stuff I already know,
and is easy enough to INCREASE power, portability and flexibility.
I give a flying dead chicken if generics exist.
And about the LAST thing I care about is those "design patterns".
Makes me puke.
Sure, if you don't have brains, you need some recepie
and a "good programming practice", some desing "template"
for the zombies, so they do not get lost in this giant forest
of ultimate logic.
>>>what the JVM offers is OS abstraction via a virtualized architecture.
>>>granted.
>>>some people don't need this though, and instead want a good scripting VM
>>>under the control of a host app, which is a role thus far best filled by
>>>Python and Lua.
>> Well, then have two VMs. I could care less for as long as I know
>> when I do this and that, I have to type a different command line,
>> or something like that.
>> You keep mentioning Lua. Have no clue about that one.
>Lua is basically a simplistic VM for a vaguely Pascal-like language.
Jeez!
So, we have this Pascal P-Machine biting back?
Is that what I am hearing?
It never died?
>http://en.wikipedia.org/wiki/Lua_%28programming_language%29
Sorry, I can not do any more reading right now.
Ok, let me see just for a couple of minutes...
Funky stuff, I tellya. I wish I had luxury to afford to get into
these kinds of things.
:--}
>it competes some with Python, where Python is much bigger and full-featured,
>and Lua is a lot smaller and light-weight.
I light light-weight buzzword!
:--}
>>>another need is for good performance and powerful app extensions, which is
>>>better filled by C (high level script languages are good for scripting an
>>>app, but not so good for extending it).
>>>I have some hope of being able to have JVM features available as well, but
>>>my motivation has been lacking (the JVM facilities I have in place are
>>>not,
>>>what I would call, "usably complete").
>>>many notable VM features (such as exceptions) don't work, and I don't have
>>>a
>>>class library (there was some attempt to port over GNU classpath, but this
>>>petered out some and I have my doubts about using such a massive GPL'ed
>>>component).
>> :--}
>> Yep, massive seems to the point.
>> Well, not sure what you have been cooking there and why did you
>> have to design your whole world to do things, but I guess you had
>> your own reasons to do it this way.
>well, it doesn't seem like nearly so much when one starts out...
I know, I know.
:--}
Until you get your feet wet!
>it was a whole world of implementing one feature, then the next, ...
>until years of effort have been eaten up and one has some huge monstrosity
>of a codebase...
Yep. That is what I peddle:
"We do not know what information truly is".
Long story.
>I did not plan this all at the outset, it just sort of turned out this
>way...
>it is always, at the moment "well, this looks cool / useful / ..., I think I
>will implement it".
>many steps along the way were, as well, missteps and severe miscalculations,
>but oh well...
>>>>>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.
>>>well, I am one of the rare VM developers who is probably not promoting yet
>>>another new bytecode or programming language...
>> Well, I am not exactly an expert in this area.
>> Never quite grasped the idea behind the bytecode.
>> If someone tells it to me in few words, fine, I'll look at it.
>> What is the primary motivation behind the bytecode?
>the bytecode is some binary representation of a compiled or semi-compiled
>program.
>it is closely related to an IL (Intermediate Language), except that an IL
>may refer to any number of possible representations (such as text and tree
>structures...), whereas bytecode is usually much more specific: a stream of
>individual byte-based opcodes which drive an interpreter or a JIT backend.
Well, that much I know. I just did not get into nuts and bolts of it.
>http://en.wikipedia.org/wiki/Bytecode
Well, we'd have to leave it for another time.
I am not a revolutionary to bother about things like these
and have no plans to rewrite Java or anything of that kind.
They say it works? - Fine with me, whatever it is.
They say BECAUSE of it, things are nearly as slow as interpreters
are? Well, I doubt it is THAT bad, but yes, I can see your point.
Do you have something better that provides as much portability
as bytecodes, being the language of VM?
Fine, lemme see it.
That is the extent of me being involved with this stuff.
Never ever cared about it one way or another.
>>>for some things, I am using JBC, and for other things I have adopted
>>>32-bit
>>>x86 as a "bytecode" (good and bad points exist here...).
>> You seem to be gettin to deep into those nasty details.
>> Like designing your own world from the O/S level and up.
>> I wonder WHY do you need to poke THAT deep into this stuff.
>> Is there are philosphical reason behind it?
>because I built it all from the low-levels and work upward...
Gosh. You ARE one of those dedicated few.
:--}
I am just more interested in information as such.
I've been through the whole trip, from electronics, theory
and up.
But from times when I was young enough and heard this thing
when I was studying at the university:
"Sinusoid does not carry any information"
It was a shock to me.
I could never agree with such a thing.
So I started looking at what IS this thing called information.
And the more I looked at it, the more it was clear to me,
we just do not know what information is PERIOD.
And to this day, we simply have no clue.
Different story altogether.
>I don't personally seem to either think "top down", nor about the distant
>future (I suspect my "future" usually tends to be maybe a few days or weeks
>or so, then it is all in the land of vague uncertainties...)
That's fine. One does not need to take it in fanatical terms.
Whatever fits your fancy is fine with me.
As long as you use YOUR brain, and not just copycatting someone
elses ideas.
I like freshness, no matter how "practical" it is.
I like something that boggles my mind,
not because of some additional complexities,
but because of something radically "efficient",
radically fresh,
something that really means something at the end.
I hate crowds of goats, forever incrementally polishing
someone elses crap and calling it a "progress".
Ugggh.
I stay away from these kinds of people.
They make me shiver.
It simply numbs my by its deadness and staleness.
>I just keep going on and stuff happens, although why and how, I don't
>know...
Cool. I like that kind of stuff.
That means to me you are still innocent.
You are still not corrupt.
You are still fresh.
You are still young.
You are till that fresh leaf on the tree of life.
What a joy.
After all, what all this big farse about "languages" and
any of these "great", "revolutionary" "technologies" is all about.
Well, a dead mosquito fart at the end
in the grand scheme of things
of Infinite, all pervading Intelligence.
Just like a wind.
"Dust in the wind...
All we are is dust in the wind...
Dust in the wind...
All we are is dust in the wind..."
A VERY good song.
Beautiful.
>none the less, I do have opinions, and what stuff tends to happen (at least
>as far as projects go), tends to somehow / magically go in about the
>direction I would want it to go,
That IS the very "magic" of it.
Blessed are thou.
> so no real need to complain too much I guess.
>except that in some areas, very little tends to happen (my code goes
>forwards and gradually gets more "impressive", but mostly just bigger), but
>other aspects of life, not so much.
Well, but who knows, may be this IS "THE" Aspect!
:--}
>how I see progects, and how I see the world, is mostly what all I have
>already done, and my memories of how it all works.
>even though I have been surprised in a few cases, finding that my memories
>of long-past technical trivia sometimes differ in surprising ways from the
>actual facts (usually though, this has tended to be order transpositions,
>such as which order items were placed in a struct, or in an array, ...).
>for example, I had fairly solidly remembered Quake1 having used "pitch,
>roll, yaw" angle ordering, yet checking back on the code (after issues with
>Quake2) I had discovered it to be "pitch, yaw, roll", and I was at a loss to
>explain why. another such difference had been in the coordinate-space
>organization, where I had "clearly" remembered 'X=right, Y=forward, Z=up',
>but had found
>'-X=forward, Y=right, Z=up'.
:--}
>>>currently C and Java are the main "script" languages in use,
>> SCRIPT language?
>> :--}
>> I like that one!
>yeah, they are not designed as such, and not traditionally used for these
>purposes, but I use them for these purposes...
Jeez!
:--}
>going back a few years, I was like "hmm, if I kludge this here
>JavaScript-like script-language interpreter of mine with JIT capabilities
>into compiling C, I can so totally not need to go through all the usual
>hassles of a FFI".
>in retrospect, this may have been a very ill-founded idea (it has resulted
>in FAR more needed effort in the long run than it has saved).
>but, OTOH, it has reduced most of my scripting dillemas to "just use C", so
>I guess it pays off...
>>> however, I
>>>can't currently compile Java on my own (I have ended up having to resort
>>>to
>>>GCJ to do the first-half of this process).
>>>I did try to plug Java support into my C frontend, but this turns into a
>>>big
>>>mess, as my compiler backend can't really deal with Java's constructs
>>>(trying to shove C and Java through the same compiler backend is not
>>>nearly
>>>so easy as it would seem).
>> Oh, maaan! You must have some royal amount of free time
>> to dig THAT deep into it.
>current running rime on this whole compiler mess:
>~ 4 years now (actually, more about 3.8 or so...).
Well, long enough to get something "out the door".
>I had gone from the point of having the idea of a C compiler, to having it
>working, in about 6 months (initially, I thought it would be a few weeks or
>similar). subsequent years, mostly piles and piles of hacking on it
>(eventually supporting x86-64, then adding Win64 and SysV calling-convention
>support, ...).
>the project sort of has a baloon-like inflation pattern...
>>>I may instead switch to an alternative strategy, and maybe get around to
>>>writing a Java compiler which produces JBC / "class" files,
>> Jeez!
>> :--}
>> I feel sorry for you. What a task!
>possibly, but I can probably reuse enough code that it "should" be more a
>task of hackery...
>as-is, I already have a C-compiler frontend (partly hacked for both Java and
>C# style syntax), as well as a "Jasmin" clone, so going direct would likely
>be less of an issue than trying to force Java through my backend.
>"should" be mostly rewriting the frontend to produce Jasmin-like output,
>rather than RPNIL output, and using said jasmin-like tool to produce
>bytecode and class files (actually, I would probably ram it together with my
>JBC interpreter, since it has a class loader which would also be rather
>useful in this case).
>or, IOW, force a few parts together, do some ugly hackery with the
>internals, and, presto...
I do suggest to document this stuff in much more detail
with pictures.
>>> and then make
>>>use of my JBC interpreter, or a translator, for plugging this into the
>>>rest
>>>of the VM.
>> Are you trying to reinvent the software busines?
>> :--}
>> Your own VM, your own language, your own interpreter, your own translator.
>> Maaaan!
>it is all stuff which piles up...
I almost feel jealous!
I also had a trip with languages while back.
But then I gave up.
It was Forth and Lisp.
Spent a few years extending that stuff quite a bit.
Not sure if I can even find that code.
Then it was expert systems and AI.
Did some interesting stuff.
And then I gave up on the whole thing. I just went away.
Looked like an excersize in futility, so immense the task was,
and, as I said before, I got a feeling we do not even know
what information is and keep digging all sorts of things
and concocting all sorts of "systems", and all it is is empty,
signifying nothing at the end.
I did dig into database theory and stuff like that.
Played with that one. Looked interesting up to a point.
Then I saw a dead end with that one also.
>each part is not nearly so amazing in and of itself...
All I want is SYSTEM.
Don't even know how to describe it to others.
But I do know what I am after.
>>>my JBC -> C translator had been mostly so that I could compile Java into
>>>native DLL's via MSVC (mostly to avoid having to send it all through the
>>>classloader, getting better performance, ...).
>> EXACTLY what I'd like to see.
>>>however, issues popped up which stalled this effort.
>>>the result is that Java has not made "significant" inroads into my
>>>codebase,
>>>and so C remains as the primary VM language (as well as the implementation
>>>language).
>>>I am still left with doubts though, and if it goes anywhere may end up
>>>either using Apache's class library (instead of GNU ClassPath), or maybe
>>>writing my own mini class library ("java.lang" and maybe a few other
>>>areas,
>>>but leaving out most of the rest).
>> Well, I definetely think you should organize your material
>> and make a good site to publish your findings.
>> You never know, you might find some other people, crazy enough
>> to join your club.
>yep, dunno...
>>>similarly, finding a "better" option than JNI could help (VM-based scripts
>>>using JNI just seems horribly tacky...).
>>>>>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
>>>> than most of bells and whistles I see.
>>>yep.
>>>this is all more a matter of coding practices and architecture though,
>>>rather than any particular features.
>>>often, native OS-level API's do this far better than nearly any VM I am
>>>aware of.
>> Fine. So make a thin interface layer above it.
>> But make it platform independent.
>> What I, personally, want is a SINGLE way of writing something.
>> I want platform independence in STATICALLY scoped (typed :--})
>> languages. No matter what anybody says, I am still very hesitant
>> to jump into these dynamic languages. I did look at some of it,
>> but my heart is somehow not at rest with it. It says: nope,
>> it is a trap. Don't go there.
>yep.
>my past experience is that code ends up turning into dirt.
>one can write it quickly enough, but it likes to blow away in the wind.
Exactly.
>C is more like rocks in my case. they may be ugly and hard to work with at
>times, but at least they fall to the ground and generally stay there.
No questions about it.
>enough rocks and one has a mound...
>it stays there, but as a downside it is really heavy...
True. But I think people were simply blindly following some
incremental "imporvements", feeling comfortable like in a herd.
Secondly, we, as mankind, did have to go through all those
manifestations, just in order to see that is all nothing more
than fragmented views.
Now it seems the time is ripe to make something genuinely
exciting and I do not think guys like microsoft or sun can
stand on the way any longer.
For one thing, the open source idea gained WAY too much weight,
to the point that ms is getting challanged by linux world,
and specifically Ubuntu.
That guy from Africa seems to be a brilliant mind.
There is one other guy in the XML stage that is doing something
really impressive.
His name is Uche Ogbuii.
And amazing guy.
He's been working on his Akara/Amara stuff for quite a while,
and now it seems he's got a group of people who got interested
in it enough to give him some substantial help with it.
I bet we are in the middle of seeing something that will ring
some bells.
I am on the developers list even though I do not participate
in any way, and what I am seeing is lots of emails. All sorts
of work is being done and they've got this thing pretty much
humming by now.
I am keeping an eye on it, at least looking at some of those
emails. I think it is going to plug in at some point into
the system. It is a Python world. But what to do.
Gosh!
Why do they do python?!?
>> Most dynamic languages are way too limited.
>> I like to see ALL the bells and whistles of static approach,
>> such as threading, async handling, event structure, performance,
>> predictability of outcome, and things like that.
>ok.
But. Running totally portable like all these dynamic languages.
:--}
>>> this is mostly since most VM's try to package everything into "one
>>>size fits all" objects, and may end up with a big pile of different
>>>classes
>>>for every possible use case.
>> Yep. I do not like that aspect of it.
>> If you could construct that VM on the fly, depending on what exactly
>> my app requires, that would probably make the whole thing leaner.
>> Not sure how realistic the whole excersize is though.
>yep.
>it depends a lot on which parts are needed though, since there are annoying
>dependency issues.
>if all one needs is an assembler+linker or a GC, that is fairly easy...
>if one wants (in my case), VFS, dynamic types, Class/Instance OO facilities,
>.... then they also end up needing to include the assembler and the GC.
So what?
>the C compiler needs all of the above.
>....
>the x86 interpreter can operate standalone, but really likes to have the
>former facilities (I ended up making it take the "back-roads" approach of
>trying to load the DLLs and grab the interfaces, although I am generally
>displeased with this strategy since it goes against my usual aesthetic...).
>>>granted, generic facilities are often not as "nice" as in the "one size
>>>fits
>>>all" strategy (often, the more control that is given, the more internal
>>>patchwork that is visible), and having to bring up subsystems by getting
>>>and
>>>setting lots of pointers isn't very nice, but it does have some merits.
>> I could care less about what kind of magic you need to do
>> while that thing is constructed at run time.
>> As long as it buys me something at the end.
>ok, fair enough.
>I have some "pseudo-COM" stuff going on (if you have seen JNI, this is a
>fairly good idea of what I am talking about). some parts are plugged
>together with function-pointer structs, ...
The thing I saw in these kinds of things is extreme complexity
on the code writing end.
There does not seem to be a way to make it simple and you have to
waste years on yet another way of saying it. Too much of plumbing
work is exposed to program writer. It should be all nicely hidden
to my taste. It gets under your skin after a while, every time
they invent something "powerful".
It simply translates into you needing to learn yet another bible
worth of crap with all those lice, just waiting to get under your
skin.
>>>>>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.
>>>well, it is an ideal at least.
>>>the tangled bits and need to mess around with crap sometimes clouds the
>>>vision.
>> Just don't spread yourself too thin.
>> I am not sure you have resources to handle so many different aspects.
>hell, I don't think I have the resources either...
>however, I hesitent of pruning anything either, so this is sort of a
>dillema...
Well, one more time:
Get it WELL documented to sufficient enough degree of details.
Put some pictures in.
You won't be able to handle it all by yourself,
That much I don't have much doubt about.
You need more hands and brains involved.
And don't be worried that you are not a big gun, and "who cares".
How do you know that no one does?
Just right here, on this very group, there are people sitting
and wasting away pretty much from what I see, and their minds
are pretty much idling, just looking into someone elses pockets.
What a royal waste!
And that is NOT the end of the world.
You never know what might appear out of the blue.
You may not even know what you are working on and why.
Just TRUST.
Trust yourself in the MOST minute manifestation,
and do not worry about that big world. It is not as big as it looks.
>>>I guess it can be compared to trying to write an app making use of
>>>DirectX.
>>>luckily, much of this internal plumbing work is hidden in the details, but
>>>at the cost that this (doing initialization automatically), itself,
>>>creates
>>>more internal dependencies and issues.
>> Well, what do you expect if you are trying to reinvent the world?
>> :--}
>ok.
>>>>>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.
>>>ok.
>>>>>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.
>>>LLVM is another VM, but which mostly sets itself up as a generic compiler
>>>lower-end.
>>>my main complaint is that the design is very centralized, and also that
>>>the
>>>whole thing is written in C++ and in a style I am not particularly fond
>>>of.
>>>may seem odd, but I believe the lower-end compiler machinery should be,
>>>hopefully, decentralized and C-friendly (C++ can be used, but one should
>>>not
>>>expect any code which externally interfaces with it to do so by instancing
>>>or extending classes, ...).
>>>I am also not as fond of the single-class-per-file or manually including
>>>"teh crapload" of class-specific headers, mostly because it means having
>>>to
>>>open and dig through far too many files to really follow the code.
>> Well, Microsoft did not have that limitation, and I totally agree
>> with that one. But it seems to be some kind of necessity overall.
>> But what a royal pain it is. My main class source file is > 250k.
>> Not that it is such a big deal with modern IDEs. But still, I'd
>> prefer to see it split into smaller, logically related sections.
>in the LLVM case, most of the headers and source files are too small...
I do like the idea of the include files.
It is just another layer that does some useful things to you.
I asked the Java experts why is it they have gotten away with
include files. Do not recall hearing anything that made any kind
of sense to me.
>so, maybe one opens a file to find it contains maybe 100 lines, 15-20 are
>maybe header inclusions, and or a single class declaration, or maybe a few
>methods. trying to follow the code is difficult as lots of time goes into
>mostly opening and closing text editor windows...
>I think it may be though a result of people using Eclipse as an IDE, and
>Eclipse likes doing things this way?...
Well, not sure about this one.
>>>>>....
>>>>>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.
>>>there is ECMA-334 and 335, which essentially mean that, as far as these
>>>parts go, there is some level of openness. one can then implement which
>>>parts are defined in these standards, and ignore most of the rest, and
>>>technically MS is under their own legal obligations not to do anything
>>>about
>>>it.
>> I just do not trust those guys ANY way you cut it.
>> From what I've seen so far, these are just different kinds of traps,
>> but you do eventually get trapped in that gook. And it is amazing,
>> they did not realize how much they are hated by just about anyone
>> for setting up all these traps and being totally closed, ignoring
>> the rest of the world, like they are the only ones that have a final
>> say on what is what.
>yes, ok.
>>>granted, you wont get the whole ".NET framework" this way, but one can get
>>>C# and MSIL, which have a few merits.
>> Well, I do not mind C# as such. I am looking at some things in passing,
>> and yes, it does make SOME sense. I just fail to see what it boils down
>> to at the end and what specifically does it buy me.
>> I think people are too obscessed with compile time issues.
>> For example, in Java generics, there is this type erasure thing,
>> which means you loose your type during the run time.
>> Well, I do not like the mechanisms like these in principle.
>yes, ok.
>>>the problem, however, is that both are fairly complicated in their full
>>>form
>>>(much more so than the JVM equivalents), and so would take a far higher
>>>resource involvement to really implement effectively.
>> I just do not see what does it buy me at the end.
>> If your program is "incorrect", you can not be saved by compilers.
>> Those are just small things that won't make your program "better".
>> Because you prolly have holes in your architecture and design.
>> People still write plenty of code in straigt C.
>> For some strange reason, it is all over the place.
>> And the more stable, more performing code, the more you get to the
>> kernel level, the closer you tend to move toward C.
>yes, it is odd.
>I had liked it, since in theory it could offer a good tradeoff between C and
>Java.
>nevermind that it is big and complicated.
>>>>>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.
>>>yep.
>>>>>(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!
>>>yep.
>> Wow!
>> I am impressed.
>>>it is mostly used for scripting.
>>>for most other things though, I am using good old static C compilers (GCC
>>>and MSVC), which do most of the "heavy lifting" as it were.
>>>my compiler is binary compatible with the static compilers (so I don't
>>>need
>>>a FFI for C-based scripts).
>>>>>but, ideally, an app will "use" a framework, rather than be "built on
>>>>>top
>>>>>of" it,
>>>> What do you mean by that?
>>>an app which uses something may continue to function without the object in
>>>question, or may supply a substitute.
>> Cool. You are pretty inventive I'd say.
>> :--}
>the usual strategy is to provide fallbacks.
>something being missing causes it to use the fallback, which may be either a
>simpler OS-provided facility, or if needed, a no-op facility.
I like that one.
>this actually works fairly well in the majority of cases.
>a lego by itself is still a lego, even if it doesn't necessarily do a whole
>lot.
>this is partly an "interesting" side effect of trying to keep code highly
>modular, and plugging it together with interfaces:
>in many cases, a component can be pulled or replaced, and other code will
>often compensate automatically.
Cool.
>>>an app which is "built on top of" something, can't be reasonably expected
>>>to
>>>function without it.
>>>for example, an app may use a GUI toolkit, or several of them, and then
>>>some
>>>way exists in which to "choose" which one to use (via build options, or
>>>even
>>>at runtime), or the app could provide a fallback (no GUI is available, so
>>>it
>>>falls back to a custom and more-simplistic interface, such as a
>>>command-line, or simple custom-drawn widgets).
>> You are really something else, I tellya.
>> :--}
>it is not that novel.
>for example, many games will often do something similar, possibly trying
>several different methods of getting the video and sound up and running
>before ultimately giving up.
>it can also be compared to how the OS uses drivers...
>how flexible would an OS be if everything were hard-coded?...
>so, usually most major components may have alternatives and fallbacks, and
>most APIs can be designed as abstract interfaces where the machinery can be
>replaced.
>if OS kernels were written like how many apps were written, then the mess
>which we would have would be horrible...
Yep. That is one of the core priciples of O/S,
which separates things to user and kernel mode.
Once you are at a kernel leval, you are the king
and you know things are clean.
And you provide the interface to all sorts of crazy people with
their user apps, so they clearly know which kinds of things they
are allowed to touch in the system.
Else, the whole thing is nothing more than insane asylum.
>>>an app "built on top of" a GUI toolkit can't easily do this, and would
>>>essentially need to be "ported" to the new toolkit, that or discarded and
>>>rewritten.
>> Yep, I do like an idea of dynamic wiring.
>yep.
>>>many toolkits and frameworks though are written to assume such a level of
>>>dependency, and are problematic to try to use in such a way which does not
>>>in some way significantly impact the app with which they are used, and
>>>often
>>>will not play well with another toolkit which does essentially the same
>>>thing, since inevitably they will conflict over some or another "prized"
>>>resource and would step on each other if one tried to use both.
>>>>> 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.
>>>historically, probably...
>>>initially, MS implemented J# and their own customized (and MSified) JVM.
>>>Sun did not take too keenly to their effort, and so there was a lawsuit.
>>>shortly thereafter, MS made a new language: C#, which kept much in common
>>>with Java (but added many syntax changes and new features).
>> That is what I meant.
>> I just saw too many Javaish things in C#, the whole MVM concept,
>> and I bet the whole .net trip is the same thing.
>> That is why I called them what I did.
>> And I would not doubt in my mind that they intended to screw Sun
>> at the end so they could suck in as many people into the webs
>> they weave and Sun, for obvious reasons, barked at that.
>> Not sure what I'd do in their place.
>> But to take upon the microsoft, even if you get paid tons of bux
>> at the end, was the end of Java, at least to vast majority of
>> boxes out there. I think ms dropping java is probably the most
>> monumental move in the entire history of sw industry.
>yes, ok.
>>>they also created MSIL / CIL, which shares many commonalities with JBC,
>>>but
>>>also differs in many ways as well.
>>>>> 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).
>>>yeah, a lot is just hacks and extensions of prior technologies.
>>>MZ/EXE (from MS-DOS) and COFF (from Unix) were hacked together to produce
>>>PE/COFF (used in 32-bit EXE's from Win95 and NT4 onwards).
>> Its a pitty that people who initially concieved and designed these
>> things did not even get a penny out of it.
>> It was all repackaged and stamped with "copyright" or "patent" stamp.
>> Simply disgusting.
>> I did have some direct experience with MS a while back.
>> What they asked me essentially is this: you give us your product
>> for FREE and we will include it in OUR package, the O/S.
>> And we won't pay you a penny in return.
>> But you do get to be "approved" by us and we will get more money
>> as a result of including more and more blood from the people and
>> companies like you.
>> I said: screw you and screw your whole trip. No deal.
>> Those suckers did not even offer a PENNY.
>> What a disgusting bunch of sickos, sucking blood from everyone
>> they can get their hands upon.
>yes, ok.
>well, I think some amount of the Windows NT line was based on grabbing up a
>bunch of source from BSD.
>I found it mildly ammusing to have been looking at one of their SDKs, and
>noting a copy of both the zlib and libjpeg liscense agreements...
I just can not see why people are so much obscessed with money.
Why do they think it is an ULTIMATE measure of ANYTHING?
What is this "fear of survival" as I call it?
I could never see the point of it, even though I saw ALL sorts of things.
And I can comprehend how "horrible" it looks,
if you can not "survive".
So people resourt to licking the rear end of those "powerful",
just be allowed to be in the herd.
Brrrr.
>>>then a bunch more crap was hacked on to create MSIL Images, which are
>>>basically PE/COFF with a bunch of relational tables and stuff added, and
>>>MSIL bytecode thrown in.
>>>I also ended up using PE/COFF, mostly for compatibility reasons, but most
>>>of
>>>my metadata notably differs (my metadata is not based on a relational
>>>structure, but is instead a heirarchical DB, mixed with some other parts
>>>which are based on a TLV structure loosely similar to RIFF or PNG,
>>>although
>>>by default a bit more compact...).
>> About the pittiest thing in this whole thing is that people
>> like Gary Kildall simply get slaughtered at the end, while these
>> parasites make a killing on the work of others.
>well, CP/M was ripped off to make MS-DOS, and DOS was extended with a MacOS
>immitation to make Windows 3.x, and was fused with DOS to make Windows 95.
>elsewhere, the BSD codebase was grabbed up and largely reworked into NT,
>some parts of which were common with Win95.
Well, at one point I had a full souce to Win2k and had a chance
to see some of it. Not that it was of any use.
>MS-DOS MZ-EXE header + BSD's COFF binaries became PE/COFF (replacing the
>Win3x NE format, which was partly a horridly hacked DOS EXE I think with an
>alternate entry point for Win16 code, and also LE which had been used I
>think for Win32s and early Win95, ...).
>....
>well, no one ever really said they had to be original...
>"embrace and extend", as the story goes, as one "rides on the shoulders of
>giants"...
Well, it is all nice and dandy.
But how come the society did not find a way to compensate those,
that do the real work and create things that eventually get wired
into the "real" products and gazillions of bux are made off it,
while the original creators do not get a penny?
Are we THAT dumb?
And I know we are. Too much zombification is no good for you.
But it is time to put an end to this.
LONG time due in fact.
>>>> 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.
>>>ok.
>>>>>(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.
>>>as-is, I don't even really have "java.lang" in place, and so most of what
>>>goes on would require plugging into C land
>> Coolio! :--}
>>>(and at the moment, likely
>>>writing far more JNI code than actual Java).
>>>similarly, it looks like a hassle to plug classpath into my project, as I
>>>would have to write a lot of machinery to glue it.
>>>possibly, I could try to go and write some wrappers for some of my C based
>>>APIs, and then build some of the core Java API's on top of these.
>>>so far, I have not done much of the sort.
>>>>>> 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.
>>>yeah, probably a real horror that.
>>>>> 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...
>>>it is fairly generic compiler stuff here.
>>>a JIT is likely to be faced with many of the same issues.
>>>just, translating stack operations into variable operations is a little
>>>cheaper than faking the stack, and with JBC's restrictions, does not add
>>>notably to the complexity.
>>>a few of the ugly edge cases are mostly that there are a few opcodes which
>>>assume a stack composed of 32-bit items and make some assumptions WRT item
>>>size, which, errm, kind of turn ugly when dealing with an abstract stack.
>>>>>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.
>>>ok.
>>>>>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 does not map from MFC to Java that well.
>>>> Basically, 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.
>> I know. I am still struggling with some totally ridiculous stuff,
>> just trying to resize some nested GUI stuff. The stupidest thing
>> in the world and the amount of time I had to waste on it is just
>> monumental compared to the functionality I was after. That same
>> thing is a sneeze doing it in java and using nothing more than
>> gridbag layouts.
>yes, ok.
>>>never really used MFC, though had used GDI+ some in the past.
>>>mostly I use OpenGL and do my own widget drawing via GL, although there
>>>are
>>>drawbacks.
>> Well, I used it from the day one. Basically, it is just an object
>> oriented C++ wrapper for win32. So, I started using it as my main thing.
>> Never regretted it, except when you have some nasty details
>> and primarily in the GUI end of it, if you are writing some
>> flexible GUI code.
>yeah.
>I mostly used GL since I do a lot of 3D stuff...
>apparently, this is the same kind of thing as most 3D modeling packages, ...
>>>>>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.
>> I mean the firewall app.
>'k.
>>>> 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.
>>>ok.
>>>>>....
>>>>>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.
>>>Java ByteCode.
>> Oh, Jeez!
>> :--}
>> Thats about the last thing I would even think about it.
>> I thought it is some kind of gadget.
>yes, ok.
>>>>>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.
>>>ok.
>>>can't much help here...
>>>compiling code is a much simpler task than converting between API's...
>>>>>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.
>>>ok.
>> What can I say, it is a pitty, society does not support the guys
>> like you and give them some basic funding just to be able to exist.
>> Because I think people like you can contribute more to the whole
>> equation, that most of the big mouths out there, called "experts".
>> Good luck.
>yes, ok.
--
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: Sun, Dec 27 2009 6:12 am
From: tanix@mongo.net (tanix)
In article <4b373ce8$0$1111$4fafbaef@reader2.news.tin.it>, "io_x" <a@b.c.invalid> wrote:
>
>"tanix" <tanix@mongo.net> ha scritto nel messaggio
>news:hh6heo$2lo$1@news.eternal-september.org...
>> In article <hh66vr$scn$1@news.albasani.net>, "BGB / cr88192"
>> <cr88192@hotmail.com> wrote:
>bla bla bla
>
>again
>one general language
>1) using a portable thypes
> eg u8 == unsigned 32 bits
> u32== unsigned 32 bits
> i32== int 32 bits
> etc and operation on them
>2) eliminate all the undefinited behaviour on the languages
>--------------------
>1) or use one PC virtual machine (all x86 + hardware of one pc, all virtual)
> that rapresent x86 PC and whatever you want: eg compiler etc
> and install that in each machine even if have different cpu and hardware
What is this?
--
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: Gigantic Class
http://groups.google.com/group/comp.lang.c++/t/b3756783d92fd56a?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Dec 27 2009 3:03 am
From: "Bo Persson"
Immortal Nephi wrote:
> I consider to use either object-based programming or object-oriental
> programming. I am not sure to choose the correct programming
> paradigms. I start with object-based programming because I need
> encapsulation.
> I provide client the interface. The client uses it to define object
> in main() function body. They invoke object�s public member
> functions. The object�s public member functions do the job to
> process algorithm. All private member functions and implementation
> details are hidden.
> The base class is growing too big because I add more private member
> functions. I debug and test them to be working properly. They are
> less reusability. You will say that gigantic class is bad practice.
> Why do you think that gigantic class is truly necessary?
> I get quote from The ANSI / ISO C++ Professional Programmer�s
> Handbook.
>
> Gigantic class
>
> There are no standardized methods for measuring the size of a class.
> However, many small specialized classes are preferred to a bulky
> single class that contains hundreds of member functions and data
> members. But bulky classes do get written. Class std::string has a
> fat interface of more than 100 member functions; clearly this is an
> exception to the rule and, to be honest, many people consider this
> to be a compromise between conflicting design approaches. Still,
> ordinary programs rarely use all these members. More than once,
> I�ve seen programmers extending a class with additional member
> functions and data members instead of using more plausible
> object-oriental techniques such as subclassing. As a rule, a class
> that extends a 20-30 member function count is suspicious.
> Gigantic classes are problematic for at least three reasons: users
> of such classes rarely know how to use them properly, the
> implementation and interface of such classes tend to undergo
> extensive changes and bug-fixes; and they are not good candidates
> for reuse because the fat interface and intricate implementation
> details can fit rarely only a very limited usage. In a sense,
> large classes are very similar to large functions.�they are
> noncohesive and difficult to maintain.
>
> [end of quote]
>
>
> How do you solve to divide into hundreds of subclasses from one
> giant class? Inheritance is the answer, but you write derive class
> to use **some** or **all** inherited member functions. You don�t
> want client to use all inherited member functions. They only need
> to derive class through private inheritance.
>
> For example:
>
> class A
> {
> public:
> A() : a( 1 ), b( 2 ) {}
> ~A() {}
>
> protected:
> int a;
> int b;
> };
>
> class B : public A
> {
> public:
> B() : c( 3 ), d( 4 ) {}
> ~B() {}
>
> protected:
> int c;
> int d;
> };
>
> class C : public B
> {
> public:
> C() : e( 5 ), f( 6 ) {}
> ~C() {}
>
> protected:
> int e;
> int f;
> };
>
> class D : private C
> {
> public:
> D() : g( 7 ), h( 8 ) {}
> ~D() {}
> void Run()
> {
> a += 100;
> b += 200;
> c += 300;
> d += 400;
> e += 500;
> f += 600;
> g += 700;
> h += 800;
> }
>
> protected:
> int g;
> int h;
> };
>
> class E : public D
> {
> public:
> E() : i( 9 ), j( 10 ) {}
> ~E() {}
> void Run()
> {
> D::Run();
> i = 900;
> j = 1000;
> }
>
> private:
> int i;
> int j;
> };
>
> int main()
> {
> E e; // object e is the interface
> e.Run(); // Run() is available to client.
> Return 0;
> }
>
It is hard to reason about classes named A, B, and C, because that
makes it very abstract. A real class hierarchy usually is a model of
"something", where the structure of "something" often helps in
designing the model.
Most often it helps if a class does one thing, and one thing only. It
should do its "thing", and possibly maintain an internal state that it
might need (an invariant). Having protected data members breaks this,
as the class can no longer take responsibility for its own state.
Therefore protected data is very rarely used.
Unlike Java, in C++ there is generally no requirement for a single
base class. Using templates, all classes conforming to an interface
can be used as arguments to a function.
Bo Persson
== 2 of 4 ==
Date: Sun, Dec 27 2009 3:43 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
Immortal Nephi <Immortal_Nephi@hotmail.com> writes:
>However, many small specialized classes are preferred to a bulky
Such metrics look superficial to me. For example, when the
specialized classes are very similar to each other, they
should be combined into a slightly larger but more general
class (DRY). It always depends also on other factors then
just the size in isolation.
>members. But bulky classes do get written. Class std::string has a
Yes, yes! Go ahead and write it! It is never a mistake to
write a huge bulky class. It is only a mistake to stop there
and not refactor it. Usually, /after/ the bulky class has been
written one sees oportunities to split it or to extract classes
from it, thus it gets smaller, usually. And in the 0,1 % of all
cases, when there is no reasonable refactor to make it smaller,
it really needs to be that big. Usually, »god class« is an anti-
pattern, but under rare circumstances it might become a pattern.
A typical cell size is 10 µm, but the ostrich egg cell is
15 centimetres (5.9 in) long, 13 centimetres (5.1 in) wide,
and weighs 1.4 kilograms (3.1 lb).
>class? Inheritance is the answer, but you write derive class to use
This is just one answer. And also seen to be an anti-pattern by
some (as implementation inheritance - not interface inheritance).
You need to know several refactors and apply each of them when
appropriate. There are several refactors that will reduce the
size of a class.
== 3 of 4 ==
Date: Sun, Dec 27 2009 9:21 am
From: Immortal Nephi
On Dec 27, 5:03 am, "Bo Persson" <b...@gmb.dk> wrote:
> Immortal Nephi wrote:
> > I consider to use either object-based programming or object-oriental
> > programming. I am not sure to choose the correct programming
> > paradigms. I start with object-based programming because I need
> > encapsulation.
> > I provide client the interface. The client uses it to define object
> > in main() function body. They invoke object s public member
> > functions. The object s public member functions do the job to
> > process algorithm. All private member functions and implementation
> > details are hidden.
> > The base class is growing too big because I add more private member
> > functions. I debug and test them to be working properly. They are
> > less reusability. You will say that gigantic class is bad practice.
> > Why do you think that gigantic class is truly necessary?
> > I get quote from The ANSI / ISO C++ Professional Programmer s
> > Handbook.
>
> > Gigantic class
>
> > There are no standardized methods for measuring the size of a class.
> > However, many small specialized classes are preferred to a bulky
> > single class that contains hundreds of member functions and data
> > members. But bulky classes do get written. Class std::string has a
> > fat interface of more than 100 member functions; clearly this is an
> > exception to the rule and, to be honest, many people consider this
> > to be a compromise between conflicting design approaches. Still,
> > ordinary programs rarely use all these members. More than once,
> > I ve seen programmers extending a class with additional member
> > functions and data members instead of using more plausible
> > object-oriental techniques such as subclassing. As a rule, a class
> > that extends a 20-30 member function count is suspicious.
> > Gigantic classes are problematic for at least three reasons: users
> > of such classes rarely know how to use them properly, the
> > implementation and interface of such classes tend to undergo
> > extensive changes and bug-fixes; and they are not good candidates
> > for reuse because the fat interface and intricate implementation
> > details can fit rarely only a very limited usage. In a sense,
> > large classes are very similar to large functions. they are
> > noncohesive and difficult to maintain.
>
> > [end of quote]
>
> > How do you solve to divide into hundreds of subclasses from one
> > giant class? Inheritance is the answer, but you write derive class
> > to use **some** or **all** inherited member functions. You don t
> > want client to use all inherited member functions. They only need
> > to derive class through private inheritance.
>
> > For example:
>
> > class A
> > {
> > public:
> > A() : a( 1 ), b( 2 ) {}
> > ~A() {}
>
> > protected:
> > int a;
> > int b;
> > };
>
> > class B : public A
> > {
> > public:
> > B() : c( 3 ), d( 4 ) {}
> > ~B() {}
>
> > protected:
> > int c;
> > int d;
> > };
>
> > class C : public B
> > {
> > public:
> > C() : e( 5 ), f( 6 ) {}
> > ~C() {}
>
> > protected:
> > int e;
> > int f;
> > };
>
> > class D : private C
> > {
> > public:
> > D() : g( 7 ), h( 8 ) {}
> > ~D() {}
> > void Run()
> > {
> > a += 100;
> > b += 200;
> > c += 300;
> > d += 400;
> > e += 500;
> > f += 600;
> > g += 700;
> > h += 800;
> > }
>
> > protected:
> > int g;
> > int h;
> > };
>
> > class E : public D
> > {
> > public:
> > E() : i( 9 ), j( 10 ) {}
> > ~E() {}
> > void Run()
> > {
> > D::Run();
> > i = 900;
> > j = 1000;
> > }
>
> > private:
> > int i;
> > int j;
> > };
>
> > int main()
> > {
> > E e; // object e is the interface
> > e.Run(); // Run() is available to client.
> > Return 0;
> > }
>
> It is hard to reason about classes named A, B, and C, because that
> makes it very abstract. A real class hierarchy usually is a model of
> "something", where the structure of "something" often helps in
> designing the model.
Class A has all responsibility to handle private data members and
private member functions. Derived class B, C, and D do not make any
senses. You have no reason to inherit class A's private data members
to class B through additional new class A's public member functions.
I am like class A designer does not want clients to use inheritance
and they only need to define and use class A in their own function
body.
> Most often it helps if a class does one thing, and one thing only. It
> should do its "thing", and possibly maintain an internal state that it
> might need (an invariant). Having protected data members breaks this,
> as the class can no longer take responsibility for its own state.
> Therefore protected data is very rarely used.
I agree with you. Class A does only one thing. One thing has some
internal states. Some internal states are defined in private data
members inside class A. All private member functions maniuplate
internal states directly. Some private member functions are added in
public member functions and the client only needs to invoke public
member function.
The client is allowed to derive class from class A, but they are
denied if they attempt to inherit private data members into derived
class B because protected data is not defined.
> Unlike Java, in C++ there is generally no requirement for a single
> base class. Using templates, all classes conforming to an interface
> can be used as arguments to a function.
Sometimes, I do not need to add templates to class A. The client only
needs to use one data type such as int when they put arguments into
public member function's parameters. They can define one or more
class A objects in their function body. Also, they can use STL such
as vector. They put more class A objects in vector like five class A
objects in one array. The vector has template because class A is
defined user type.
For example:
int variable = 100;
A a1( variable );
A a2( variable + 1 );
A a3; // use default constructor as a3()
A oneArray[5];
vector < A > ( oneArray, 5 );
Make sense?
== 4 of 4 ==
Date: Sun, Dec 27 2009 9:54 am
From: Immortal Nephi
On Dec 27, 5:43 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Immortal Nephi <Immortal_Ne...@hotmail.com> writes:
> >However, many small specialized classes are preferred to a bulky
>
> Such metrics look superficial to me. For example, when the
> specialized classes are very similar to each other, they
> should be combined into a slightly larger but more general
> class (DRY). It always depends also on other factors then
> just the size in isolation.
>
> >members. But bulky classes do get written. Class std::string has a
>
> Yes, yes! Go ahead and write it! It is never a mistake to
> write a huge bulky class. It is only a mistake to stop there
> and not refactor it. Usually, /after/ the bulky class has been
> written one sees oportunities to split it or to extract classes
> from it, thus it gets smaller, usually. And in the 0,1 % of all
> cases, when there is no reasonable refactor to make it smaller,
> it really needs to be that big. Usually, »god class« is an anti-
> pattern, but under rare circumstances it might become a pattern.
"god class"? Are you referring that giant class A is perfect with
free bugs unless you have already debugged and tested and it is to be
working properly?
> A typical cell size is 10 µm, but the ostrich egg cell is
> 15 centimetres (5.9 in) long, 13 centimetres (5.1 in) wide,
> and weighs 1.4 kilograms (3.1 lb).
>
> >class? Inheritance is the answer, but you write derive class to use
>
> This is just one answer. And also seen to be an anti-pattern by
> some (as implementation inheritance - not interface inheritance).
If inheritance is not the answer because protected data members and
protected member functions are not defined, what is the solution? You
might say that composition is the answer. Create hundreds of base
subclasses. Put them into one base main class. How can base
subclasses access base main class' private data members?
I showed you my example as class A, B, C, and D through public
inheritance above. Convert from inheritance to composition. Let's
say for example. class B, C, and D are considered to be base
subclasses and class A is considered to be base main class. Class B,
C, D can't access class A's private data members unless you add friend
class B, C, and D in class A. Class A needs to access class class B,
C, and D's member functions before class B, C, D's member functions in
turn to access class A's private data members directly.
class B { public: /* member functions access A's private data members
*/ };
class C { public: /* member functions access A's private data members
*/ };
class D { public: /* member functions access A's private data members
*/ };
class A
{
friend class B
friend class C
friend class D
public: /* member functions access class B, C, D's member functions */
private: /* private internal states as data members */
B b;
C c;
D d;
};
Class A's data members are always undefined because class A body is
not declared in the top before class B, C, and D are defined. I guess
that composition is not the answer. How do you have the solution?
==============================================================================
TOPIC: Hot sale Air force one shoes, Nike air max, Nike Shox paypal payment
free shipping (www.vipchinatrade.com)
http://groups.google.com/group/comp.lang.c++/t/c3a39c1719ab4760?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 27 2009 5:21 am
From: yoyotrade
Cheap Wholesale Nike Air Max 87 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 89 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 90 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 91 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 92 Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 93 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 95 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 97 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 180 Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 2006 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max 2009 <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max Clssic BW <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max LTD <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max Skyline <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max STAB <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max Tailwind <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Nike Air Max TN <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Shox NZ <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox OZ <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox R2 <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox R3 <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox R3+R4 <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox R4 <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox R5 <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox Reverie lover
Cheap Wholesale Shox RZ <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox TL <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox Torch <www.vipchinatrade.com> paypal payment
Cheap Wholesale Shox TZ <www.vipchinatrade.com> paypal payment
Air Force one <www.vipchinatrade.com> paypal payment
Cheap Wholesale Air Force One Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force One Women <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force One M&W <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force one 25 Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force One 25 Women <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force One Kid <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force one Mid Man <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force one Mid Women <www.vipchinatrade.com> paypal
payment
Cheap Wholesale Air Force one Hight Women <www.vipchinatrade.com>
paypal payment
Cheap Wholesale Nike shoes <www.vipchinatrade.com> paypal payment
Cheap Wholesale Nike Dunk SB <www.vipchinatrade.com> paypal payment
Cheap Wholesale Nike RLFT <www.vipchinatrade.com> paypal payment
==============================================================================
TOPIC: Exception Misconceptions: Exceptions are for unrecoverable errors.
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 27 2009 6:32 am
From: "Balog Pal"
"James Kanze" <james.kanze@gmail.com>
>> So you use the same tech -- the destructor sits there to carry
>> out the responsibility that is left over.
>
> There is a similarity: additional actions may be needed when an
> exception has been thrown. But the word "resource" (or even
> "responibility") seems too limiting. I prefer talking in terms
> of program coherence (in which invariants are maintained): the
> coalition takes place in the other sense: when the program is
> coherent, for example, no one holds a mutex lock, or other
> resources that won't be used.
Hm, to me that is what sounds strange. To me mutex locking means a ctirical
section of code, and has nothing to do with invariants or coherence.
And invariant means something that holds. And supposed to. It may be broken
for some special technical reason (like not having atomic multi-assign), but
it better be avoided. While critical sections are totally meant to be
entered, and perfectly natural.
>> > 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.
>
> In general: it's best to do anything that might throw before
> changing any state. (That principle predates the swap idiom by
> some decades:-).)
Sure, that just comes from the fact that an UNDO action is often far from
trivial even in theory, and doing it may fail just like the operation that
went forward. We rather avoid such potentially hopeless situations. ;-)
> The swap idiom is just a fairly simple way of
> expressing it in C++ (and letting destructors handle the
> clean-up in both the error cases and the normal case). But if
> you're interested, an analysis of the constructor code for
> boost::shared_ptr is illuminating; doing things correctly
> requires some thought.
I did study that constructor when it was a new thing (guess like a decade
ago), and it was definitely illuminating. IIRC it was before Herb's
Exceptional... books, and the Abrahams guarantees were either in the future
or new stuff.
By today the scene hopefully is different, that material is considered
fundamental for a long time. And have high attention in interviews for a
C++ position and code reviews.
> Independantly of the language:
> destructors do help in the implementation details, but the
> initial analysis is still necessary.
I didn't say otherwise -- just dtors are a great tool that works like pyro
seat belts. And are good to have even if you stop the car in time.
>> > (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?
>
> Defining clearly what pointers have to be freed, when. In
> general, the implementation doesn't require much effort, once
> you've defined clearly what has to be done.
In normal cases we want to avoid that very problem. In ctor, and related
stuff -- copy ctor, op=, possibly others. The way to avoid it is to NOT use
raw pointers as members like shared_ptr does. But use smart members or a
base class.
That side-step the problem for good.
The smart pointer suite itself is IMO quite a special case. :)
Not to be done -- or trusted to a real expert. Who certainly spent his time
studying the existing implementations, and is aware of those problems.
==============================================================================
TOPIC: ♣°ω°♣ cheap wholesale pants belts bikinis underwear at www.ecyaya.com
http://groups.google.com/group/comp.lang.c++/t/7fe8ea65ab863cc8?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 27 2009 6:29 am
From: hero
♣°ω°♣ cheap wholesale pants belts bikinis underwear at www.ecyaya.com
fahionable pants
cheap wholesale A&F Pants with high quality and low price on www.ecyaya.com
cheap wholesale Affliction Pants with high quality and low price on
www.ecyaya.com
cheap wholesale Artful Dodger Pants with high quality and low price on
www.ecyaya.com
cheap wholesale Bape Pants with high quality and low price on www.ecyaya.com
cheap wholesale BBC Pants with high quality and low price on www.ecyaya.com
cheap wholesale Christian Audigier Pants with high quality and low
price on www.ecyaya.com
cheap wholesale Coogi Pants with high quality and low price on www.ecyaya.com
cheap wholesale ED Hardy Pants with high quality and low price on
www.ecyaya.com
cheap wholesale Evisu Pants with high quality and low price on www.ecyaya.com
cheap wholesale RMC Pants with high quality and low price on www.ecyaya.com
cool belts
the hottest Afflirtion Belt with high quality and low price on www.ecyaya.com
the hottest Armani Belt with high quality and low price on www.ecyaya.com
the hottest Bape Belt with high quality and low price on www.ecyaya.com
the hottest Boss Belt with high quality and low price on www.ecyaya.com
the hottest Burberry Belt with high quality and low price on www.ecyaya.com
the hottest C.D Belt with high quality and low price on www.ecyaya.com
the hottest Chanel Belt with high quality and low price on www.ecyaya.com
the hottest CK Belt with high quality and low price on www.ecyaya.com
the hottest D&G Belt with high quality and low price on www.ecyaya.com
the hottest Diesel Belt with high quality and low price on www.ecyaya.com
the hottest DSQ Belt with high quality and low price on www.ecyaya.com
the hottest ED Belt with high quality and low price on www.ecyaya.com
the hottest Gucci Belt with high quality and low price on www.ecyaya.com
the hottest Hermes Belt with high quality and low price on www.ecyaya.com
the hottest Levfs Belt with high quality and low price on www.ecyaya.com
the hottest LV Belt with high quality and low price on www.ecyaya.com
the hottest Polo Belt with high quality and low price on www.ecyaya.com
the hottest Prada Belt with high quality and low price on www.ecyaya.com
the hottest Versace Belt with high quality and low price on www.ecyaya.com
beautiful bikinis
cheap wholesale Bureriy Swimming with high quality and low price on
www.ecyaya.com
cheap wholesale Chanel Swimming with high quality and low price on
www.ecyaya.com
cheap wholesale Ed Hardy Swimming with high quality and low price on
www.ecyaya.com
cheap wholesale Gucci Swimming with high quality and low price on
www.ecyaya.com
cheap wholesale LV Swimming with high quality and low price on www.ecyaya.com
cheap wholesale Touse Swimming with high quality and low price on
www.ecyaya.com
well-selling underwear
cheap wholesale A&F Underwear with high quality and low price on
www.ecyaya.com
cheap wholesale Armani Underwear with high quality and low price on
www.ecyaya.com
cheap wholesale BOSS Underwear with high quality and low price on
www.ecyaya.com
cheap wholesale CK Underwear with high quality and low price on www.ecyaya.com
cheap wholesale Ed Hardy Underwear with high quality and low price on
www.ecyaya.com
cheap wholesale LV Underwear with high quality and low price on www.ecyaya.com
==============================================================================
TOPIC: Saving a binary file into a string
http://groups.google.com/group/comp.lang.c++/t/ddc89ddf30293133?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 27 2009 7:39 am
From: Dominik Schmidt
Hi,
I'm new to C++, so I have a very basic question.
I wrote a function which opens a file and saves it into a string variable.
Another function can save a string variable into a file.
I tried to combine those two functions, because in combination they should
make an exact copy of a file. And it seems to work, in every case the copy
had the exact same hash value (MD5) as the original file.
I'd like to know if I made an error, so if there's any possibility that my
functions won't work in some case?
Just to be sure: 1 Byte can have 2^8 = 256 different states, so each
"character" of a string variable can have those 256 states, right? Every
byte of a file can be saved in a string variable? If this is true, there
can be no file which can *not* be copied by my functions (except it's too
big)?
Thanks in advance for any tip!
================
Here is my code:
================
int main()
{
string var1;
var1 = OpenFile("D:\\myfile1.bin");
SaveFile("D:\\myfile1-copy.bin", var1);
return 0;
}
string OpenFile(string FilePath)
{
string Out1;
ifstream file1;
char Chr1;
string Str1;
long long filesize;
filesize = GetFileSize(FilePath);
file1.open (FilePath.c_str(), ios::binary);
if (file1.is_open())
{
for (long long i = 0; i < filesize; i++)
{
file1.read (&Chr1, 1);
Str1 = Chr1;
Attach (&Out1, Str1);
}
}
file1.close ();
return Out1;
}
void SaveFile(string FilePath, string FileContent)
{
ofstream file1;
long long filesize;
char Chr1;
filesize = FileContent.length();
if (FileExists(FilePath)) KillFile(FilePath);
if (FileExists(FilePath)) return;
if (filesize < 0) return;
file1.open (FilePath.c_str(), ios::binary);
if (file1.is_open())
{
for (long long i = 0; i < filesize; i++)
{
Chr1 = FileContent[i];
file1.write (&Chr1, 1);
}
}
file1.close();
}
//Here are the dependencies:
long long GetFileSize(string FilePath)
{
long long Out1 = -1;
ifstream file1;
file1.open (FilePath.c_str());
if (file1.is_open())
{
file1.seekg(0, ios::end);
Out1 = file1.tellg();
}
file1.close();
return Out1;
}
bool FileExists(string FilePath)
{
//http://msdn.microsoft.com/en-us/library/aa365740%28VS.85%29.aspx
WIN32_FIND_DATA FindFileData;
HANDLE hFind = FindFirstFile(FilePath.c_str(), &FindFileData);
if (hFind == INVALID_HANDLE_VALUE || (FindFileData.dwFileAttributes &
FILE_ATTRIBUTE_DIRECTORY))
{
return false;
}
else
{
return true;
}
}
void Attach(string *OldString, string AddString, bool InNewLine)
{
if (InNewLine)
{
*OldString += Cr;
*OldString += Lf;
}
*OldString += AddString;
}
bool KillFile(string FilePath)
{
int Out1;
Out1 = remove(FilePath.c_str());
return Out1 == 0;
}
== 2 of 2 ==
Date: Sun, Dec 27 2009 9:39 am
From: Rune Allnor
On 27 Des, 16:39, Dominik Schmidt <dominikschmi...@gmx.net> wrote:
> Hi,
>
> I'm new to C++, so I have a very basic question.
> I wrote a function which opens a file and saves it into a string variable.
> Another function can save a string variable into a file.
> I tried to combine those two functions, because in combination they should
> make an exact copy of a file. And it seems to work, in every case the copy
> had the exact same hash value (MD5) as the original file.
>
> I'd like to know if I made an error, so if there's any possibility that my
> functions won't work in some case?
There is the possibility, yes.
Some byte values or sequences of byte values take on special
meanings like 'end of line' or 'end of string' in the context
of text files and strings.
If you want to work with binary files, use std::vector<char>
or something like that, instead of std::string. That way all
characters are treated as arbitrary numbers, with no special
significance attached to any of them.
Rune
==============================================================================
TOPIC: Discount wholesale Chanel Handbags Miumiu,LV,Juicy,Gucci, Fendi,
Burberry,D&G,Jimmy Choo(www.vipchinatrade.com)
http://groups.google.com/group/comp.lang.c++/t/126c1693082e7a31?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 27 2009 9:08 am
From: yoyo
Discount wholesale Handbags
AAA real leather Handbags
Cheap Wholesale Balenciaga real leather Handbags
<www.vipchinatrade.com paypal payment>
Cheap Wholesale Balenciaga real leather Purse
Cheap Wholesale Bally real leather Purse <free shipping paypal
payment>
Cheap Wholesale BOSS real leather Purse <www.vipchinatrade.com paypal
payment>
Cheap Wholesale Burberry real leather Handbags
Cheap Wholesale Chanel real leather Handbags <free shipping paypal
payment>
Cheap Wholesale Chanel real leather Purse
Cheap Wholesale Chloe real leather Handbags
Cheap Wholesale Chloe real leather Purse <free shipping paypal
payment>
Cheap Wholesale Coach real leather Handbags
Cheap Wholesale Coach real leather Purse <www.vipchinatrade.com paypal
payment>
Cheap Wholesale D&G real leather Handbags
Cheap Wholesale D&G real leather Purse
Cheap Wholesale Dior real leather Handbags <free shipping paypal
payment>
Cheap Wholesale Dunhill real leather Purse
Cheap Wholesale Fendi real leather Handbags <free shipping paypal
payment>
Cheap Wholesale Gucci real leather Handbags <www.vipchinatrade.com
paypal payment>
Cheap Wholesale Gucci real leather Purse
Cheap Wholesale Hermes real leather Handbags
Cheap Wholesale Hermes real leather Purse <free shipping paypal
payment>
Cheap Wholesale Jimmy Choo real leather Handbags <free shipping paypal
payment>
Cheap Wholesale Jimmy Choo real leather Purse <free shipping paypal
payment>
Cheap Wholesale Juicy real leather Handbags <www.vipchinatrade.com
paypal payment>
Cheap Wholesale Kooba real leather Handbags
Cheap Wholesale Lancel real leather Handbags
Cheap Wholesale Loewe real leather Handbags <www.vipchinatrade.com
paypal payment>
Cheap Wholesale LV real leather Handbags <free shipping paypal
payment>
Cheap Wholesale LV real leather Purse <free shipping paypal payment>
Cheap Wholesale Marc Jacobs real leather Handbags
<www.vipchinatrade.com paypal payment>
Cheap Wholesale Miumiu real leather Handbags
Cheap Wholesale Mulberry real leather Handbags
Cheap Wholesale Prada real leather Handbags <free shipping paypal
payment>
Cheap Wholesale Prada real leather Purse
Cheap Wholesale Thomaswlde real leather Handbags
<www.vipchinatrade.com paypal payment>
Cheap Wholesale Valentnv real leather Handbags
Cheap Wholesale Versace real leather Handbags <www.vipchinatrade.com
paypal payment>
A+ Grade
Purse
Discount Wholesale Anna Purse <free shipping paypal payment>
Discount Wholesale Burbetty Purse
Discount Wholesale Chanel Purse <www.vipchinatrade.com >
Discount Wholesale Chloe Purse
Discount Wholesale Coach Purse <www.vipchinatrade.com >
Discount Wholesale D&G Purse
Discount Wholesale Dior Purse <www.vipchinatrade.com >
Discount Wholesale Dooney&Bourke Purse
Discount Wholesale ED Hardy Purse <www.vipchinatrade.com >
Discount Wholesale Fendi Purse
Discount Wholesale Ferragmo Purse
Discount Wholesale Gucci Purse <www.vipchinatrade.com >
Discount Wholesale Guess Purse
Discount Wholesale LV Purse <free shipping paypal payment>
Discount Wholesale Miumiu Purse
Discount Wholesale Prada Purse <www.vipchinatrade.com >
Discount Wholesale Tous Purse
Discount Wholesale Versace Purse <www.vipchinatrade.com > <free
shipping paypal payment>
Handbags
Discount Wholesale BOSS Handbag
Discount Wholesale Burberry Handbag <www.vipchinatrade.com >
Discount Wholesale CA Handbag
Discount Wholesale Chanel Handbag <free shipping paypal payment>
Discount Wholesale Chloe Handbag <www.vipchinatrade.com >
Discount Wholesale Coach Handbag
Discount Wholesale D&G Handbag <www.vipchinatrade.com >
Discount Wholesale Dooney&Bourke Handbag
Discount Wholesale ED Hardy Handbag <www.vipchinatrade.com >
Discount Wholesale Fendi Handbag
Discount Wholesale Gucci Handbag <www.vipchinatrade.com >
Discount Wholesale Hermes Handbag
Discount Wholesale Jimmy Choo Handbag <free shipping paypal
payment>
Discount Wholesale Juciy Handbag
Discount Wholesale LV Handbag <www.vipchinatrade.com >
Discount Wholesale Miumiu Handbag <www.vipchinatrade.com >
Discount Wholesale Prada Handbag
Discount Wholesale Tous Handbag <www.vipchinatrade.com >
Discount Wholesale Versace Handbags <free shipping paypal payment>
==============================================================================
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