http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Gigantic Class - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/b3756783d92fd56a?hl=en
* Saving a binary file into a string - 8 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/ddc89ddf30293133?hl=en
* "Reusable" operator overloading for enum? - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/981ab2c7a0c2c5ff?hl=en
* Design patterns - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
* C++ jobs down another 40% - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
* Interfacing C++ and assembler code - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/79272d2bf39c62ec?hl=en
==============================================================================
TOPIC: Gigantic Class
http://groups.google.com/group/comp.lang.c++/t/b3756783d92fd56a?hl=en
==============================================================================
== 1 of 5 ==
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?
== 2 of 5 ==
Date: Sun, Dec 27 2009 10:43 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
Immortal Nephi <Immortal_Nephi@hotmail.com> writes:
>How do you have the solution?
To give a solution, I would need to have a problem.
A problem is a description of the required (functional and
possibly non-functional) properties of a program, that is,
of its behavior. Then, I might find an implementation.
Refactoring can only work this way, because it changes the
source code, while leaving the behavior as specified.
If there is no behavior specification, one can not do refactoring.
(Of course, I cannot promise to solve every problem posted to
Usenet, I just might try and do it for some small problems
if I have some leisure.)
The meaning of »god class« can be looked up using a search
engine.
== 3 of 5 ==
Date: Sun, Dec 27 2009 12:13 pm
From: Immortal Nephi
On Dec 27, 12:43 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Immortal Nephi <Immortal_Ne...@hotmail.com> writes:
> >How do you have the solution?
>
> To give a solution, I would need to have a problem.
>
> A problem is a description of the required (functional and
> possibly non-functional) properties of a program, that is,
> of its behavior. Then, I might find an implementation.
>
> Refactoring can only work this way, because it changes the
> source code, while leaving the behavior as specified.
> If there is no behavior specification, one can not do refactoring.
You refer "Refactoring". Do you mean divide one big problem is
divided into several small problems? I showed quote from ANSI/ISO
book above. Gigantic class is like a big function body. You create
one thing. One thing is one problem. You can't solve it at once.
You need to write small sub-functions and focus small problems. All
sub-functions are debugged and tested correctly before you put them
together in one main function.
If a bug is found, it will *affect* some or all sub-functions. Trace
every sub-functions until you found a bug. Fix one sub-function
before all sub-functions in one main function are working and running
correctly. All sub-functions do not need to be modified.
> (Of course, I cannot promise to solve every problem posted to
> Usenet, I just might try and do it for some small problems
> if I have some leisure.)
>
> The meaning of »god class« can be looked up using a search
> engine.
I am unable to find *god class* in Google search, but I do see *God
object*. I think that you are referring "C++ Anti-Pattern Design". I
have good understanding how C++ language is written, but I probably do
not have experience to understand Pattern Design.
== 4 of 5 ==
Date: Sun, Dec 27 2009 12:26 pm
From: Jonathan Lee
On Dec 27, 3:13 pm, Immortal Nephi <Immortal_Ne...@hotmail.com> wrote:
> You refer "Refactoring". Do you mean divide one big problem is
> divided into several small problems?
For starters he means this:
http://www.refactoring.com/catalog/index.html
and this
http://en.wikipedia.org/wiki/Code_refactoring
Use those strategies to "pull out" code from your god object into
more compact classes.
> I am unable to find *god class* in Google search, but I do see *God
> object*. I think that you are referring "C++ Anti-Pattern Design".
That's right.
--Jonathan
== 5 of 5 ==
Date: Sun, Dec 27 2009 4:27 pm
From: Immortal Nephi
On Dec 27, 2:26 pm, Jonathan Lee <cho...@shaw.ca> wrote:
> On Dec 27, 3:13 pm, Immortal Nephi <Immortal_Ne...@hotmail.com> wrote:
>
> > You refer "Refactoring". Do you mean divide one big problem is
> > divided into several small problems?
>
> For starters he means this:
>
> http://www.refactoring.com/catalog/index.html
>
> and this
>
> http://en.wikipedia.org/wiki/Code_refactoring
>
> Use those strategies to "pull out" code from your god object into
> more compact classes.
>
> > I am unable to find *god class* in Google search, but I do see *God
> > object*. I think that you are referring "C++ Anti-Pattern Design".
>
> That's right.
Jonathan,
Thank you for the information. It is very new to me and I am learning
by reading reference. You provided me two websites, but I found good
website at http://sourcemaking.com. It gives you the information
about Design Pattern and Refactoring. You can click Refactoring and
you will see reference.
==============================================================================
TOPIC: Saving a binary file into a string
http://groups.google.com/group/comp.lang.c++/t/ddc89ddf30293133?hl=en
==============================================================================
== 1 of 8 ==
Date: Sun, Dec 27 2009 10:11 am
From: Dominik Schmidt
On Sun, 27 Dec 2009 09:39:12 -0800 (PST), Rune Allnor wrote:
> 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.
You mean bytes like CR (carriage return, 13), LF (line feed, 10) or null
(0)?
I've copied many files with my code, including text files using only CR
*or* LF as line break (insted of CR LF) and files including null characters
or other bytes which don't represent a visible character.
And all of those copies had the same hashes as the original files. So it
worked (so far). Even with large files > 2 GB.
> 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.
Actually I thought my code would already do this by using "ios::binary" in
both functions?
Could you give me an example (file) that doesn't work with my code?
Thanks for your help
== 2 of 8 ==
Date: Sun, Dec 27 2009 10:38 am
From: Rune Allnor
On 27 Des, 19:11, Dominik Schmidt <dominikschmi...@gmx.net> wrote:
> > 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.
>
> Actually I thought my code would already do this by using "ios::binary" in
> both functions?
It might have done, but by using std::string you confuse readers
of your code about what you are doing. std::string is intended
for human-readable text, and anywhere one sees it, one expects
to handle human-readable text. You break with that expectation,
which will only cause confusion later on. You also expose your
data to functions and manipulations intended for strings.
If you use std::vector<char> you first of all make it clear to
the reader that these are binary data, and the reader of your
code will relate to your code accordingly. Secondly you prevent
your data from being accessed through string-manipulating
functions. Which would only have caused mayhem and misery,
if it occured.
The key to C++ is to express the data in terms of the type
or class that best represents the properties of the data.
Since you do *not* have text data, std::string, which is
intended for precisely text data, is the *wrong* container
to use.
Rune
== 3 of 8 ==
Date: Sun, Dec 27 2009 10:43 am
From: Jonathan Lee
On Dec 27, 10:39 am, Dominik Schmidt <dominikschmi...@gmx.net> wrote:
> 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?
Strictly speaking, char may be larger than an octet in C++. The
value of CHAR_BIT in <climits> will tell you exactly how big. I
think both POSIX and Windows require it to be 8, though. And even
if it weren't, I don't think your code would be affected as is.
> string OpenFile(string FilePath)
Nothing major.
- Str1 seems completely unnecessary. You could write the attach
function to work with chars.
- long long isn't an official type in C++ yet. C++0x will add
it as a type.
- I don't see why you don't just read the whole file instead of
a char at a time. That's gotta be slow. If you aren't
expecting the files to be large, do whatever processing you
have to in memory.
> void SaveFile(string FilePath, string FileContent)
Again, you could write all of FileContent.data() at once.
> long long GetFileSize(string FilePath)
I would probably use the return type of tellg() (i.e.,
std::streampos). No biggy.
--Jonathan
== 4 of 8 ==
Date: Sun, Dec 27 2009 12:03 pm
From: Dominik Schmidt
On Sun, 27 Dec 2009 10:38:55 -0800 (PST), Rune Allnor wrote:
OK, this is what I wanted to know.
Thank you very much for your explanation.
I won't use the data type std::string for binary data anymore.
== 5 of 8 ==
Date: Sun, Dec 27 2009 12:40 pm
From: Dominik Schmidt
On Sun, 27 Dec 2009 10:43:10 -0800 (PST), Jonathan Lee wrote:
> Strictly speaking, char may be larger than an octet in C++. The
> value of CHAR_BIT in <climits> will tell you exactly how big. I
> think both POSIX and Windows require it to be 8, though. And even
> if it weren't, I don't think your code would be affected as is.
Right now, I'm working on a Windows only application, so this shouldn't be
a problem.
But could this cause trouble if I'm writing an application for UN*X (or
another common OS)? I guess no?
>> string OpenFile(string FilePath)
>
> Nothing major.
> - Str1 seems completely unnecessary. You could write the attach
> function to work with chars.
Yes, you're right, and I've done this by now.
> - long long isn't an official type in C++ yet. C++0x will add
> it as a type.
long long isn't an official type?
What alternative do I have to save a large integer number? As far as I know
the largest possible number in a long long variable is 9223372036854775807,
so which official data type could save this number?
Can I get into trouble if I continue using long long?
> - I don't see why you don't just read the whole file instead of
> a char at a time. That's gotta be slow. If you aren't
> expecting the files to be large, do whatever processing you
> have to in memory.
Is there a significant time difference when using large (maybe > 500 MB)
files?
> I would probably use the return type of tellg() (i.e.,
> std::streampos). No biggy.
OK, I assume this would be a better way of coding?
Can I do anything wrong by using long long here?
== 6 of 8 ==
Date: Sun, Dec 27 2009 1:06 pm
From: Jonathan Lee
On Dec 27, 3:40 pm, Dominik Schmidt <dominikschmi...@gmx.net> wrote:
> But could this cause trouble if I'm writing an application for UN*X (or
> another common OS)? I guess no?
Linux and BSDs follow POSIX which requires CHAR_BIT == 8. I don't
really
know about other OS's.
> > - long long isn't an official type in C++ yet. C++0x will add
> > it as a type.
> long long isn't an official type?
Not in the current version of C++. Though most compilers support it
as an extension since it's in C99. See here:
http://en.wikipedia.org/wiki/C%2B%2B0x#Type_long_long_int
Or http://www2.research.att.com/~bs/C++0xFAQ.html#long-long
> What alternative do I have to save a large integer number?
long, or unsigned long. If you're on a 64-bit OS these will
be 64-bits anyway. But see below about streampos/tellg()
> so which official data type could save this number?
None. Though long *could* be large enough.
> Can I get into trouble if I continue using long long?
Not really. It'll be in C++0x which is on the horizon, and
I think most/all compilers support it as an extension. I
don't think it's a problem most people get upset about. I
was just giving you a heads up, really.
> Is there a significant time difference when using large
> (maybe > 500 MB) files?
Probably not significant. Your OS should cache the reads
from disk so that you aren't going to disk for each char.
That would be the big performance penalty. You'll just
incur the call overhead. This is all platform dependent.
You could test to find out the difference on your
computer.
But still, it just seems odd. If you follow Rune's advice
and use a std::vector, just resize it to the file size
and read directly into the vector:
yourvector.resize(filesize) // make room
yourfile.read(&yourvector[0], filesize); // done.
> OK, I assume this would be a better way of coding?
> Can I do anything wrong by using long long here?
I'm just anal about types. tellg() returns a streampos,
which is defined by the standard to be a signed integral
type. So it will fit into long long; you won't have a
problem with that.
But also keep in mind that you don't really need
long long, then. The value in your long long vars will
never be larger than what can fit in a streampos (which
in turn will be no larger than a long). So if it were
me, I'd just get rid of long long and use streampos.
I'd kill two "problems" with one stone.
--Jonathan
== 7 of 8 ==
Date: Sun, Dec 27 2009 2:54 pm
From: Jorgen Grahn
On Sun, 2009-12-27, Dominik Schmidt 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.
...
> void SaveFile(string FilePath, string FileContent)
You should learn to use references; that's better written as
void SaveFile(const string& path, const string& s)
Having to fit the whole file in memory *once* is problematic enough;
here you double the memory needed.
You also almost always need a way to report errors.
> {
> ofstream file1;
> long long filesize;
> char Chr1;
>
> filesize = FileContent.length();
>
> if (FileExists(FilePath)) KillFile(FilePath);
> if (FileExists(FilePath)) return;
Don't ask for permission; just try to do it (truncating the existing
file as you go). You ask the wrong question anyway -- you might just
as well fail because you don't have write permissions, or the disk is
almost full, or ...
The checks are also leaky because the thing you try to check for and
make sure is true, can become false a microsecond later, when some
other process creates that file.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 8 of 8 ==
Date: Sun, Dec 27 2009 8:21 pm
From: Kaz Kylheku
On 2009-12-27, Dominik Schmidt <dominikschmidt3@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.
Can't be done in standard C++. To make an exact copy of a file requires
platform-specific functions. You have to retrieve all of the file's
OS-specific attributes like ownership, permissions, modification
timestamps, and other features like ``forks'', etc.
==============================================================================
TOPIC: "Reusable" operator overloading for enum?
http://groups.google.com/group/comp.lang.c++/t/981ab2c7a0c2c5ff?hl=en
==============================================================================
== 1 of 5 ==
Date: Sun, Dec 27 2009 11:30 am
From: nick
Thanks for all the great replies!
Marcel, your solution works perfectly. I like how it 'documents' the
enum as being a flag set. I'm using this for now with a few small
additions, but now I'm curious why people seem generally opposed to
macros...
Anyway, I have a few other small questions if you guys are still
interested. Balog, you mentioned the ~ operator would not be
predictable, and it sounds like it's because the way enums are stored
in memory is not predictable?
This makes me wonder if I should cast to unsigned as in Marcel's
example, or signed as in Saeed's example and as I was doing before. Of
course I'll only want to use positive numbers for my flag sets, but
enums seem to handle negative numbers just fine, so I'm not sure what
the right thing to do is here.
So, I guess my question is: is there a way to explicitly store an enum
as an int, or an unsigned int, or whatever, either using a language
construct or some kind of compiler instrucion? I'm using GCC 4.3.
The template stuff may be a bit over my head, but here's how I
understand it: Saeed's solution will work, but it will overload those
operators for all (classes? enums?), not just the flag sets I need
those operators for. Johannes says I can use is_enum<ENUM_TYPE>::value
to fix it so it only affects (enums?) ... is that about right? If so
what are the advantages of that over Marcel's method, other than macro
definitions looking ugly in the source?
Thanks for the help!
-- Nick
== 2 of 5 ==
Date: Sun, Dec 27 2009 7:05 pm
From: "BGB / cr88192"
"nick" <nick___@fastmail.fm> wrote in message
news:eefb339f-9a80-4566-8a41-fdf6625532ca@q2g2000yqd.googlegroups.com...
> 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.
>
errm, if they are flags why not just use '#define'?...
> -- Nick
== 3 of 5 ==
Date: Sun, Dec 27 2009 8:29 pm
From: "Balog Pal"
> template<class ENUM_TYPE>
> ENUM_TYPE operator|(ENUM_TYPE e1, ENUM_TYPE e2)
>
>> 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.
Me too. But for this case I stand with macros. Global templated operator --
that is way more evil than macros :)
And for this case I want certain operators only for a couple of enums. (bit
operators for those that has masks, increment, addition that I use in state
machine, etc...)
If that is_enum<> actually works it still picks up all the enums, masking
problems where I used an unintended one.
>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.
Yeah, there are good improvements, class enums do not convert to integrals
implicitly, also you can set a fixed implementation type -- and if you did,
you can forward-declare the enum, and define its enumerators at multiple
places. (IIRC)
== 4 of 5 ==
Date: Sun, Dec 27 2009 8:44 pm
From: "Balog Pal"
"nick" <nick___@fastmail.fm>
> Marcel, your solution works perfectly. I like how it 'documents' the
> enum as being a flag set. I'm using this for now with a few small
> additions, but now I'm curious why people seem generally opposed to
> macros...
You will find it in all accepted standard/guideline books. The most serious
roblem is that macros do not respect scope. And for many applications there
are way better tools -- constants/enums, inline functions, templates...
Though not for everything.
> Anyway, I have a few other small questions if you guys are still
> interested. Balog, you mentioned the ~ operator would not be
> predictable, and it sounds like it's because the way enums are stored
> in memory is not predictable?
Yes, if you have enumerators 0, 1 -- the used type may be char, unsigned
char, short, int, possibly others. Certain use approach can go without
problems, but I'd avoid it unless absolutely needed. If you want it to
remove bits combined with &, rather define a named function doing right
that.
> This makes me wonder if I should cast to unsigned as in Marcel's
> example, or signed as in Saeed's example and as I was doing before. Of
> course I'll only want to use positive numbers for my flag sets, but
> enums seem to handle negative numbers just fine, so I'm not sure what
> the right thing to do is here.
For bit-masks I stick to unsigned operations.
> So, I guess my question is: is there a way to explicitly store an enum
> as an int, or an unsigned int, or whatever, either using a language
> construct or some kind of compiler instrucion? I'm using GCC 4.3.
Probably gcc has a compiler switch to 'treat enums as ints' or like, though
for all of them. Look dox for attribute, rthough don't hold your breath. For
language level control wait C++0x.
> The template stuff may be a bit over my head, but here's how I
> understand it: Saeed's solution will work, but it will overload those
> operators for all (classes? enums?), not just the flag sets I need
> those operators for. Johannes says I can use is_enum<ENUM_TYPE>::value
> to fix it so it only affects (enums?) ... is that about right?
AFAIK is_enum is some boost magic.
== 5 of 5 ==
Date: Sun, Dec 27 2009 9:53 pm
From: nick
Thanks, Balog. I did away with the ~ operator, but instead of
replacing it with a named function I figured I'd use the - and -=
operators for unsetting the flag. Here's what I ended up with, maybe
this will be useful for someone else.
#define FLAGS_(T) \
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 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|r; } \
inline static T operator-(T l, T r) \
{ return l&r?(T)((unsigned)l-(unsigned)r):l; } \
inline static T& operator|=(T& l, T r) \
{ return l = l|r; } \
inline static T& operator&=(T& l, T r) \
{ return l = l&r; } \
inline static T& operator+=(T& l, T r) \
{ return l = l+r; } \
inline static T& operator-=(T& l, T r) \
{ return l = l-r; }
==============================================================================
TOPIC: Design patterns
http://groups.google.com/group/comp.lang.c++/t/c99eb0b17c6ad648?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Dec 27 2009 12:08 pm
From: Branimir Maksimovic
tanix wrote:
> In article <hh7bu9$urq$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
>> Joshua Maurice wrote:
>>> 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.
>
Enough. ;)
What a impressive argument!
Greets
== 2 of 4 ==
Date: Sun, Dec 27 2009 4:13 pm
From: Joshua Maurice
On Dec 27, 3:08 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> tanix wrote:
> > In article <hh7bu9$ur...@news.albasani.net>, Branimir Maksimovic <bm...@hotmail.com> wrote:
> >> Joshua Maurice wrote:
> >>> 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.
>
> Enough. ;)
> What a impressive argument!
Technically, that was my point too. Thus far, we haven't made any
reasoned arguments. tanix, Branimir Maksimovic, and myself have just
been spitting out definitions, or axioms, without any sort of coherent
argument. We've just made the claim that "Intelligence is defined as
X, and I am right". However, at least I mentioned that I was doing
that.
This is going to quickly devolve into an argument over "correct
definitions" or an argument of religion, neither of which I'm keen to
discuss, so I will leave it at that. (I do wish that instead we could
try to distill down the core of what most people mean when they say
"intelligence", but I fear that such a discussion is also off topic,
and none of the people in the discussion are well enough educated to
have such a discussion, myself included.)
== 3 of 4 ==
Date: Sun, Dec 27 2009 5:07 pm
From: MiB
On Dec 27, 3:43 am, ta...@mongo.net (tanix) wrote:
> Well, I am not against the design patterns in principle.
>
> But what I DO see all over the place is a literal obscession.
> That web page used two design patterns for a single thing.
> I do not argue whether it IS the way to go or not.
>
> But that looked like an extremism to me, just from glancing at it.
It is not uncommon practice to mix several design patterns.
Note, using a design pattern does not imply you are talking about
every aspect of an application.
For example, assume you need to do the architecture for a application
that shall have a GUI and needs to access a central database in a
distributed system. You may end up with a design that separates the
internal representation of data from how it is represented in the GUI,
plus some (again separate) mechanism to react on user input from the
GUI and propagate business logic activity to state changes in the GUI.
If you talk to some other expert about this approach it may be easier
to just say you are planning for a Model-View-Controller design
pattern, and usually he will understand what you mean without the need
to explain the details, many of which may not yet be fixed anyway.
For the access to the central database you may find it a good idea not
to access the database directly, but layer an application server in
between and already you use a second pattern "Three-Tier".
The connection to the application server may be encapsulated in its
own class and for efficiency you want to a) make sure it is only
established if actually needed, b) is shared in different parts of
your application, and c) at most one object is created; you'll
probably end up with the "Singleton" pattern.
At no time you are limited to use an existing design pattern, if you
find something unique that is better suited for the problem at hand,
use it by all means. However, if it proves useful, you should make a
note on why you chose this special design and how the parts fit
together - maybe it can be reused for a different problem later and
become a design pattern for you.
I would like to recommend you two books; there are a number of other
good books on the topic available already but these I liked most:
E. Gamma, R. Helm, R. Johnson, J. Vlissides: "Design Patterns -
Elements of Reusable Object-Oriented Software", Addison-Wesley: 1995.
M. Fowler: "Patterns of Enterprise Application Architecture", Addison-
Wesley: 2003.
Especially the Fowler book changed my view on software development; I
rarely encountered similar eye-openers before - Stroustrup's "The C++
programming language"; not the language description part, but the
later chapters about programming paradigms; "Gödel, Escher, Bach" by
D. Hofstaedter was another one for me.
best,
MiB
== 4 of 4 ==
Date: Sun, Dec 27 2009 8:17 pm
From: Kaz Kylheku
On 2009-12-27, Branimir Maksimovic <bmaxa@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.
This is not a fact, but an open question in artificial intelligence
research.
> Human consciousness and intelligence does not works
> on algorithm.
Assertion without evidence.
Quantum physicists believe in a finite state universe. If consciousness
is embedded in a finite-state universe then it means it's part of a
finite state machine, ergo ...
But that is not so interesting; what's more provoking is the possibility
that consciousness could be encoded in a lot fewer states.
> Plain fact. We can invent algorithm,
Not all of us, just a small minority.
> but algorithm itself can;t produce previously
> unknown algorithm.
Obviously, an algorithm whose purpose isn't algorithm invention doesn't
invent algorithms.
Genetic programming is an concrete example of algorithms inventing
algorithms.
> This is mathematical fact....
ROFL.
==============================================================================
TOPIC: C++ jobs down another 40%
http://groups.google.com/group/comp.lang.c++/t/6718a9cd2f3ecdbf?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Dec 27 2009 2:17 pm
From: "BGB / cr88192"
"Bo Persson" <bop@gmb.dk> wrote in message
news:7pouahFmkjU1@mid.individual.net...
> 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!
>
yeah, x86 only is pretty weak...
even with x86 only, there is still 32 vs 64 bit x86, which creates all sorts
of troubles...
using 32-bit x86 and either interpreting or JIT'ing it, is a little better,
but still kind of a nasty option...
however, doing some of the code in 32-bit x86 and JIT'ing it for the 64-bit
case has been something I had been considering, even if it is nasty...
MSIL / CIL is possibly a little better option, but CIL is a big and
complicated format.
JBC (Java ByteCode) is also available, but JBC is hardly general-purpose
(can't really do C, ...).
if possible, I would want to avoid creating for the world "yet another"
("portable") bytecode (we already have too many of these).
this is also why I am not trying to make a "new" prog-lang either, and
instead leveraging C and Java and friends. ideally, all should be open, and
"porting" largely little more than a matter of copy and paste...
>
> Bo Persson
>
>
== 2 of 2 ==
Date: Sun, Dec 27 2009 5:54 pm
From: "BGB / cr88192"
"tanix" <tanix@mongo.net> wrote in message
news:hh7psk$8bf$1@news.eternal-september.org...
> In article <hh710d$fqt$1@news.albasani.net>, "BGB / cr88192"
> <cr88192@hotmail.com> wrote:
>>
<snip>
going to see if all this can be cut down this mountain of text some.
>
>>> 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.
>
yep.
> 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?
>
well, it is not quite a VM in the traditional sense, in that there is no
singular or unified architecture, and no centralized design (instead it all
being composed of bunches of components).
rather, the goal of the system is to try to be able to glue enough stuff
together to make it all work.
granted, in practice it hasn't been quite so nice.
this is part of why there is a big "metadata database" in the mix. it sits
around and tries to keep track of all the data, functions, and types. other
code sits around which does little more than tries to figure out how to
resolve requests, sometimes generating glue code in the process.
so, in this respect, it is a little nasty...
this is also part of why there is a (mostly) unified naming and
type-signature system.
these signatures are also used by the automatic code generators, ... as
well.
<snip>
as far as portability, well, I don't make the claim that it will work
anything near like what the JVM does...
for now, it works on 32 and 64 bit x86, but for anything else, well then,
there is a problem.
the idea I had before was that for other archs, most of the
not-really-portable parts would be rewritten, and only really the APIs would
be kept intact.
(the idea would be that hopefully all of the parts and APIs could be
specified sufficiently as that clone parts could be written without too many
compatibility issues).
for some newer parts, I have been trying to address portability better, for
example, the x86 interpreter is generally written to try to avoid itself
depending on x86, ...
but, I don't really have a good or clean solution here.
I guess it will be "portable" in the same manner as POSIX tries to be
portable.
generally, one will find minor issues and incompatibilities, for example,
code written naively for Linux may not build right on FreeBSD or vice versa,
but generally it is possible to make code which works in both cases.
no provisions then are made for code which is not written portably, which I
guess is something Sun does fairly well (since Java largely enforces that
code written for their VM will also work elsewhere...).
>
>>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.
>
it has threads, and synchronization is via good old mutexes.
I provide API wrappers for both threads and mutexes, partly to abstract over
the OS APIs, and partly to make GC aware of them.
events, well, not sure what exactly is in question here...
exceptions are not really workable at this point, since exception handling
is a big ugly mess in C land (since C doesn't have exceptions). I have some
API calls though which do them, and on Windows mostly hack into the Win32
and Win64 SEH mechanisms.
Linux has thus far been addressed mostly by "pretending" that Win32 SEH
exists.
I had designed a new EH mechanism to unify it all (based partly on both
Win64 SEH and Java's EH mechanism), but haven't really implemented it as of
yet...
it really doesn't help much that typically several different EH mechanisms
are in use on each OS as it is (Win32/64 have SEH, VEH, MSVC++ exceptions,
...), and Linux as well has several mechanisms (although g++ uses libunwind,
which has become de-facto).
none of this is well tested though, so I am hesitant to assert that the EH
actually works.
>>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.
>
yep.
>>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...).
>
<snip>
>
>>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.
>
ok, but FWIW it is mostly a special purpose JVM, although I am not certain
its exact intended use case.
>>no new language is created here.
>
> Oh, I like that one. I kinda have enough of those languages
> to bother about.
>
yep.
>
>>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?
>
'BGB Scripting C Compiler'.
the name partly comes from its direct (codebase) ancestor:
BS1 (BGB Script / 1).
which was a short-lived (late 2006) implementation rewrite of BS (BGB
Script), which was a loosely JavaScript derived script language originally
written in about 2004.
it had replaced Lang/BGB (LB), which was in use from around 2001-2003 and
was a Scheme variant (but with a number of additions/alterations).
LB was where I had first started messing around with non S-Expression
syntax, one of my early examples having beat a Python-like syntax on top of
Scheme, but I soon came to the conclusion that this was a poor idea (it was
less fun messing with the indentation than with the parens...)
BS1 had originally been written because BS was too slow and used the GC too
much (so, BS1 was mostly a redesign and optimization effort). BS1 was then
mutated into my original C compiler.
both LB and BS1 had use S-Exps internally for the parser / ASTs.
BS had originally use XML DOM-style trees.
the early C compiler used S-Exps as well, but eventually switched back to
DOM (me re-grabbing some amount of code from the BS interpreter)
>
>>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.
>
ok.
well, the project is decentralized, so little stops different parts from
working in different ways.
>
>>>>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.
>
yes, ok.
well, I have had at least some experience with a JS-style language (after
having written and used it for a while).
>
>>>>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?
> :--}
>
yep...
>
>>> 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.
>
not much used IDEs in a long time...
mostly Notepad + Windows Explorer + shells...
hard time seeing what an IDE really buys me, for the most part.
although, I guess IDE's have a few nice points, I don't know.
>
>>> 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...
>
granted.
well, documenting and rationalizing everything is a thought.
I guess it is better than "well, it all just happened...".
"well, I threw the gold in the fire, and out came the calf...".
>
>>> 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.
>
yep.
like a textual assembler...
one can generate assembler nearly anywhere from anything, and send it to the
assembler.
this works out fairly well, much better than directly forging machine
code...
> 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.
>
ok.
> 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?
>
not personally.
eventually, at some point I could use a job, but for now I am mostly a
college student...
> You probably need at least 3 to 10 people working on this thing.
> I am not sure you can handle it all by yourself.
>
possibly, yes.
but, as-is, it is just myself.
I am not sure how I would go about organizing an actual "project" as such.
actually, all is hosted from a server in my room at present, mostly because
for a long time I had fairly slow internet (when I was libing around Asia),
and trying to get anything up on sourceforge or similar was just WAY too
slow...
even then, interest was not terribly great for prior stuff.
>>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.
>
well, it is an idea...
even if no one likes the source, I guess it all could be of help if there
were any similar projects, since with a sufficiently "open" project, it
shouldn't matter as much who writes the components.
<more snip>
>
>>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.
>
agreed...
lots of skimming in this world it seems, people everywhere doing potentially
interesting stuff.
>
>>>>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...
> :--}
>
well, I don't personally use Java or the JVM as such, but I can understand
why other people would do so.
personally, I don't expect everything to be homogenous, the world just
doesn't work this way.
my effort spawned I guess because I always just did things like how I wanted
to do them (well, and how I had always done them).
maybe about 1998/1999 I had looked into Java, but at the time I was not much
pleased with the experience, so I returned to C, which is what I had been
using before.
later on, I ended up mostly looking into Scheme (initially a Lisp
implementation I forget the name of, later Scheme via SCM and Guile...).
Guile was giving me trouble, so I looked some at the source and wrote my
own. this was the origins of my ventures into VM land...
it was much of a decade before I really started looking at it again, but by
this point I was already well versed in the underlying technology...
>>>>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)
>
ok.
>>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!
>
yeah...
>>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.
>
granted...
luckily, MSVC and GCC "mostly" agree...
only that MSVC I suspect is living mostly in C90 / C95 land, whereas GCC is
in C99 land...
so, one can write C which works on both, granted, but it can be observed
that there are many slight differences between their notions of the
standard, and of standard components available in the compiler.
dunno why MS doesn't really seem to bother with C99 though, after all,
someone could have uses for things like complex numbers, ...
>>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.
>
ok.
>>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.
>
yeah...
my stuff mostly works without too much issue on Windows and Linux, and 32
and 64 bit x86.
beyond this?...
dunno...
I had loosely considered other archs, but this was not really a goal I have
much reason to pursue for now...
>>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!
> :--}
>
yep.
well, it is as portable as C is portable, more then a matter of the
implementation...
most of the implementation portability is a matter of the codegen, as well
as finding better alternatives than directly producing ASM.
sadly, there are too many tasks where the code needed to be produced is too
low-level to use C or RPNIL, and so much direct ASM is produced...
the issue with then is that these low-level fragments generally need to be
rewritten for each CPU and OS, which is not very nice...
>>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.
>
Win32 and Win64, and Linux x86 and x86-64.
any further, at the moment, would be a problem.
granted, many of the components could be ported easy enough, but many others
would break.
mostly, the components which would have problems are those directly related
to working with machine code (such as the assembler, linker, and codegen).
actually, I originally intended the codegen to be replacable, but ended up
hacking it onto x86-64 rather than doing a full replacement (as it ended up
as a much more complex component than originally imagined).
some adjustments were made though to potentially later address the
transition to non-x86 systems.
>>>>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?
>
I can't say really...
>>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.
>
yep.
> 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.
>
yep.
> 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.
>
yes, ok.
>>>>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?
>
Pascal never dies...
>>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.
>
> :--}
>
ok.
>>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!
> :--}
>
maybe.
>
>>> 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!
>
pretty much.
>>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.
>
ok.
>>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...
>
>
>>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.
>
ok.
>>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 parts, I am using JBC.
for other things, I am mostly compiling directly from source and caching the
results...
JBC is not "that bad", since JBC is typically JIT'ed into machine code
anymore.
I may do this eventually as well...
>>>>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.
>
yeah, not as much into electronics...
>>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.
>
yes, ok.
>>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.
>
ok.
>>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!
> :--}
>
well, there are all these ideals:
marry, get a job, ...
but none have happened...
so, much is as it was years ago, not so ideal.
>>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".
>
ok.
>>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.
>
ok, ok.
>>>> 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.
>
hmm...
>>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.
>
yes, ok.
>
>>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?!?
>
why Python, dunno...
lots of people use it, but personally I don't know the reason...
>>> 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.
> :--}
>
agreed, would be nice.
textual C source can be portable, much more so than binary code.
however, for some things, we don't want C...
for example, I would have my doubts about it comming off a web-page, or at
least if not sandboxed.
sandboxing is something I had also looked into.
>
>>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.
>>....
>
these are internal dependencies...
ideally, dependencies should be avoidable, but they are not always so...
then again, a compiler makes little sense without having an assembler
around, so I guess it is justified...
>
>>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.
>
well, there are some unique powers to these kind of things, admittedly, they
can be a bit ugly...
>
>>> 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.
>
yes, ok.
I could write more, but these posts are getting long, and I have stuff
needing to do.
>
>>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.
>
well, getting away from them does allow optimizing the compiler some, since
this is one of the biggie issues which slows down C compilation:
processing the huge piles of stuff pulled in by headers...
>>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.
>
ok.
>
>>> 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.
>
agreed.
I like to divide things up similarly if possible.
>
>>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.
>
hmm... dunno...
>
>>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.
>
well, I really don't know how this particular issue can be addressed...
usually, the one doing the selling is the one getting the money, but I guess
it is the mystery of what of the people who do the actual work...
hmm...
==============================================================================
TOPIC: Interfacing C++ and assembler code
http://groups.google.com/group/comp.lang.c++/t/79272d2bf39c62ec?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Dec 27 2009 2:34 pm
From: Jorgen Grahn
On Sat, 2009-12-26, Branimir Maksimovic wrote:
...
> 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:
I don't do Win32 programming, but your example makes it reasonably
clear that they did *not* ban assembly; they simply removed the C++
extensions for inline assembly from their compiler. Some would say
that was a wise choice.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
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