Hi All,

I'm currently working in the typesystem branch for csound 6.  I was
thinking that we currently have some mix of hash map implementation
s(name_hash, csound_str_hash_32, name_hash_2).  It's curently in the
namedins.h header.

I was thinking it might be nice to reorganize hash usage a bit, at
least into its own header.  I also did a search and found this
implementation:

http://pokristensson.com/strmap.html

It's LGPL 3, and seems well done.  I figured it could be modified to
replace malloc/free with csound->malloc, csound->free and add CSOUND*
to the function arguments.

It seems like it'd be cleaner to have this data structure be in its
own header (instead of namedins.h) and clearer to understand in code
what files use hash maps.  Any objections or concerns in moving
forward along these lines?

Thanks!
steven

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Csound already involves linking with the C++ standard library for some
of the opcodes. Put the stuff into a std::map<> or std::hash_map<> in
a C ++ file and create some C helper/wrapper functions in the Csound
API. You will get an excellent, probably unimprovable implementation
for next to no work.

The same could be said for all the other collections in Csound...

On the other hand, it looks as though C++ linkage has been
deliberately kept out of libscoundNN.so.N.N.

On the other, other hand, it seems silly to me to duplicate
implementations of standard algorithms where perfectly good
implementations already exist in the Csound code base.

Regards,
Mike

On Sat, Jul 14, 2012 at 11:19 AM, Steven Yi  wrote:
> Hi All,
>
> I'm currently working in the typesystem branch for csound 6.  I was
> thinking that we currently have some mix of hash map implementation
> s(name_hash, csound_str_hash_32, name_hash_2).  It's curently in the
> namedins.h header.
>
> I was thinking it might be nice to reorganize hash usage a bit, at
> least into its own header.  I also did a search and found this
> implementation:
>
> http://pokristensson.com/strmap.html
>
> It's LGPL 3, and seems well done.  I figured it could be modified to
> replace malloc/free with csound->malloc, csound->free and add CSOUND*
> to the function arguments.
>
> It seems like it'd be cleaner to have this data structure be in its
> own header (instead of namedins.h) and clearer to understand in code
> what files use hash maps.  Any objections or concerns in moving
> forward along these lines?
>
> Thanks!
> steven
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'd prefer not to wrap C++ and keep things straight C.  I also think
that the existing map functions (multiple) should be reorganized at
the least.  It sounds like if not C++ wrapping, you'd lean towards
just reorganizing the existing functions?

On Sat, Jul 14, 2012 at 11:39 AM, Michael Gogins
 wrote:
> Csound already involves linking with the C++ standard library for some
> of the opcodes. Put the stuff into a std::map<> or std::hash_map<> in
> a C ++ file and create some C helper/wrapper functions in the Csound
> API. You will get an excellent, probably unimprovable implementation
> for next to no work.
>
> The same could be said for all the other collections in Csound...
>
> On the other hand, it looks as though C++ linkage has been
> deliberately kept out of libscoundNN.so.N.N.
>
> On the other, other hand, it seems silly to me to duplicate
> implementations of standard algorithms where perfectly good
> implementations already exist in the Csound code base.
>
> Regards,
> Mike
>
> On Sat, Jul 14, 2012 at 11:19 AM, Steven Yi  wrote:
>> Hi All,
>>
>> I'm currently working in the typesystem branch for csound 6.  I was
>> thinking that we currently have some mix of hash map implementation
>> s(name_hash, csound_str_hash_32, name_hash_2).  It's curently in the
>> namedins.h header.
>>
>> I was thinking it might be nice to reorganize hash usage a bit, at
>> least into its own header.  I also did a search and found this
>> implementation:
>>
>> http://pokristensson.com/strmap.html
>>
>> It's LGPL 3, and seems well done.  I figured it could be modified to
>> replace malloc/free with csound->malloc, csound->free and add CSOUND*
>> to the function arguments.
>>
>> It seems like it'd be cleaner to have this data structure be in its
>> own header (instead of namedins.h) and clearer to understand in code
>> what files use hash maps.  Any objections or concerns in moving
>> forward along these lines?
>>
>> Thanks!
>> steven
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have long recommended rewriting Csound in C++ (I'm not talking about
the opcodes, but only the runtime). I also don't see a problem with
mixing C and C++.

My recommendations are based on both industry experience and personal
experience. They are not subjective. They are not based on "like" or
"dislike." What I like is code that is correct, that runs fast, and
that is easy to read. I don't care at all how these goals are arrived
at.

These days critical systems and large scale software is mostly written
in C++. That includes avionics, sophisticated signal processing, most
large software applications including most commercial music software,
and science data analysis software. I presume there are real reasons
for this choice, and based upon my personal experience writing Csound
opcodes and other software in both C and C++, as well as many other
programming languages, I feel like I know what these reasons are.

C++ enables one to write large software systems without sacrificing
efficiency. C++ code also is more terse than C code, so takes less
time to write and to get right.

Regards,
Mike

On Sat, Jul 14, 2012 at 11:54 AM, Steven Yi  wrote:
> I'd prefer not to wrap C++ and keep things straight C.  I also think
> that the existing map functions (multiple) should be reorganized at
> the least.  It sounds like if not C++ wrapping, you'd lean towards
> just reorganizing the existing functions?
>
> On Sat, Jul 14, 2012 at 11:39 AM, Michael Gogins
>  wrote:
>> Csound already involves linking with the C++ standard library for some
>> of the opcodes. Put the stuff into a std::map<> or std::hash_map<> in
>> a C ++ file and create some C helper/wrapper functions in the Csound
>> API. You will get an excellent, probably unimprovable implementation
>> for next to no work.
>>
>> The same could be said for all the other collections in Csound...
>>
>> On the other hand, it looks as though C++ linkage has been
>> deliberately kept out of libscoundNN.so.N.N.
>>
>> On the other, other hand, it seems silly to me to duplicate
>> implementations of standard algorithms where perfectly good
>> implementations already exist in the Csound code base.
>>
>> Regards,
>> Mike
>>
>> On Sat, Jul 14, 2012 at 11:19 AM, Steven Yi  wrote:
>>> Hi All,
>>>
>>> I'm currently working in the typesystem branch for csound 6.  I was
>>> thinking that we currently have some mix of hash map implementation
>>> s(name_hash, csound_str_hash_32, name_hash_2).  It's curently in the
>>> namedins.h header.
>>>
>>> I was thinking it might be nice to reorganize hash usage a bit, at
>>> least into its own header.  I also did a search and found this
>>> implementation:
>>>
>>> http://pokristensson.com/strmap.html
>>>
>>> It's LGPL 3, and seems well done.  I figured it could be modified to
>>> replace malloc/free with csound->malloc, csound->free and add CSOUND*
>>> to the function arguments.
>>>
>>> It seems like it'd be cleaner to have this data structure be in its
>>> own header (instead of namedins.h) and clearer to understand in code
>>> what files use hash maps.  Any objections or concerns in moving
>>> forward along these lines?
>>>
>>> Thanks!
>>> steven
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, I know your stance on C/C++ and your rationales as well.
However, your email is not quite addressing the question I asked.
I'll just keep going with what I'm doing here; the map stuff is not
critical and I have quite a bit of other things to do first.


On Sat, Jul 14, 2012 at 5:35 PM, Michael Gogins
 wrote:
> I have long recommended rewriting Csound in C++ (I'm not talking about
> the opcodes, but only the runtime). I also don't see a problem with
> mixing C and C++.
>
> My recommendations are based on both industry experience and personal
> experience. They are not subjective. They are not based on "like" or
> "dislike." What I like is code that is correct, that runs fast, and
> that is easy to read. I don't care at all how these goals are arrived
> at.
>
> These days critical systems and large scale software is mostly written
> in C++. That includes avionics, sophisticated signal processing, most
> large software applications including most commercial music software,
> and science data analysis software. I presume there are real reasons
> for this choice, and based upon my personal experience writing Csound
> opcodes and other software in both C and C++, as well as many other
> programming languages, I feel like I know what these reasons are.
>
> C++ enables one to write large software systems without sacrificing
> efficiency. C++ code also is more terse than C code, so takes less
> time to write and to get right.
>
> Regards,
> Mike
>
> On Sat, Jul 14, 2012 at 11:54 AM, Steven Yi  wrote:
>> I'd prefer not to wrap C++ and keep things straight C.  I also think
>> that the existing map functions (multiple) should be reorganized at
>> the least.  It sounds like if not C++ wrapping, you'd lean towards
>> just reorganizing the existing functions?
>>
>> On Sat, Jul 14, 2012 at 11:39 AM, Michael Gogins
>>  wrote:
>>> Csound already involves linking with the C++ standard library for some
>>> of the opcodes. Put the stuff into a std::map<> or std::hash_map<> in
>>> a C ++ file and create some C helper/wrapper functions in the Csound
>>> API. You will get an excellent, probably unimprovable implementation
>>> for next to no work.
>>>
>>> The same could be said for all the other collections in Csound...
>>>
>>> On the other hand, it looks as though C++ linkage has been
>>> deliberately kept out of libscoundNN.so.N.N.
>>>
>>> On the other, other hand, it seems silly to me to duplicate
>>> implementations of standard algorithms where perfectly good
>>> implementations already exist in the Csound code base.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Sat, Jul 14, 2012 at 11:19 AM, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> I'm currently working in the typesystem branch for csound 6.  I was
>>>> thinking that we currently have some mix of hash map implementation
>>>> s(name_hash, csound_str_hash_32, name_hash_2).  It's curently in the
>>>> namedins.h header.
>>>>
>>>> I was thinking it might be nice to reorganize hash usage a bit, at
>>>> least into its own header.  I also did a search and found this
>>>> implementation:
>>>>
>>>> http://pokristensson.com/strmap.html
>>>>
>>>> It's LGPL 3, and seems well done.  I figured it could be modified to
>>>> replace malloc/free with csound->malloc, csound->free and add CSOUND*
>>>> to the function arguments.
>>>>
>>>> It seems like it'd be cleaner to have this data structure be in its
>>>> own header (instead of namedins.h) and clearer to understand in code
>>>> what files use hash maps.  Any objections or concerns in moving
>>>> forward along these lines?
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I didn't mean to distract, my apologies.

To refocus on the issues you raised, I think factoring together
collections code that exists in C would indeed be a good idea.

I don't think using the C collections code from C++ would be as good
an idea as the other way round, in case that was another possibility
you were suggesting, because I think the C++ collections are more
widely used and more extensively debugged.

Regards,
Mike

On Sat, Jul 14, 2012 at 5:51 PM, Steven Yi  wrote:
> Yes, I know your stance on C/C++ and your rationales as well.
> However, your email is not quite addressing the question I asked.
> I'll just keep going with what I'm doing here; the map stuff is not
> critical and I have quite a bit of other things to do first.
>
>
> On Sat, Jul 14, 2012 at 5:35 PM, Michael Gogins
>  wrote:
>> I have long recommended rewriting Csound in C++ (I'm not talking about
>> the opcodes, but only the runtime). I also don't see a problem with
>> mixing C and C++.
>>
>> My recommendations are based on both industry experience and personal
>> experience. They are not subjective. They are not based on "like" or
>> "dislike." What I like is code that is correct, that runs fast, and
>> that is easy to read. I don't care at all how these goals are arrived
>> at.
>>
>> These days critical systems and large scale software is mostly written
>> in C++. That includes avionics, sophisticated signal processing, most
>> large software applications including most commercial music software,
>> and science data analysis software. I presume there are real reasons
>> for this choice, and based upon my personal experience writing Csound
>> opcodes and other software in both C and C++, as well as many other
>> programming languages, I feel like I know what these reasons are.
>>
>> C++ enables one to write large software systems without sacrificing
>> efficiency. C++ code also is more terse than C code, so takes less
>> time to write and to get right.
>>
>> Regards,
>> Mike
>>
>> On Sat, Jul 14, 2012 at 11:54 AM, Steven Yi  wrote:
>>> I'd prefer not to wrap C++ and keep things straight C.  I also think
>>> that the existing map functions (multiple) should be reorganized at
>>> the least.  It sounds like if not C++ wrapping, you'd lean towards
>>> just reorganizing the existing functions?
>>>
>>> On Sat, Jul 14, 2012 at 11:39 AM, Michael Gogins
>>>  wrote:
>>>> Csound already involves linking with the C++ standard library for some
>>>> of the opcodes. Put the stuff into a std::map<> or std::hash_map<> in
>>>> a C ++ file and create some C helper/wrapper functions in the Csound
>>>> API. You will get an excellent, probably unimprovable implementation
>>>> for next to no work.
>>>>
>>>> The same could be said for all the other collections in Csound...
>>>>
>>>> On the other hand, it looks as though C++ linkage has been
>>>> deliberately kept out of libscoundNN.so.N.N.
>>>>
>>>> On the other, other hand, it seems silly to me to duplicate
>>>> implementations of standard algorithms where perfectly good
>>>> implementations already exist in the Csound code base.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Sat, Jul 14, 2012 at 11:19 AM, Steven Yi  wrote:
>>>>> Hi All,
>>>>>
>>>>> I'm currently working in the typesystem branch for csound 6.  I was
>>>>> thinking that we currently have some mix of hash map implementation
>>>>> s(name_hash, csound_str_hash_32, name_hash_2).  It's curently in the
>>>>> namedins.h header.
>>>>>
>>>>> I was thinking it might be nice to reorganize hash usage a bit, at
>>>>> least into its own header.  I also did a search and found this
>>>>> implementation:
>>>>>
>>>>> http://pokristensson.com/strmap.html
>>>>>
>>>>> It's LGPL 3, and seems well done.  I figured it could be modified to
>>>>> replace malloc/free with csound->malloc, csound->free and add CSOUND*
>>>>> to the function arguments.
>>>>>
>>>>> It seems like it'd be cleaner to have this data structure be in its
>>>>> own header (instead of namedins.h) and clearer to understand in code
>>>>> what files use hash maps.  Any objections or concerns in moving
>>>>> forward along these lines?
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

All good, I'm sort of out of it after looking at code for Csound and
blue for some 4+ hours today. I'm looking at some big changes in both
projects so it's making so my head ache a bit; sorry if I was a bit
short in my reply! :)

If I was looking to use C++, I'd certainly just use STL containers,
for precisely the reasons you mentioned.  No argument there.

For the time being, I'm going to just keep going with what I got so
that I don't lose momentum.  Some of this code I'm writing is not
really using optimal data structures, but I think I've written it in a
way such that it can easily be replaced.

I'm currently working on redoing csoundCompileTree/oload/instance to
use the type system, and also replacing variable counts with variable
pools. There's a lot to rip out and replace, but it should clean up a
lot of things I think.  I think it'll make the code easier to
understand too, especially csound_orc_compile.c.  I'm planning for
instance to still use a total memory size count to alloc a giant pool
of memory for the vars/opcodes when creating new instances of an
instrument, but change to using using the variable pool to look up
indexes (will probably cache indexes in an array as well to optimize).
I'm also looking at encapsulating the string and MYFLOAT constants
pools into their own structs, more to help clear up the code
organization than anything.

Just a note, there's a lot I can't push to SourceForge at the moment
as the amount of changes are big and it's taking a while to get things
back into a usable state.  I'm hoping to start the modifications to
replace the variable index counts tomorrow, and will update here with
status whenever things are in a working state again.

Thanks!
steven


On Sat, Jul 14, 2012 at 6:14 PM, Michael Gogins
 wrote:
> I didn't mean to distract, my apologies.
>
> To refocus on the issues you raised, I think factoring together
> collections code that exists in C would indeed be a good idea.
>
> I don't think using the C collections code from C++ would be as good
> an idea as the other way round, in case that was another possibility
> you were suggesting, because I think the C++ collections are more
> widely used and more extensively debugged.
>
> Regards,
> Mike
>
> On Sat, Jul 14, 2012 at 5:51 PM, Steven Yi  wrote:
>> Yes, I know your stance on C/C++ and your rationales as well.
>> However, your email is not quite addressing the question I asked.
>> I'll just keep going with what I'm doing here; the map stuff is not
>> critical and I have quite a bit of other things to do first.
>>
>>
>> On Sat, Jul 14, 2012 at 5:35 PM, Michael Gogins
>>  wrote:
>>> I have long recommended rewriting Csound in C++ (I'm not talking about
>>> the opcodes, but only the runtime). I also don't see a problem with
>>> mixing C and C++.
>>>
>>> My recommendations are based on both industry experience and personal
>>> experience. They are not subjective. They are not based on "like" or
>>> "dislike." What I like is code that is correct, that runs fast, and
>>> that is easy to read. I don't care at all how these goals are arrived
>>> at.
>>>
>>> These days critical systems and large scale software is mostly written
>>> in C++. That includes avionics, sophisticated signal processing, most
>>> large software applications including most commercial music software,
>>> and science data analysis software. I presume there are real reasons
>>> for this choice, and based upon my personal experience writing Csound
>>> opcodes and other software in both C and C++, as well as many other
>>> programming languages, I feel like I know what these reasons are.
>>>
>>> C++ enables one to write large software systems without sacrificing
>>> efficiency. C++ code also is more terse than C code, so takes less
>>> time to write and to get right.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Sat, Jul 14, 2012 at 11:54 AM, Steven Yi  wrote:
>>>> I'd prefer not to wrap C++ and keep things straight C.  I also think
>>>> that the existing map functions (multiple) should be reorganized at
>>>> the least.  It sounds like if not C++ wrapping, you'd lean towards
>>>> just reorganizing the existing functions?
>>>>
>>>> On Sat, Jul 14, 2012 at 11:39 AM, Michael Gogins
>>>>  wrote:
>>>>> Csound already involves linking with the C++ standard library for some
>>>>> of the opcodes. Put the stuff into a std::map<> or std::hash_map<> in
>>>>> a C ++ file and create some C helper/wrapper functions in the Csound
>>>>> API. You will get an excellent, probably unimprovable implementation
>>>>> for next to no work.
>>>>>
>>>>> The same could be said for all the other collections in Csound...
>>>>>
>>>>> On the other hand, it looks as though C++ linkage has been
>>>>> deliberately kept out of libscoundNN.so.N.N.
>>>>>
>>>>> On the other, other hand, it seems silly to me to duplicate
>>>>> implementations of standard algorithms where perfectly good
>>>>> implementations already exist in the Csound code base.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On Sat, Jul 14, 2012 at 11:19 AM, Steven Yi  wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I'm currently working in the typesystem branch for csound 6.  I was
>>>>>> thinking that we currently have some mix of hash map implementation
>>>>>> s(name_hash, csound_str_hash_32, name_hash_2).  It's curently in the
>>>>>> namedins.h header.
>>>>>>
>>>>>> I was thinking it might be nice to reorganize hash usage a bit, at
>>>>>> least into its own header.  I also did a search and found this
>>>>>> implementation:
>>>>>>
>>>>>> http://pokristensson.com/strmap.html
>>>>>>
>>>>>> It's LGPL 3, and seems well done.  I figured it could be modified to
>>>>>> replace malloc/free with csound->malloc, csound->free and add CSOUND*
>>>>>> to the function arguments.
>>>>>>
>>>>>> It seems like it'd be cleaner to have this data structure be in its
>>>>>> own header (instead of namedins.h) and clearer to understand in code
>>>>>> what files use hash maps.  Any objections or concerns in moving
>>>>>> forward along these lines?
>>>>>>
>>>>>> Thanks!
>>>>>> steven
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks for the update. Readable code! Readable code! Sounds good.

Best,
Mike

On Sat, Jul 14, 2012 at 6:39 PM, Steven Yi  wrote:
> All good, I'm sort of out of it after looking at code for Csound and
> blue for some 4+ hours today. I'm looking at some big changes in both
> projects so it's making so my head ache a bit; sorry if I was a bit
> short in my reply! :)
>
> If I was looking to use C++, I'd certainly just use STL containers,
> for precisely the reasons you mentioned.  No argument there.
>
> For the time being, I'm going to just keep going with what I got so
> that I don't lose momentum.  Some of this code I'm writing is not
> really using optimal data structures, but I think I've written it in a
> way such that it can easily be replaced.
>
> I'm currently working on redoing csoundCompileTree/oload/instance to
> use the type system, and also replacing variable counts with variable
> pools. There's a lot to rip out and replace, but it should clean up a
> lot of things I think.  I think it'll make the code easier to
> understand too, especially csound_orc_compile.c.  I'm planning for
> instance to still use a total memory size count to alloc a giant pool
> of memory for the vars/opcodes when creating new instances of an
> instrument, but change to using using the variable pool to look up
> indexes (will probably cache indexes in an array as well to optimize).
> I'm also looking at encapsulating the string and MYFLOAT constants
> pools into their own structs, more to help clear up the code
> organization than anything.
>
> Just a note, there's a lot I can't push to SourceForge at the moment
> as the amount of changes are big and it's taking a while to get things
> back into a usable state.  I'm hoping to start the modifications to
> replace the variable index counts tomorrow, and will update here with
> status whenever things are in a working state again.
>
> Thanks!
> steven
>
>
> On Sat, Jul 14, 2012 at 6:14 PM, Michael Gogins
>  wrote:
>> I didn't mean to distract, my apologies.
>>
>> To refocus on the issues you raised, I think factoring together
>> collections code that exists in C would indeed be a good idea.
>>
>> I don't think using the C collections code from C++ would be as good
>> an idea as the other way round, in case that was another possibility
>> you were suggesting, because I think the C++ collections are more
>> widely used and more extensively debugged.
>>
>> Regards,
>> Mike
>>
>> On Sat, Jul 14, 2012 at 5:51 PM, Steven Yi  wrote:
>>> Yes, I know your stance on C/C++ and your rationales as well.
>>> However, your email is not quite addressing the question I asked.
>>> I'll just keep going with what I'm doing here; the map stuff is not
>>> critical and I have quite a bit of other things to do first.
>>>
>>>
>>> On Sat, Jul 14, 2012 at 5:35 PM, Michael Gogins
>>>  wrote:
>>>> I have long recommended rewriting Csound in C++ (I'm not talking about
>>>> the opcodes, but only the runtime). I also don't see a problem with
>>>> mixing C and C++.
>>>>
>>>> My recommendations are based on both industry experience and personal
>>>> experience. They are not subjective. They are not based on "like" or
>>>> "dislike." What I like is code that is correct, that runs fast, and
>>>> that is easy to read. I don't care at all how these goals are arrived
>>>> at.
>>>>
>>>> These days critical systems and large scale software is mostly written
>>>> in C++. That includes avionics, sophisticated signal processing, most
>>>> large software applications including most commercial music software,
>>>> and science data analysis software. I presume there are real reasons
>>>> for this choice, and based upon my personal experience writing Csound
>>>> opcodes and other software in both C and C++, as well as many other
>>>> programming languages, I feel like I know what these reasons are.
>>>>
>>>> C++ enables one to write large software systems without sacrificing
>>>> efficiency. C++ code also is more terse than C code, so takes less
>>>> time to write and to get right.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Sat, Jul 14, 2012 at 11:54 AM, Steven Yi  wrote:
>>>>> I'd prefer not to wrap C++ and keep things straight C.  I also think
>>>>> that the existing map functions (multiple) should be reorganized at
>>>>> the least.  It sounds like if not C++ wrapping, you'd lean towards
>>>>> just reorganizing the existing functions?
>>>>>
>>>>> On Sat, Jul 14, 2012 at 11:39 AM, Michael Gogins
>>>>>  wrote:
>>>>>> Csound already involves linking with the C++ standard library for some
>>>>>> of the opcodes. Put the stuff into a std::map<> or std::hash_map<> in
>>>>>> a C ++ file and create some C helper/wrapper functions in the Csound
>>>>>> API. You will get an excellent, probably unimprovable implementation
>>>>>> for next to no work.
>>>>>>
>>>>>> The same could be said for all the other collections in Csound...
>>>>>>
>>>>>> On the other hand, it looks as though C++ linkage has been
>>>>>> deliberately kept out of libscoundNN.so.N.N.
>>>>>>
>>>>>> On the other, other hand, it seems silly to me to duplicate
>>>>>> implementations of standard algorithms where perfectly good
>>>>>> implementations already exist in the Csound code base.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>> On Sat, Jul 14, 2012 at 11:19 AM, Steven Yi  wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I'm currently working in the typesystem branch for csound 6.  I was
>>>>>>> thinking that we currently have some mix of hash map implementation
>>>>>>> s(name_hash, csound_str_hash_32, name_hash_2).  It's curently in the
>>>>>>> namedins.h header.
>>>>>>>
>>>>>>> I was thinking it might be nice to reorganize hash usage a bit, at
>>>>>>> least into its own header.  I also did a search and found this
>>>>>>> implementation:
>>>>>>>
>>>>>>> http://pokristensson.com/strmap.html
>>>>>>>
>>>>>>> It's LGPL 3, and seems well done.  I figured it could be modified to
>>>>>>> replace malloc/free with csound->malloc, csound->free and add CSOUND*
>>>>>>> to the function arguments.
>>>>>>>
>>>>>>> It seems like it'd be cleaner to have this data structure be in its
>>>>>>> own header (instead of namedins.h) and clearer to understand in code
>>>>>>> what files use hash maps.  Any objections or concerns in moving
>>>>>>> forward along these lines?
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://www.michael-gogins.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>>> will include endpoint security, mobile security and the latest in malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net