http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* ┈━═☆ Cheap wholesale Lv Jean, True Relig Jean, Laguna Beach Jean, G-star
Jean ect at website: www.fjrjtrade.com <Paypal Payment> - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6fe10cb989d88f0e?hl=en
* Design patterns - 10 messages, 8 authors
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
* ❉♡❉Hot sale cheap bed sheet, umbrella, crimping iron, Bose at www.ecyaya.com
- 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/8d21f35f359d9a60?hl=en
* Interfacing C++ and assembler code - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/79272d2bf39c62ec?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
* String not printing data on next line despite \n in the string - 5 messages,
3 authors
http://groups.google.com/group/comp.lang.c++/t/35658d761ffe5130?hl=en
* C++ call C# .NET api (dll) - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b42e544e36439542?hl=en
* C++ jobs down another 40% - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?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
==============================================================================
TOPIC: ┈━═☆ Cheap wholesale Lv Jean, True Relig Jean, Laguna Beach Jean, G-
star Jean ect at website: www.fjrjtrade.com <Paypal Payment>
http://groups.google.com/group/comp.lang.c++/t/6fe10cb989d88f0e?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 6:57 am
From: "www.fjrjtrade.com"
┈━═☆ Cheap wholesale Lv Jean, True Relig Jean, Laguna Beach Jean, G-
star Jean ect at website: www.fjrjtrade.com <Paypal Payment>
Cheap wholesale Jeans
http://www.fjrjtrade.com/1261-Jean.html
Cheap wholesale A&F Jean
http://www.fjrjtrade.com/2169-AF-Jean.html
Cheap wholesale Artful Dodger Jean
http://www.fjrjtrade.com/1954-Artful-Dodger-Jean.html
Cheap wholesale BBC Jean
http://www.fjrjtrade.com/1955-BBC-Jean.html
Cheap wholesale Cavalli Jean
http://www.fjrjtrade.com/1956-Cavalli-Jean.html
Cheap wholesale Iceberg Jean Man
http://www.fjrjtrade.com/2172-Iceberg-Jean-Man.html
Cheap wholesale Kanji Jean Man
http://www.fjrjtrade.com/2173-Kanji-Jean-Man.html
Cheap wholesale Laguna Beach Jean
http://www.fjrjtrade.com/1951-Laguna-Beach-Jean.html
Cheap wholesale Michael Jackson Jean Man
http://www.fjrjtrade.com/2174-Michael-Jackson-Jean-Man.html
Cheap wholesale Prada Jean
http://www.fjrjtrade.com/1957-Prada-Jean.html
Cheap wholesale RMC Jean
http://www.fjrjtrade.com/1958-RMC-Jean.html
Cheap wholesale Robins Jean Man
http://www.fjrjtrade.com/2175-Robins-Jean-Man.html
Cheap wholesale Roca Wear Jean
http://www.fjrjtrade.com/1959-Roca-Wear-Jean.html
Cheap wholesale ZEN Jean
http://www.fjrjtrade.com/1950-ZEN-Jean.html
Cheap wholesale Affliction Jean
http://www.fjrjtrade.com/1262-Affliction-Jean.html
Cheap wholesale Akademiks Jean
http://www.fjrjtrade.com/1263-Akademiks-Jean.html
Cheap wholesale Armani Jean
http://www.fjrjtrade.com/1264-Armani-Jean.html
Cheap wholesale Bape Jean
http://www.fjrjtrade.com/1265-Bape-Jean.html
Cheap wholesale Christian Audigier Jean
http://www.fjrjtrade.com/1267-Christian-Audigier-Jean.html
Cheap wholesale Coogi Jean
http://www.fjrjtrade.com/1268-Coogi-Jean.html
Cheap wholesale Crown Holder Jean
http://www.fjrjtrade.com/1269-Crown-Holder-Jean.html
Cheap wholesale D&G Jean
http://www.fjrjtrade.com/1270-DG-Jean.html
Cheap wholesale Diesel Jean
http://www.fjrjtrade.com/1271-Diesel-Jean.html
Cheap wholesale Ecko Unltd Jean
http://www.fjrjtrade.com/1272-Ecko-Unltd-Jean.html
Cheap wholesale Ed Hardy Jean
http://www.fjrjtrade.com/1273-Ed-Hardy-Jean.html
Cheap wholesale Evisu Jean
http://www.fjrjtrade.com/1274-Evisu-Jean.html
Cheap wholesale G-Star Jean
http://www.fjrjtrade.com/1275-G-Star-Jean.html
Cheap wholesale Gucci Jean
http://www.fjrjtrade.com/1276-Gucci-Jean.html
Cheap wholesale LEVI'S Jean
http://www.fjrjtrade.com/1281-LEVIS-Jean.html
Cheap wholesale LRG Jean
http://www.fjrjtrade.com/1282-LRG-Jean.html
Cheap wholesale LV Jean
http://www.fjrjtrade.com/1283-LV-Jean.html
Cheap wholesale Rock Jean
http://www.fjrjtrade.com/1284-Rock-Jean.html
Cheap wholesale True Relig Jean
http://www.fjrjtrade.com/1285-True-Relig-Jean.html
Cheap wholesale Versace Jean
http://www.fjrjtrade.com/1286-Versace-Jean.html
More items at website:
http://www.fjrjtrade.com
==============================================================================
TOPIC: Design patterns
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
==============================================================================
== 1 of 10 ==
Date: Sat, Dec 26 2009 7:07 am
From: tanix@mongo.net (tanix)
I just read one article here about patterns
and it made me shiver.
Are you guys trying to find a solution to your issue
by first looking if you can find as many "design patterns" as you
can find and then try to stick as many of them into your code,
as you can manage?
Is THAT the central idea about modern programming techniques?
--
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.
== 2 of 10 ==
Date: Sat, Dec 26 2009 7:17 am
From: "AnonMail2005@gmail.com"
On Dec 26, 10:07 am, ta...@mongo.net (tanix) wrote:
> I just read one article here about patterns
> and it made me shiver.
>
> Are you guys trying to find a solution to your issue
> by first looking if you can find as many "design patterns" as you
> can find and then try to stick as many of them into your code,
> as you can manage?
>
> Is THAT the central idea about modern programming techniques?
>
> --
> Programmer's Goldmine collections:
>
> http://preciseinfo.org
>
> Tens of thousands of code examples and expert discussions on
> C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
> organized by major topics of language, tools, methods, techniques.
You sound like a troll.
Certain design patterns are useful tools for solving certain
programming problems. I use them as I see fit.
== 3 of 10 ==
Date: Sat, Dec 26 2009 7:20 am
From: tanix@mongo.net (tanix)
In article <cbb29484-fbea-4c84-be94-e52348b0c766@r5g2000yqb.googlegroups.com>, "AnonMail2005@gmail.com" <anonmail2005@gmail.com> wrote:
>On Dec 26, 10:07=A0am, ta...@mongo.net (tanix) wrote:
>> I just read one article here about patterns
>> and it made me shiver.
>>
>> Are you guys trying to find a solution to your issue
>> by first looking if you can find as many "design patterns" as you
>> can find and then try to stick as many of them into your code,
>> as you can manage?
>>
>> Is THAT the central idea about modern programming techniques?
>>
>> --
>> Programmer's Goldmine collections:
>>
>> http://preciseinfo.org
>>
>> Tens of thousands of code examples and expert discussions on
>> C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
>> organized by major topics of language, tools, methods, techniques.
>
>You sound like a troll.
And THAT is how you START?
>Certain design patterns are useful tools for solving certain
>programming problems.
:--}
> I use them as I see fit.
:--}
--
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 10 ==
Date: Sat, Dec 26 2009 9:34 am
From: MiB
Selecting design pattern(s) for an application is a delicate process.
On a more macroscopic level, it requires in-depth analysis similar to
selecting an algorithm for solving a problem.
In order to make an educated choice, in both cases you need to know a
number of alternatives, i.e. strong points and drawbacks of design
patterns for the task at hand as well as you need this for algorithms.
I did not check the web site you gave, but I assume its a kind of
collection or catalog of design patterns - of course it is not a good
idea to stick in design patterns into writing an application
indiscriminately but a catalog is a good knowledge base for not having
to invent the wheel over and over again.
best,
MiB
== 5 of 10 ==
Date: Sat, Dec 26 2009 10:26 am
From: James Kanze
On Dec 26, 3:07 pm, ta...@mongo.net (tanix) wrote:
> I just read one article here about patterns and it made me
> shiver.
> Are you guys trying to find a solution to your issue by first
> looking if you can find as many "design patterns" as you can
> find and then try to stick as many of them into your code, as
> you can manage?
Maybe some are, but I've not encountered any. I have
encountered a lot of programmers who prefer reinventing known
solutions rather than using existing ones. In the end, using
design patterns is just using a common language for talking
about existing solutions, so you don't have to reinvent known
solutions each time around. (The common vocabulary is extremely
useful for documentation purposes.)
> Is THAT the central idea about modern programming techniques?
The central idea about modern programming techniques is to
produce error free, maintainable software as cheaply as
possible. Using known solutions, when applicable, is an
effective technique for that.
--
James Kanze
== 6 of 10 ==
Date: Sat, Dec 26 2009 11:14 am
From: Jonathan Lee
On Dec 26, 10:07 am, ta...@mongo.net (tanix) wrote:
> Are you guys trying to find a solution to your issue
> by first looking if you can find as many "design patterns" as you
> can find and then try to stick as many of them into your code,
> as you can manage?
>
> Is THAT the central idea about modern programming techniques?
Absolutely. In fact, for my undergrad thesis I'm working on a
"problem description language" that will take your problem/goal
and re-express it in design patterns. It will then write the
program by mechanically applying the design patterns.
But I'm having a small problem finishing it. Anyone know of a
pattern for the above problem?
--Jonathan
== 7 of 10 ==
Date: Sat, Dec 26 2009 11:38 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
Jonathan Lee <chorus@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
== 8 of 10 ==
Date: Sat, Dec 26 2009 12:01 pm
From: Branimir Maksimovic
Stefan Ram wrote:
> Jonathan Lee <chorus@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...
Greets
== 9 of 10 ==
Date: Sat, Dec 26 2009 4:23 pm
From: Joshua Maurice
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.
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
does a remarkably good job describing evolution by natural selection,
specifically how evolution by natural selection may be the only known
natural process which creates information in a local open system, the
only process which creates information which is not intelligent
design. "The non-random survival of randomly varying replicators."
Throw on a couple good books of information theory and entropy for
good measure.
On the flip side, who ever proved that humans are "creative"? Or any
moreso than a really good computer AI (which has not yet been made)?
== 10 of 10 ==
Date: Sat, Dec 26 2009 4:35 pm
From: Branimir Maksimovic
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....
>
> 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?
Greets
==============================================================================
TOPIC: ❉♡❉Hot sale cheap bed sheet, umbrella, crimping iron, Bose at www.
ecyaya.com
http://groups.google.com/group/comp.lang.c++/t/8d21f35f359d9a60?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Dec 26 2009 7:41 am
From: hero
❉♡❉Hot sale cheap bed sheet, umbrella, crimping iron, Bose at www.ecyaya.com
Hot sale cheap LV 4 sets bed in a bag at www.ecyaya.com
Hot sale cheap Gucci 4 sets bed in a bag at www.ecyaya.com
Hot sale cheap Fendi 4 sets in a bag at www.ecyaya.com
Hot sale cheap Dior 4 sets in a bag at www.ecyaya.com
Hot sale cheap Coach 4 sets bed in a bag at www.ecyaya.com
Hot sale cheap CK 4 set bed in a bag at www.ecyaya.com
Hot sale cheap Chanel 4 sets in a bag at www.ecyaya.com
Hot sale cheap Burberry 4 sets in a bag at www.ecyaya.com
Hot sale cheap LV6 sets bed in a bag at www.ecyaya.com
Hot sale cheap Gucci 6 sets bed in a bag at www.ecyaya.com
Hot sale cheap Fendi 6 sets in a bag at www.ecyaya.com
Hot sale cheap Dior 6 sets in a bag at www.ecyaya.com
Hot sale cheap Coach 6 sets bed in a bag at www.ecyaya.com
Hot sale cheap CK 6 set bed in a bag at www.ecyaya.com
Hot sale cheap Chanel 6 sets in a bag at www.ecyaya.com
Hot sale cheap Burberry 6 sets in a bag at www.ecyaya.com
Hot sale cheap Umbella at www.ecyaya.com
Hoe sale cheap Bose at www.ecyaya.com
Hot sale cheap crimping iron at www.ecyaya.com
Welcome to my website www.ecyaya.com for more details, the bedsheet
have different styles, different colors for your reference.
== 2 of 2 ==
Date: Sat, Dec 26 2009 7:41 am
From: hero
❉♡❉Hot sale cheap bed sheet, umbrella, crimping iron, Bose at www.ecyaya.com
Hot sale cheap LV 4 sets bed in a bag at www.ecyaya.com
Hot sale cheap Gucci 4 sets bed in a bag at www.ecyaya.com
Hot sale cheap Fendi 4 sets in a bag at www.ecyaya.com
Hot sale cheap Dior 4 sets in a bag at www.ecyaya.com
Hot sale cheap Coach 4 sets bed in a bag at www.ecyaya.com
Hot sale cheap CK 4 set bed in a bag at www.ecyaya.com
Hot sale cheap Chanel 4 sets in a bag at www.ecyaya.com
Hot sale cheap Burberry 4 sets in a bag at www.ecyaya.com
Hot sale cheap LV6 sets bed in a bag at www.ecyaya.com
Hot sale cheap Gucci 6 sets bed in a bag at www.ecyaya.com
Hot sale cheap Fendi 6 sets in a bag at www.ecyaya.com
Hot sale cheap Dior 6 sets in a bag at www.ecyaya.com
Hot sale cheap Coach 6 sets bed in a bag at www.ecyaya.com
Hot sale cheap CK 6 set bed in a bag at www.ecyaya.com
Hot sale cheap Chanel 6 sets in a bag at www.ecyaya.com
Hot sale cheap Burberry 6 sets in a bag at www.ecyaya.com
Hot sale cheap Umbella at www.ecyaya.com
Hoe sale cheap Bose at www.ecyaya.com
Hot sale cheap crimping iron at www.ecyaya.com
Welcome to my website www.ecyaya.com for more details, the bedsheet
have different styles, different colors for your reference.
==============================================================================
TOPIC: Interfacing C++ and assembler code
http://groups.google.com/group/comp.lang.c++/t/79272d2bf39c62ec?hl=en
==============================================================================
== 1 of 3 ==
Date: Sat, Dec 26 2009 8:37 am
From: Rune Allnor
Hi all.
When one mixes C++ and assmbler code one needs to
know a few details about the way the CPU works. In particular,
one would need to know
1) what registers and variables must be left alone
2) which variables and registers might be manipulated
inside the routine if the contents are restored before
the routine terminates
3) what registers and variables one is free to play with at will.
Where can one find information about such details?
I am particularly interested in stuff relating to VS2008.
Rune
== 2 of 3 ==
Date: Sat, Dec 26 2009 9:36 am
From: Jonathan Lee
On Dec 26, 11:37 am, Rune Allnor <all...@tele.ntnu.no> wrote:
> Hi all.
>
> When one mixes C++ and assmbler code one needs to
> know a few details about the way the CPU works. In particular,
> one would need to know
>
> 1) what registers and variables must be left alone
> 2) which variables and registers might be manipulated
> inside the routine if the contents are restored before
> the routine terminates
> 3) what registers and variables one is free to play with at will.
>
> Where can one find information about such details?
> I am particularly interested in stuff relating to VS2008.
>
> Rune
I don't use visual studio, but a Google search brought this
up:
http://msdn.microsoft.com/en-us/library/4ks26t93%28VS.80%29.aspx
--Jonathan
== 3 of 3 ==
Date: Sat, Dec 26 2009 9:44 am
From: Branimir Maksimovic
Rune Allnor wrote:
> Hi all.
>
> When one mixes C++ and assmbler code one needs to
> know a few details about the way the CPU works. In particular,
> one would need to know
>
> 1) what registers and variables must be left alone
> 2) which variables and registers might be manipulated
> inside the routine if the contents are restored before
> the routine terminates
> 3) what registers and variables one is free to play with at will.
>
> Where can one find information about such details?
> I am particularly interested in stuff relating to VS2008.
>
> Rune
This is implementation of my Window class, I think, everything is clear
here, how you can do it in win32, unfortunately microsoft has banned
assembler from 64 bit environment there you can only
write separate assembler modules:
#include "Window.h"
class Window::Thunk{
friend class Window;
public:
Thunk(Window*);
void SetDestroyed(){ destroyed_ = true; }
void AddRef()
{
++ref_;
}
void ReleaseRef(bool dest = false)
{
--ref_;
if(ref_ <= 0)
if(dest)delete this;
else destroyed_=true;
}
~Thunk(){ delete[] code_; instances_--;}
private:
static void Destroy();
Thunk(const Thunk&);
Thunk& operator=(const Thunk&);
BYTE* code_;
bool destroyed_;
int ref_;
class Test{
public:
~Test(){ if (Thunk::instances_)MessageBox(NULL,"THUNK
INSTANCES","",MB_OK);}
};
static Test test;
static int instances_;
};
Window::Thunk::Test Window::Thunk::test;
Window::Test Window::test;
int Window::instances_ = 0;
int Window::Thunk::instances_ = 0;
Window::Window(bool isDlg)
:hwnd_(0),orig_proc_(0),wnd_class_(0),thunk_(0),ref_(1)
{
thunk_ = new Thunk(this);
wnd_proc_ = (WNDPROC)thunk_->code_;
instances_++;
}
Window::~Window()
{
instances_--;
if(IsWindow())
{
if(orig_proc_)
SetWindowLongPtr(GWLP_WNDPROC,(LONG_PTR)orig_proc_);
else
SetWindowLongPtr(GWLP_WNDPROC,(LONG_PTR)DefWindowProc);
DestroyWindow();
}
if(wnd_class_)::UnregisterClass((LPCTSTR)wnd_class_,(HINSTANCE)GetWindowLongPtr(GWLP_HINSTANCE));
if(thunk_)thunk_->ReleaseRef(true);
}
void Window::Create(DWORD dwExStyle,
LPCTSTR lpClassName,
LPCTSTR lpWindowName,
DWORD dwStyle,
int x,
int y,
int nWidth,
int nHeight,
HWND hWndParent,
HMENU hMenu,
HINSTANCE hInstance,
LPVOID lpParam
)
{
if(hwnd_)
{
MessageBox(NULL,"Window already created","",MB_ICONEXCLAMATION | MB_OK);
return;
}
if(!lpClassName && !wnd_class_)
{
WNDCLASSEX wincl = RegisterClass(wnd_proc_);
if (wnd_class_ = ::RegisterClassEx (&wincl),!wnd_class_)
{
DWORD error = GetLastError();
char buf[4096];
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, error, 0, buf, sizeof
buf,NULL);
throw std::runtime_error(buf);
}
}
hwnd_ = ::CreateWindowEx(dwExStyle,
lpClassName?lpClassName:(LPCTSTR)wnd_class_,
lpWindowName,
dwStyle,
x,
y,
nWidth,
nHeight,
hWndParent,
hMenu,
hInstance,
lpParam);
if (!hwnd_)
{
DWORD error = GetLastError();
char buf[4096];
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, error, 0, buf, sizeof
buf,NULL);
throw std::runtime_error(buf);
}
WNDPROC proc =
(WNDPROC)SetWindowLongPtr(GWLP_WNDPROC,(LONG_PTR)wnd_proc_);
if (proc != wnd_proc_)orig_proc_ = proc;
}
LRESULT CALLBACK Window::WindowProc(Window* pThis,HWND hwnd,UINT
message,WPARAM wParam,LPARAM lParam)
{
LRESULT rc;Thunk* pThunk=pThis->thunk_;
if(pThis->hwnd_ != hwnd)pThis->hwnd_ = hwnd;
try
{
AutoRef<Thunk> apThunk(pThunk);
apThunk->AddRef();
rc = pThis->ProcessMessages(hwnd,message,wParam,lParam);
}catch(...)
{
if(pThunk->destroyed_)delete pThunk;
throw;
}
return rc;
}
__declspec(naked) LRESULT CALLBACK Window::CodeProc(HWND hwnd,UINT
message,WPARAM wParam,LPARAM lParam)
{
Window* pThis;Thunk* pThunk;
LRESULT rc;
__asm
{
mov eax, end;
sub eax, begin; // eax == size
mov ebx, tag;
sub ebx, begin; // ebx == tag offset
mov ecx, begin;
ret;
}
begin:
__asm
{
push ebp;
mov ebp,esp;
sub esp,__LOCAL_SIZE;
}
__asm mov dword ptr [pThis],0x0;
tag:
pThunk = pThis->thunk_;
__asm // rc = WindowProc(pThis,hwnd,message,wParam,lParam);
{
push dword ptr[lParam];
push dword ptr[wParam];
push dword ptr[message];
push dword ptr[hwnd];
push dword ptr[pThis];
mov edx, dword ptr[Window::WindowProc];
call edx;
mov dword ptr[rc], eax;
}
if(pThunk->destroyed_)
{
__asm
{
mov eax, dword ptr[rc];
mov ecx, dword ptr[pThunk];
mov esp,ebp;
pop ebp;
mov edx, dword ptr[Window::Thunk::Destroy];
jmp edx; // we don't wont Destroy to return since this function will
be deleted
}
}
__asm
{
mov eax,dword ptr [rc];
mov esp,ebp;
pop ebp;
ret 0x10; // __stdcall stack cleanup
}
end:;
}
Window::Thunk::Thunk(Window* pThis):destroyed_(false),ref_(1)
{
instances_++;
size_t lsize,lmod,lbegin;
__asm
{
call Window::CodeProc;
mov dword ptr[lsize], eax;
mov dword ptr[lmod], ebx;
mov dword ptr[lbegin], ecx;
}
code_ = new BYTE[lsize];
void *pDst = code_;
__asm //memcpy(pDst,code,lsize);
{
mov esi, dword ptr[lbegin];
mov edi, dword ptr[pDst];
mov ecx, dword ptr[lsize];
cld;
rep movsb;
}
__asm // modify mov var,0 to mov var,address
{
mov eax, dword ptr[pThis];
mov ebx, dword ptr[pDst];
add ebx, dword ptr[lmod];
mov dword ptr[ebx-4], eax;
}
DWORD oldprotect;
if(!VirtualProtect(code_, lsize, PAGE_EXECUTE_READWRITE, &oldprotect))
{
DWORD error = GetLastError();
char buf[4096];
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, error, 0, buf, sizeof
buf,NULL);
delete code_;
throw std::runtime_error(buf);
}
FlushInstructionCache(GetCurrentProcess(), code_, lsize);
}
__declspec(naked) void Window::Thunk::Destroy()
{
Thunk* pThunk;
__asm
{
push ebp;
mov ebp,esp;
sub esp,__LOCAL_SIZE;
push eax; // save rc
mov dword ptr[pThunk],ecx
}
delete pThunk;
__asm
{
pop eax; // restore rc
mov esp,ebp;
pop ebp;
ret 0x10; //// __stdcall stack cleanup from code proc
}
}
Greets, hope this helps...
==============================================================================
TOPIC: Exception Misconceptions: Exceptions are for unrecoverable errors.
http://groups.google.com/group/comp.lang.c++/t/786cfdf0ab25866d?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 10:21 am
From: James Kanze
On Dec 26, 1:52 pm, "Balog Pal" <p...@lib.hu> wrote:
> "James Kanze" <james.ka...@gmail.com>
> > A mutex probably should be considered a resource, but a
> > transaction?
> Sure. Actually I tend to replace the R in mozaiks from
> "resource" to "responsibility". So everything looks uniform,
> resource alloc comes wih responsibility to dealloc, mutex lock
> requires unlock, transaction opening requires rollback or
> commit...
> So you use the same tech -- the destructor sits there to carry
> out the responsibility that is left over.
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.
> > 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:-).) 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. Independantly of the language:
destructors do help in the implementation details, but the
initial analysis is still necessary.
> > (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. (Even a finally
block in Java isn't that much effort. Once you know what needs
to go in it.)
--
James Kanze
==============================================================================
TOPIC: String not printing data on next line despite \n in the string
http://groups.google.com/group/comp.lang.c++/t/35658d761ffe5130?hl=en
==============================================================================
== 1 of 5 ==
Date: Sat, Dec 26 2009 12:03 pm
From: "BGB / cr88192"
"Paavo Helde" <myfirstname@osa.pri.ee> wrote in message
news:Xns9CED7AFF5D5DApaavo256@216.196.109.131...
> "BGB / cr88192" <cr88192@hotmail.com> wrote in
> news:hh3l5j$4o5$1@news.albasani.net:
>
>>
>> "Paavo Helde" <myfirstname@osa.pri.ee> wrote in message
>> news:Xns9CEBD26804A1Epaavo256@216.196.109.131...
>>> SRK <kumarsr@gmail.com> wrote in news:f45f3f70-d140-4b48-af0a-
>>> 10f52eee8394@15g2000prz.googlegroups.com:
>>>
>>>> Hi folks,
>>>> I am trying to read some data from a config file and want that data
>>>> to be printed in formatted way foe example if I have this string in
>>>> the config file - ABC PQR XYZ and want to display it like
>>>>
>>>> ABC
>>>> PQR
>>>> XYZ
>>>>
>>>> for that I have put the above mentioned string as ABC \nPQR \nXYZ
>>>>
>>>> But instead of displaying the next string on next line, when I print
>>>> the data, it prints as ABC \nPQR \nXYZ.
>>>
>>> You need to convert two symbols (backslash and n) to a single symbol
>>> (line-feed '\n').
>>>
>>> If this is not very performance-critical, you can do it in-place:
>>>
>>> std::string s = "ABC\\nPQR\\nXYZ\\n"; // contains backslash and n
>>>
>>> std::string::size_type k = 0;
>>> while((k=s.find("\\n", k))!=s.npos) {
>>> s.replace(k, 2, "\n");
>>> }
>>>
>>> // s now contains linefeed characters instead.
>>>
>>
>> or, maybe the good old char-pointers strategy:
>> char tb[256]; //or whatever is the maximum sane length
>
> This is a buffer overrun error waiting to happen (or being exploited). At
> least one should check the length, or allocate a buffer long enough. In
> this case this should be easy.
>
but, it is worth noting that new/malloc and delete/free are not free
either...
so, the possibility of a buffer overflow may sometimes be justifiable in the
name of performance...
there is also a reason for a value like 256 rather than, say, 82.
we could declare, "well, no valid text file has > 80 characters per line",
and use 82 (allowing for a newline and a nul), but 256 adds a little more
padding.
granted, a 256 char line will overflow this buffer...
granted:
char *buf;
buf=(char *)malloc(strlen(input)+1);
is easy enough...
in practice, I usually use an alternative strategy I call a "rotating
allocator", where usually the potential cost of a buffer overflow is fairly
low, and a rotating allocator is not readily exploitable (there is little to
say where the string will be in memory), ...
>
>> char *s, *t;
>>
>> s=input; t=tb;
>> while(*s)
>> {
>> if((*s=='\\') && (*(s+1)=='n'))
>> { *t++='\n'; s+=2; continue; }
>> *t++=*s++;
>> }
>> *t++=0;
>>
>>
>> granted, one can debate whether or not this is good style in C++, ...
>> but, should work ok.
>
> This is a C solution, and assumes C strings (zero-terminated, no embedded
> zeroes). Probably this is a harmless assumption, but nevertheless it is
> slightly different, and makes the coding a bit more convenient (no extra
> care needed when checking *(s+1)).
>
this is partly why I said "good old char pointers"...
> The same algorithm can be made to work with std::string as well of
> course, by extracting the C-style string pointer via the c_str() member
> function:
>
>
> std::string input = ...
> std::string output(input.length(), '\0');
>
> if (!input.empty()) {
> const char* s = input.c_str();
> char* t = &output[0];
>
> // C-style algorithm here...
>
> output.resize(t-&output[0]);
> }
>
granted, but I guess the question then is whether or not someone is using
std::string...
admitted, yes, I am more of a C coder than a C++ one (I use C++ sometimes,
but a majority of my code is C), and I tend to prefer strategies which work
fairly well in both cases...
(not wanting to make debate here, but there are reasons to choose one or
another in different contexts, many not particularly relevant to the
language as seen/written by humans, and many not related to the "majority"
of projects).
> Paavo
>
== 2 of 5 ==
Date: Sat, Dec 26 2009 1:01 pm
From: Branimir Maksimovic
SRK wrote:
> On Dec 24, 3:08 pm, SRK <kuma...@gmail.com> wrote:
>> Hi folks,
>> I am trying to read some data from a config file and want that data to
>> be printed in formatted way foe example if I have this string in the
>> config file - ABC PQR XYZ and want to display it like
>>
>> ABC
>> PQR
>> XYZ
>>
>> for that I have put the above mentioned string as ABC \nPQR \nXYZ
>>
>> But instead of displaying the next string on next line, when I print
>> the data, it prints as ABC \nPQR \nXYZ.
>>
>> Any help would be highly appriciated.
>>
>> Thanks
>> SRK
>
> Let me mention that I am using FILE pointer for reading from the file
> and using fgets for reading the entire line. I dont have to print the
> string one by one, but I want to make it something like a menu and
> send it on a socket.
>
> thanks
> SRK
Hm,
ifstream ifs("file.conf");
string tmp;
while(getline(ifs,tmp))
{
istringstream iss(tmp);
while(iss>>tmp)cout<<tmp<<'\n';
}
this code does not compile,,,, it is just example of one of ways you can
do that....
Greets
== 3 of 5 ==
Date: Sat, Dec 26 2009 1:29 pm
From: Paavo Helde
"BGB / cr88192" <cr88192@hotmail.com> wrote in
news:hh5q6c$a8$1@news.albasani.net:
> so, the possibility of a buffer overflow may sometimes be justifiable
> in the name of performance...
I hope you are joking!
Now, seriously, the unexpected things like the size of input data come from
the outside of the program, by definition. Input/output is typically slow
enough that a check for the input data size would cost next to nothing. I
see *no* justification of skipping that! Note that I do not advocate
dynamic allocation, but just a simple check and error return.
> (not wanting to make debate here, but there are reasons to choose one
> or another in different contexts, many not particularly relevant to
> the language as seen/written by humans, and many not related to the
> "majority" of projects).
I cannot see any reason to knowingly leave a potential UB bug in the
program. God knows there are many of them already left unknowingly, no
reason to add one!
Paavo
== 4 of 5 ==
Date: Sat, Dec 26 2009 1:35 pm
From: Branimir Maksimovic
Paavo Helde wrote:
>> (not wanting to make debate here, but there are reasons to choose one
>> or another in different contexts, many not particularly relevant to
>> the language as seen/written by humans, and many not related to the
>> "majority" of projects).
>
> I cannot see any reason to knowingly leave a potential UB bug in the
> program. God knows there are many of them already left unknowingly, no
> reason to add one!
Hm, microsoft had practice to allow write in deallocated memory
in order for some important applications to work on windows.
I don;t see how this is problem. Besides that it is excellent
idea to provide COM interface to download binary code in such
environment from the internet..
Greets
== 5 of 5 ==
Date: Sat, Dec 26 2009 1:55 pm
From: Branimir Maksimovic
Branimir Maksimovic wrote:
> Paavo Helde wrote:
>>> (not wanting to make debate here, but there are reasons to choose one
>>> or another in different contexts, many not particularly relevant to
>>> the language as seen/written by humans, and many not related to the
>>> "majority" of projects).
>>
>> I cannot see any reason to knowingly leave a potential UB bug in the
>> program. God knows there are many of them already left unknowingly, no
>> reason to add one!
>
> Hm, microsoft had practice to allow write in deallocated memory
> in order for some important applications to work on windows.
> I don;t see how this is problem. Besides that it is excellent
> idea to provide COM interface to download binary code in such
> environment from the internet..
>
Also on 32 bit windows you can;t touch last bit in any pointer
because some directx driver use it to determine if it's handle
or pointer. So in 32 bit windows touching anything above 2gb is no no...
Greets
==============================================================================
TOPIC: C++ call C# .NET api (dll)
http://groups.google.com/group/comp.lang.c++/t/b42e544e36439542?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 12:32 pm
From: Aziz Azizi
On Dec 24, 2:51 am, Slickuser <slick.us...@gmail.com> wrote:
> Hi,
>
> I have two projects, one wrote in C++ and one in C# .NET 3.5 Framework
> sp1.
>
> I would like the C++ project to call C# project dll. How can I expose
> api/function from C# to allow C++ to call. Mostly I will not have the
> source code to C# project, just api I can call.
>
> Example of C# file below so I can get something going. Any help?
>
> Test.cs
> using System;
> using System.Collections.Generic;
> using System.Text;
>
> namespace ProjectX
> {
> public class Test
> {
>
> public static void Main()
> {
> Console.WriteLine("Main!");
> }
>
> public void TestCount()
> {
> Console.WriteLine("Count!");
> }
>
> }
>
>
>
> }
Hi;
if you want to call API by programming in C++ I can send you some
project.
==============================================================================
TOPIC: C++ jobs down another 40%
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Dec 26 2009 3:41 pm
From: "BGB / cr88192"
"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, ...).
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 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.
> 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.
> 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...
> 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".
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...
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. it
would be better if one could compile it in both cases, rather than creating
yet another barrier:
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 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.
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.
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).
JavaScript is not likely to scale well.
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". 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).
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.
> So, I had to implement it using the "copy/paste antipattern" and
> I have about 3 copies of exactly the same logic, dealing with
> 3 types or argument.
>
> Do I regret it? - Nope. Not to the least.
> Did I EVER have ANy problems with it? - Not that I know of.
> I don't even notice this code. Works like a champ.
> And each of those methods take about 10 lines of code.
> Why would I bother to write some ugly code using generics?
> I would not even THINK about such a think. UTTERLY usesless.
>
> How many places in your code do you have that do very similar
> things? Well, I bet ALL over the place. Would you need to
> replace it with generics? Well, try.
>
> One professor from France, a while back said:
> Writing programs automatically is just a myth that will never
> happen. Because each program is unique and has millions of
> nasty little things that distinguish them from something
> similar.
>
> Otherwise, we would not have a software industry by now.
> It would be all generated by the software robots.
>
> And with all the "developments", interfaces, OO approach,
> it is still a myth, just the same.
>
> I do not think THIS is the priority of development and THIS
> is what is going to imporve the sofware design.
>
> And I do not think that introductions of more and more
> complexities into syntax and notation is going to solve
> ANYTHING. It is just going to create more and more headaches
> as it becomes more and more unintuitive.
>
> Language designers seem to be totally oblivious of the fact
> that their language is not exactly what is going on in the
> programmers or designer's mind. They need some specific
> JOB to be done. Some specific CONCEPT to be implemented,
> some specific ARCHITECTURE that will do such and such.
>
> They could care LESS if your obscession with languages means
> something to you as language designer. I do not recall many
> cases, if any, where I thought: oh crap, I can not do this
> and that because my language SYNTAX is screwed up, or my
> espressive power is not enough.
>
> But I do recall TONS of cases where I had to waste almost
> half an hour of my time looking at some utterly ugly code,
> written by some idiot with complex of inferiority, that
> probably wasted DAYS of his time to write some generics
> goubledy gook code that was not even needed to begin with.
>
> I could do exact same thing with funken C code, not even C++.
> And the hell would sooner get frozen before they can prove
> ANY advantage of that "purist" code and all those compile
> time "benefits" they get out of it.
>
> But no. These suckers need to show the whole world how "smart"
> they are. You see, they can OUTSMART you!
> :--}
>
> What a bunch of sickos, utterly brainless idiots, driven by
> the complex of inferiority, forever trying to prove everybody
> how "smart" they are. Why do you need to even bother with such
> foolish things? I simply can not find a bettter term for it.
>
...
>>I at first put some effort into trying to get it to build from sources on
>>Windows, but was having far too many difficulties, and personally found
>>the
>>code a bit nasty, so quickly enough gave up.
>
> Hey. Thanx for your feedback. That is exactly the kind of thing
> I need to hear. The last thing in the world I am interested in
> wasting weeks, if not months of my time just to eventually realized
> I was screwed again by some fools, selling my pussy in the sky with
> diamonds.
>
>>I later started looking into writing my own .NET implementation, but this
>>petered out, as my frameworks' architecture started taking shape on its
>>own,
>>but is not a whole lot like the .NET VM.
>
>>actually, my project is a lot more of a chimera (some parts influenced by
>>the JVM, others by .NET, others by GCC, others by LLVM, ...).
>
> Well, would be interesting to see what kind of thing you came up with.
> You can write an article on it. Don't worry about that "off topic" crap.
> We'll fight if we have to.
>
well, for the most part, it is not particularly "compelling".
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.
> 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, and set
up "the one true VM to rule them all".
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).
> You see, what I am beginning to sense more and more that the solution
> to language and portability issues is that very VM as a concept.
>
> And I think Java is a perfect example of it.
> Because it demonstrated in practical terms that the whole language
> becomes much more powerful (in my opinion) and MUCH more portable
> and all sorts of portability related issues could be resolved,
> and GUI, threads and garbage collections could be wired right into it.
>
> So, once you have a VM that handles all those nasty details,
> you are shielded from ALL sorts of problems and issues.
> Yes, that VM probably have to have some web related functionality
> wired right into it. Plenty people complain about very primitive,
> low level support of web apps in Java, and I trust what they say
> and I can see some of it, and I think the language and VM
> designers need to pay MUCH closer attention to what they ask for
> instead of inventing some ugly even even more complicated stuff
> with language syntax and semantics, that turns out to be some
> of the most useless thing at the end just because no one really
> needs it in forseable future. It all just adds to conceptual fat
> at the end.
>
yep.
well, there are merits to VMs, and there are costs...
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.
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.
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++.
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.
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).
>>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...
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...).
currently C and Java are the main "script" languages in use, 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).
I may instead switch to an alternative strategy, and maybe get around to
writing a Java compiler which produces JBC / "class" files, and then make
use of my JBC interpreter, or a translator, for plugging this into the rest
of the VM.
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, ...).
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).
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
> that 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. 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.
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.
>>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.
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.
>>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.
>>....
>>
>>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.
granted, you wont get the whole ".NET framework" this way, but one can get
C# and MSIL, which have a few merits.
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.
>>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.
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.
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).
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.
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).
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).
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...).
> 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 (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 doe not map from MFC to Java that well.
> Baeically, you have to rewrite the whole thing.
> But I bet it is going to be the easiest thing in the world,
> going from C++/MFC to Java. It would probably be 3 times as hard
> to go the other way around. MFC sucks pretty bad as far as sophisticated
> GUI goes where you do not use the modal dialogs and where you dialogs
> are not some dumb, single threaded, fixed size miniscule boxes,
> just like about anything microsoft does, but are fully resizable,
> multi-threaded, property sheet/page dialogs.
>
> That thing would be a disaster to implement in MFC.
>
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.
>>however, an interpreter would allow, potentially, compiling C++ code to
>>x86,
>>loading the x86 in an interpreter and running it (at likely crap speeds),
>
> No. Interpreters are totally out of the window for this job.
> It is high traffic, high performance situation, where you have
> to do all sorts of tricks to make sure you are not blown out
> in some situations.
>
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.
>>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.
> --
> Programmer's Goldmine collections:
>
> http://preciseinfo.org
>
> 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: Sat, Dec 26 2009 5:21 pm
From: Pavel
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
==============================================================================
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